Architecture is a concept everyone knows, but what is architecture actually?

In Chapter 2.2 of TOGAF 9.1 it says:

TOGAF embraces but does not strictly adhere to ISO/IEC 42010:2007 terminology.

Yet, in its list of definitions, TOGAF attributes ISO/IEC 42010:2007 when it defines architecture:

1. A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010:2007).
2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

The citation of ISO/IEC 42010:2007 is incorrect. The second definition is a paraphrase, not a literal quote of the 42010 definition, but the first definition should not be attributed to 42010 at all. Neither should refer to 42010 as its source, I would say. The actual text of the definition of architecture from ISO/IEC 42010:2007 is:

The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.

I asked around about the TOGAF reference. Andrew Josey from the Open Group picked up on my question and has now filed a defect report (“Minor”, “Editorial”) in the TOGAF 9.1 Defect Reporting system (protected link; you need to be a member of the Architecture Forum to access it).

It so happens that ISO/IEC 42010:2007 is today a deprecated standard, since the standards bodies have published a revised version, ISO/IEC/IEEE 42010:2011, which updates this very definition. The text of the definition of architecture from ISO/IEC/IEEE 42010-2011 is:

Fundamental concepts or properties of a system in its environment, embodied in its elements, relationships and in the principles of design and evolution.

The new definition is in my opinion clearer than the 2007 definition, and the one I will use in the future. The 42010 standard has a long history, enough to fill a whole annex (Annex A) of the standard and a classic paper. The 42010 FAQ points out that there are several key ideas in this definition:

• “Architecture” names that which is fundamental or unifying about a system as a whole; the set of essential properties of a system which determine its form, function, value, cost, and risk.
• An architecture is a conception of a system – i.e., it is in the human mind. An architecture may exist without ever being written down. Therefore, the Standard distinguishes architectures and architecture descriptions: just as it is said, “the map is not the territory”, an architecture description is not the architecture. An architecture description is what is written down as a concrete work product. An architecture description represents an attempt to express a conception of a system to share with others. The focus of the Standard is on requirements on architecture descriptions.
• An architecture is understood in context – not in isolation. To understand a system’s fundamental properties (i.e., architecture) is to understand how the system relates to, and is situated in, its environment. Often, the architect cannot know what is fundamental about a system without knowingfundamental to whom? Therefore “fundamental” is to be interpreted in the context of a system’s stakeholders in its environment.
• Finally, there are some things that an architecture definitely is not. An architecture is not merely the overall structure of physical components that make up a system. While physical structure can be fundamental to a system, it need not be.

Strictly speaking, TOGAF “messes up” the 42010 definition by suggesting two meanings “depending on the context” but not then explaining when and where which definition should be used; in TOGAF chapter 35.1, only the second definition is used, even though in a place where the first definition ought to be used (artifacts/documents context), but actually following 42010 and saying that the architecture as one thing, and the architecture description as another thing. 42010 is very clear: An architecture is abstract – not an artifact. The 42010 standard uses another term, architecture description, to refer to artifacts used to express and document architectures.

When we work with architecture, as architects, we are architecting (42010:2011):

Process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle.

In the Common Approach, architecture is defined as:

a systematic approach that organizes and guides design, analysis, planning, and documentation activities.

Finally, a quote from the Danish architect/designer Arne Jacobsen:

I don’t see that any buildings should be excluded from the term architecture, as long as they are done properly.

Available very soon:

August 2012 – Volume 8, Number 3 of

CONTENT

Editor’s Corner
John Gøtze introduces this number.

Don’t understand what the architect is talking about? There’s an app for that!

EAGlossary.com is a free web app for looking up enterprise architecture terms and definitions.

Get the app: Via webbrowser on your tablet/mobile, add eaglossary.com to the home screen.

Sources are EA3, The Common Approach and FEAF-II and ISO:42010.

Week 31 is for students and researchers as well as practitioners in the field of enterprise architecture, who want to spend a pracademic week together and share and learn more about EA. 

