So many people find the term “architecture” sexy and classy – and perhaps that’s why it’s so widely used? More than any other term in IT, “architecture” leads to much confusion and – frequently – disappointment.
IT solution architecture
When I worked at HP I took extensive trainings in a methodology known as ITSA – IT Solution Architecture. Originally developed by Digital, then taken and improved by Compaq, and finally taken over and renamed by HP, ITSA is a powerful and rigorous technique that let’s you begin with a business goal, examine the implications and consequences hierarchically (business->function->technical->implementation) and finish up with all the steps you need to successfully achieve that goal. Even when this technique is applied at a high level, without all the complicated artifacts and templates, it is still a very useful approach that gives an end-to-end consistency: each part of the solution can be mapped to a business driver.
HP originally wanted to publish this technique as an ISO standard (similar to ISO 42010 ); sadly, they never did.
IT software architecture
Many software developers reach the stage where they wish to be known as software architects – and except for vanity reasons, I could never understand this. Software development is a noble profession, so “master software developer” is to me an equally noble term.
Look on any forum about EA, and probably the hottest discussion is: “What exactly is EA?” What does that say when adherents themselves have not yet fully agreed on what it is they do?!
The most “robust” example of a company embracing architecture – that I have personally worked with – is the Swiss Federal Railways. There are massive teams of people in IT (IT architects) and each of them have their counterpart in massive teams of people in the business units (Geschäftsarchitektur). If you think this approach could be expensive and time-consuming, it is. It adds many, many additional layers to any IT projects that are carried out. But to be fair, the quality requirements are exceptionally high (Swiss trains must run on time, as a matter of national pride) and the process (and especially, interface) landscapes are so complex, this ensure everyone “measures fifty times, cuts once.”
IT Governance vs. Architecture (or rather, IT Governance + Architecture)
In my view, the ISO definitions in and around architecture, including “solution architecture,” are a great step forward for the industry. IT Governance was a similar area in need of standardization. But recently, there have been great gains in the definition of IT Governance (see e.g. ISO 38500).
My gut naively tells me there should be a deeper linkage and alignment between architecture definitions and governance definitions than what I have seen – soft of the IT equivalent of the “Grand Unified Theories” of physics. If anyone has links that address this, I would be eager to read more about this.