Tuesday, June 15, 2004
Software Suburbia
Science, like life, evolves with the environment, or dies. In the field of Computer Science, this evolution resulted in creation of the role of architect. The architect was responsible for maintaining the vision of a system throughout its development lifecycle. In practical terms, this meant designing an application infrastructure that supported both the functional and nonfunctional requirements. Thus, a higher level of organization was achieved.
The trend amongst man-made systems is toward increasing levels of organization-- it is as if the whole of humanity is fighting a holy war against the forces of entropy. In terms of the role of architects, this means that the inherent architecture of infrastructure components is steadily increasing. This does beg a question, which must soon be answered if architects are to avoid the fate of the dodo bird (insert favorite architect joke here): what does this imply about the future role of the architect?
If the role of architect is to survive, it must continue to climb the levels of abstraction. As COTS components continue to resolve (in a more or less optimized fashion) the nonfunctional requirements of enterprise systems, the need for formal designs, at the enterprise level, for the resolution of such concerns must necessarily diminish. Instead, focus should be placed on the needs at the enterprise level: business processes, information flow, and context management.
There is still plenty of system work to be accomplished at this level. BPEL is moving forward quickly, as is MDA. MDA. Now there's an interesting dilemma. If what I have said is true, then MDA is not really what we should be looking for. MDB, anyone?
