The Verb, “To Architect”

Posted by Martin Hunter on 18 December 2012

Have you heard it said that “you need an architecture document here” or “you need an architect on that”? If you have ever worked in or close to the IT industry then this comment, or something like it, is probably something you’ll have come across. If this is you, now ask yourself: When was the last time you heard it said “you need to architect this” with the focus on the process rather than the deliverable? My bet is that it will be less often, potentially never! Architecture is commonly seen as a deliverable, which I think misses the point, and that is the topic of this short blog entry.

The concepts that “an architecture” needs to be produced as part of any IT endeavour as an end in itself, or that an architecture is comprised of a commonly known and unchanging set of artifacts that all architects are familiar with, are complete myths. Whilst to the outsider, IT hides itself well under a vail of computer-scientific terminology and techno-babble that sounds very well structured, architectures in IT are notoriously varied and often (disappointingly) anything but scientific: Their scopes, semantics and syntax vary from architect to architect, let alone from organisation to organisation, and certainly they vary over time. Whilst this is less than helpful, it is also a reflection that one thing that is far more important varies considerably too: The consultative design process that any architecture output documents.

The process of architecting something, be it a house, office block, system or enterprise is a design optimisation process. It sounds obvious and it pretty much is. In most developed countries, the construction industry has the minimum necessary component parts of a building architecture locked down quite well, but what is also evident from this realm is that the architect is really someone who manages the design process and ensures that the end product meets the needs of those who are stakeholders in it. The stakeholders are not just the owners, but the people who use a building (try thinking now and in 50 years from now), the builders that put it together, bills of materials for suppliers, the council who signs it off as safe to inhabit, the quantity surveyor who assesses its resource requirements, the fireman who needs to save people from the building when it burns, the risk assessor that signs off the building mortgage or insurance policy and so on. All important aspects of a building are considered by a construction architect, at least to a certain level, and these aspects extend well beyond the three dimensional models typically portrayed as an architect’s output. Architecture in construction is rarely about drawing technical pictures, it’s all about understanding needs, communicating problems and solution options and balancing the benefits and costs of a complex process to achieve a desired outcome.

This much is true of IT as well; the thrust of the architectural process is about taking a consultative, structured approach to identifying, analysing and solving the parameters of an optimisation problem: It is a process of strategic, stakeholder-driven design.When you put it like this, it is easy to see why architecture (as a verb, not a noun) is important and necessary. Architecture as an artifactis nothing, architecture as a process is everything.

This philosophy is why I like to press the argument that investment in fixed architecture templates (in document or model forms) are less helpful than they appear or purport to be. There are plethora of architectural methods and frameworks from vendors big and small that promise lower risk and more predictable outcomes. Organisational standards based on these are often reinforced with draconian, almost radical, mantras forcing adherence to templates and ensuring that process check-boxes are ticked at every stage, whether it makes sense or not, whilst at the same time missing important, sometimes unique factors of a particular problem domain. Whilst templates are often there to help (via compliance) they should certainly not disempower the architects and designers who need to follow the very important process of design that is needed to actually reduce risk and improve predictability.

So what are the characteristics of a good architectural design process, if not adherence to templates or well documented frameworks? Well, in contrast to the above, I think that the core architectural process comes down to some simple tenants (watch this space for my future blog on architectural axioms) aimed at discovering the right questions to ask and to prioritise the finding of answers to. Tools, frameworks and methods are about empowering the architect to do just this. The architect is someone who understands these artifacts and has the background, either by training or job experience, that enables them to ask the right stakeholders the right questions at the right time. Frameworks and methods are helpful as a means to ensure that topics have been covered; tools are helpful to allow the architect to manage the huge complexity they face and to communicate views of this to different stakeholders. They are all aimed at making sure conversations are had, aspects considered, risks raised, and, very importantly, allow an architect to derive what is important and what might have been missed. Frameworks and templates need to be easy to understand, light and focus on a few simple ideas that provide dimensions to the problem and solution spaces rather than act to impress a strict process or ideal. To me, this is truly using frameworks and templates for good, not evil.