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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Paul. Excellent!
I have many other reasons why I think IEEE1471 does not help us at all. But I like very much what you are saying.
One of the biggest challenges is that consultancy organizations have abducted the mainstream body of knowledge of enterprise architecture. But it should be in the hands of non profit organizations.
I my opinion for starters we need clear definitions for architect, architecture, structure, concept, element, component, pattern, principle and view. And to get them, we need discussion. Architecture is not only a noun (product) but also a verb (field of science).
I myself have created an open method EA called Dragon1 https://www.dragon1.com/frameworks/dragon1 where I define these terms and use them as a core in a way of thinking, way of working and way of supporting for architects.
Architect = Designer of Total Concepts & supervisor of the realization. Architecture (noun) = Special Total
Concept for a structure. Architecture (verb) = the art and science of designing and reallizing structures, Principle = the enforced way a entity (concept, element, component, solution, system, etc…) works producing results, etc…
This great post of Paul should be read and commented by lots of other people. I think it is meant to start of discussion. So where’s the discussion guys & girls?
Good reading, thanks Paul, I love the way you are thinking, however I cannot agree with the message. Standard is here not to govern the architecture – the purpose is to give us the starting point to build whatever framework we want. And strangely, any good architecture framework appears more or less inline with what 42010 suggests. You feel gaps in concepts and terminology – you are welcome to build your own methodology.
Interesting point regarding Business Architerure “left hanging” – this maybe the case with BA without engineering background, true. But adjusting standard to help this marginal group feel better… I’d prefer to educate them on systems, mostly because it works. Business has the same nature as other systems, we can define functions, identify stakeholders, synthesize realization structure and build implementation plan as we do in software, or basically in any other domain of human activity.
With the full respect and best regards,
Ivan P.
The revision of ISO/IEC/IEEE 42010 has begun.
I think you’ll like the new title:
Enterprise, systems and software — Architecture description.
WG42 welcomes comments on improvement of the Standard.
Check the website for details.
Recall from the earliest edition IEEE 1471:2000, we specifically included enterprise in our scope. The name reflected not the scope of the standard, but the charter of the sponsoring organizations..
Hi Paul,
I think that the right approach would not to standardise what (crap) the Architects say and do, but what should they say and do to make sense and improve the organisation of our systems and their management. Particularly, Architect must (IMHO) distinguish between Architecture, Architectural Practice (its elements and outcomes like solutions and requirements for realisation) and Implementation of Architectural Solutions. How the Architect roles are categorised is the second priority thing and, actually a part of the Architectural Practice realm.
I am ready to contribute into a standard (considering my experience in writing OASIS SOA standards) that would make Architecture and its practice sensible, reasonable, practical and defensible.
Best regards,
– Michael Poulin
Any thoughts on The Open Group standards; TOGAF, Archimate etc.? How do they compare in value to ISO 42010 and IEEE 1471?