As we move into a new period of architect growth and capability, we are also facing some of our most important challenges as a profession, and it is extremely important that our standards remain relevant and useful. Unfortunately, that is simply not the case with what is supposed to be our most important centralized standard, the ISO 42010, Systems and software engineering — Architecture description, and some of the problem is right there in the name. This standard, adopted in 2011, was completely antiquated and less than useful then, much less now. This is a standard that attempts to define some of our core terminology and yet even the name points at a software engineering problem and not an architecture problem domain. This simply does not provide the useful and powerful foundation we need as a profession to continue to stay relevant and necessary in our professional capacity, nor does it in any way relate to the day in and day out life of practicing architects.

In my post, architecture doesn’t happen at a desk I explain why models and documents are useless to most enterprises but, sadly, this is just what our standards describe, very scientific and rigorous ways to create models and documents not innovation, strategy and execution. Now you might think Im ‘anti-architecture’ in the sense of a good architecture description, but the real truth is I am simply tired of seeing architects fail because they focus on conformance and governance based documentation over real transformation. 42010 and 1471 are a part of that problem. I am calling for a new standard in architecture. One that focuses on the architect and their primary value function, business technology strategy, instead of documentation and model wizard. Here are some of the things that MUST be fixed.

  1. Software engineering is not architecture – This should go without saying, business architecture is not software engineering. Infrastructure architecture is not software engineering. We retain our technical skill throughout our career, yes even business architects must have some decent technology background to succeed over time. But the vast majority of architecture is strategy. Most importantly this definition does not create a relevant difference between software engineering and software architecture, much less software engineering and business architecture. An architecture defines WHY – what I often call Form – not just HOW or WHAT. The HOW – what I like to call Structure – is a meeting between the WHY and the WHAT – what I call Function. This is one reason why architects and engineers are such different people even though in many cases their skills overlap signficantly. It also works for business, enterprise, information, and infrastructure. Our definitions at Iasa much better represent the value of architecture OVER engineering – keep in mind a common job of an architect is to figure out ways to turn things OFF not just build them. Engineering is about structure and function (the ISO version), architecture is about Strategy and structure (the Iasa version).
  2. It is completely irrelevant to business architecture – Any definition, especially at the international standards level must function for ALL architects. ISO clearly does not function in any way for the average business architect and one reason they have been so difficult to integrate into existing architecture organizations – they are effectively left hanging. A better definition integrates architects at the value proposition level, ie what a customer comes to us for.
  3. Architecture is not inherent, it must be intentional – only structure is inherent and not even that in many systems – The whole concept of a system having an architecture whether it is written down or not has always struck me as a little less than useful, somewhat like the professional equivalent of ‘the sound of one hand clapping’. Great for beers or meditation, but useless for the practicing architect. A system may have a structure (a design) whether it is intentialinal or not, but can we agree that we want to reserve the term architecture for something we meant to happen? I realize that we love our debates, but we must begin acting like professionals. Our clients hire us because they want a solid business technology strategy that we can execute for them. Let’s stick with what does our customers good and save the philosophy for the bar.
  4. It treats architecture only as a document not a profession – In Architecture Practice vs The Noun, I describe the point of architecture as a practice, an ethical code and a value proposition. Architecture is not a just a noun (a document), it is a value practice that customers need and cannot achieve for themselves. 42010 treats architecture as a noun (except the term architecting, which is not a real word). It describes an architecture description and signficant amounts of conformance requirements for it to meet that definition. The vast majority of the standard is about views, viewpoints, concerns and models all rolled up in a neat little package called an architecture description. And yet for this to have meaning a) it must be used, b) it must be useful, c) it must exhibit qualities that cannot be attained through another role or a layman. None of these are inherent in the definitions or implementation of the standard. The definitions can easily be fulfilled by a good engineer. The document itself is generally less than useful, especially in an emergent design mentality such as agile, and therefore they are not used (except as documentation) which relegates the architect to a corner where he/she documents the enterprise as it goes by, while others do real work that adds value and transforms.
  5. There are significantly more than these terms relevant to architects – Architecture repository, strategy, constraints, business, value, governance, project, program, portfolio, product, epic, story, presentation, risk, even the word DESIGN is missing. We found 100+ terms useful to architects in our work on the FRM. Let’s get busy on a standard that helps solve arguments instead of creating them.
  6. The definition of views/viewpoints is skewed – The current standard has views addressing stakeholder’s concerns. Seems fair and good, and while presumably the architect themselves is a relevant stakeholder, the way this comes across is that all architecture views are meant to address someone elses concerns. In the real world I have found the best architects maintain only one set of very minimal and very powerful documents, their own. That is the minimum set of models, descriptions, and value management tools necessary to understand WHY decisions were made and to transfer ownership of those decisions, as quickly as possible, to another architect if that is necessary. All other documents are simply communication, and most of that can be thrown away after it is communicated. I will be posting another entire piece on this so keep a look out for it.
  7. Shareholders, not just stakeholders, are what matter most – most of the best architects in the world care about their stakeholders. And they know they need to communicate effectively with them. But they also know something else. Their real job is to the shareholder, not the stakeholder. The most successful architects will tell a stakeholder what is needed and in many cases why it is needed by the company or owner. This gets into the nature of value versus requirement which I talk about here.

There is some decent rigor put into the standard and Im sure we will have a lot of debating to do but the point of the standard is completely wrong. Instead of a practical guide to concepts and capabilities of an architect, we have a reference model for models and documents. Time to get that right.