Design in Context
I have always been fascinated by building design and architecture. My brother is an architect and we have long talks on the subject, where we discuss not only the works of particular architects or artists, but the nature and profession of building design. I find these talks stimulating because I can relate to most of these topics as well.
When it comes to software, however, I find the role of the architect not as defined as it is in construction. At least not yet, as there seems to be a lot of discussion going on about the nature and role of an Architect. The IT industry is not just about software, it's also about the enterprise, the infra-structure and so on. In IT we find infra-structure architects, solution architects and enterprise strategy architects, each focused on one type of architecture. There is one other aspect that, in my mind, widens the gap between architecture in software and in construction, is that architecture in construction is more akin to art than to science, while architecture in IT traditionally stems from engineering and is deeply rooted in science.
So, regarding architecture in IT I keep asking myself two questions:
- Is software architecture art or science?
- With so many software engineers available how do we articulate the value of and need for an architect?
I won't address the first question here as it is somewhat metaphysical (not to mention controversial) and is food for another post at a later time. I have to admit I don't have a clear answer to either of these questions, but I venture that to find an answer (if an answer is to be found) we should look at the meaning of architecture in construction and in building design.
In the conversations I've had with my brother around architecture, I became distinctly aware of the great importance architects place on context: topological context, social context, design context, material context.
Take a look, for instance, at the work of architects like Tadao Ando, Mies Van der Rohe, Frank Lloyd Wright or even Frank Ghery and you can see and feel how their buildings either are inserted into the context of the surrounding landscape or they provide a new context to the surrounding landscape. Even when the buildings are disruptive, they are so contextually (i.e. the disruption provides a new context to the surrounding elements).
I venture that one of the greatest values of a software architect's to an IT organization is to provide software design in context. With this I mean, the right design that satisfies a number of propositions, those being the requirements for the software, but also the context in which that software is to be built and operated. This context can be defined in many different ways, for instance tying a business goal to IT capabilities and mapping technology to those capabilities or understanding a services strategy for a given enterprise and designing a LOB application according to that strategy. It might seem obvious and common sense, but I find that this context is frequently overlooked or dismissed, causing numerous disruptions, like constant feature redefinition, scope creep, cost overruns and client dissatisfaction.
In a time where IT is seen as a cost center and there is a generalized idea that most software is built like a house of cards without much structural integrity, it seems like confidence in IT as a strategic asset is dwindling. IT spending is becoming tighter and IT managers have to prove the value of IT to business stakeholders. Architects are a valuable asset to any IT organization in defining the principles for the IT eco-system (the IT context for the enterprise), helping to align business goals and IT capabilities.