Dates: 30 July – 3 Aug 2012
Location: IT University of Copenhagen

REGISTER NOW

Themes:

• EA as a Discipline and a Profession
• Trends in Enterprise Architecture Practice and Research
• Selected Industry EA developments
• The Common Approach to Federal Enterprise Architecture (US) and other recent developments in government EA

Workshops on:

• Enterprise Roadmapping
• Collaborative Planning
• The Social Enterprise
• Out-of-the-box vs Boxes-and-Arrows: Innovation and Architecture
• Documentation, Models and Artifacts: Common Meta Models?
• Business and Information Systems Engineering Curriculum & Philosophy of Computer Science
• … (suggest a workshop!)

Read more at 2012.internationaleainstitute.org

Gary Hamel’s new book, What Matters Now: How to Win in a World of Relentless Change, Ferocious Competition, and Unstoppable Innovation, is marketed as “an impassioned plea” to “reinvent management as we know it” and “rethink the fundamental assumptions we have about capitalism, organizational life, and the meaning of work”.

In this important book, Hamel continues the argumentation known from his 2007 bestseller The Future of Management. There, Hamel discussed the various forms of innovation – operational innovation, product innovation, strategy innovation, and, of course, management innovation. The new book continues in the same direction. His argument is that innovators “pay close attention to emerging trends”, to “the nascent discontinuities that have the potential to reinvigorate old businesses or create new ones”.

He lists five questions that can help a team to zero in on potentially important discontinuities:

1. As you think about culture, politics, technology, and so on, what are the things you’ve read, seen, or experienced in recent months that have been surprising, perplexing, or disconcerting?
2. Which of these anomalies seem to have some momentum behind them? When you look across the world, or back over the last few months, do you see these trends expanding in scope or accelerating? Are they blooming if not yet booming?
3. If you ‘‘run the movie forward,’’ how might these discontinuities play out? What are the chain reactions that might be set in motion?
4. Which of these discontinuities aren’t yet topics of conversation within your industry? Which ones were missing from the agenda of the last industry confab you attended?
5. How might we exploit these discontinuities in ways that would wrong-foot our competitors?

The challenge is that people need to view the world around them with fresh eyes:

 I can’t state the point strongly enough: the first and most important step for any organization intent on building a capacity for continuous, gamechanging innovation is to teach its people how to view the world around them with fresh eyes.

To put it bluntly, the conversation about “where to go next” should be dominated by individuals who have their emotional equity invested in the future rather than the past. It needs to be led by individuals who don’t feel the need to defend decisions that were taken ten or twenty years ago.

And from the conclusion, with reference to Vineet Nayar:

The world has become too complex for the CEO to play the role of “visionary-in-chief.” Instead, the CEO must become a “management architect” – someone who continually asks, “What are the principles and processes that can help us surface the best ideas and unleash the talents of everyone who works here?”

“Management architect” is a great concept, I think. Hamel doesn’t provide more details about what he sees in this role, unfortunately. Nor does Nayar, as far as I can see.

Both gentlemen – and readers of their books – really should look into enterprise architecture.

As an enterprise architect, most of my emotional equity is invested in the future, but I am also deeply concerned about the present, but not so much about the past. My mission: future-proofing enterprises. My vision: The coherent enterprise which thrives on discontinuities in a continuous way.

In a recent memo for the federal CIOs, the US Federal CIO, Steven VanRoekel, launched a set of important management documents, including the so-called Common Approach, which states:

The role of an enterprise architect is to help facilitate and support a common understanding of needs, help formulate recommendations to meet those needs, and facilitate the development of a plan of action that is grounded in an integrated view of not just technology planning, but the full spectrum of planning disciplines to include mission/business planning, capital planning, security planning, infrastructure planning, human capital planning, performance planning, and records planning. Source: FEAF-II 

 

I wonder when EA will be discussed in Hamel’s new initiative, Management Innovation eXchange. Hopefully soon.