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.

The next number of JEA will contain around 41859 words! We are still working on getting it all together, aiming at getting it out in early-mid May.

I am very pleased to announce that JEA has been awarded formal ISSNs by the US Library of Congress:

ISSN 2166-6792 (Online)
ISSN 2166-6768 (Print)

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

Architect in the Spotlight: Tom Graves
Interview with Tom Graves.

Reinterpreting TOGAF’s Enterprise Architecture Principles Using a Cybernetic Lens
Mohammad Esmaeil Zadeh, Gary Millar and Edward Lewis
In the literature, there are many definitions of Enterprise Architecture (EA), but most of them have three items in common: elements, relationships and principles. Among these, principles represent an essential element in the definition of EA, and some researchers posit that they are the main element in this definition. However, despite the recent advances in defining enterprise architecture principles (EAPs), this notion is suffering from the lack of a theoretical foundation that provides a logical framework for defining them. Stafford Beer’s Viable System Model (VSM) and its application to IT governance, the Viable Governance Model (VGM), have shown to be comprehensive blueprints for designing viable organizations and IT governance arrangements, respectively. Similarly, in recent realizations of EA, the design of the whole organization, and not just the IT, is brought into consideration. Therefore, this paper aims to establish whether the laws and principles of cybernetics, especially those embodied in the VSM and the VGM, can provide a sound theoretical basis for deriving EA principles. This paper investigates the principles defined in the Open Group’s TOGAF based on the theoretical concepts drawn from the VSM/VGM and cybernetics more broadly. This investigation demonstrates that the principles in TOGAF can be derived from the laws and principles of cybernetics.

The Social Dimension of Enterprise Architecture in Government
Jouko Poutanen
Citizens’ rising demands and expectations concerning both the quality and equality of public services are increasing pressure on the Finnish public administration to improve its efficiency and responsiveness. An enacted act on Information Management Governance in public administration declares Enterprise Architecture (abbreviated EA) as a central tool for developing administration’s services. EA is seen as a strategic management tool standardising the development of administration and exploitation of Information and Communication Technologies (abbreviated ICT). The new act demands agencies to apply EA yet there exists relatively limited knowledge and experience of the concept. Since EA is an abstract and complex tool there is great risk that the expectations put on EA are not met. The large numbers of agencies demanded to apply this tool increases the significance of the problem. This article is based on a case study research where the goal was to identify issues of EA use and adoption, to gain understanding why these issues exist and to recommend ways of improving the perceived value of EA. The focus was on the social dimension of alignment since most existing studies have emphasised the technical dimension. The study approaches the problem from the perspective of strategic management and organisational learning. EA is treated as a mechanism and a strategy tool to enable alignment of business and IT. EA adoption presents a learning challenge to an organisation – it has to learn the intellectual content but more importantly, it has to learn how to cooperate and share information across functional, hierarchical and professional boundaries.

Measuring the Realization of Benefits from Enterprise Architecture Management
Matthias Lange, Jan Mendling and Jan Recker
Enterprise architecture management (EAM) has become an intensively discussed approach to manage enterprise transformations. While many organizations employ EAM, a notable insecurity about the value of EAM remains. In this paper*, we propose a model to measure the realization of benefits from EAM. We identify EAM success factors and EAM benefits through a comprehensive literature review and eleven explorative expert interviews. Based on our findings, we integrate the EAM success factors and benefits with the established DeLone & McLean IS success model resulting in a model that explains the realization of EAM benefits. This model aids organizations as a benchmark and framework for identifying and assessing the setup of their EAM initiatives and whether and how EAM benefits are materialized. We see our model also as a first step to gain insights in and start a discussion on the theory of EAM benefit realization.

Enterprise Architecture, IT Service Management and Service Oriented Architecture: Relationships, Approaches and Operative Guidelines. Part 1
Carlo Randone
Enterprise Architecture, IT Service Management (and Governance) and Service Oriented Architecture are current topics, widely discussed in the information technology departments and professional publications. In addition, many companies have been (or are) involved with the adoption of at least one of these innovations. While each of these elements can be considered in its own right, it is in their relationships, and more or less strong intersections, that interesting opportunities and synergies can emerge, potentially even with some specific issues to manage. The focus of this two-part article is just that: to show the relationships, approaches and operative guidelines related to the synergic adoption in an IT organization and/or in an Enterprise of concepts from the Enterprise Architecture (EA), IT Service Management (ITSM) and Service Oriented Architecture (SOA) domains.

An Enterprise Framework for Operationally Effective System of Systems Design
Joseph Bobinis and Thomas Herald
This paper proposes a transformation of traditional engineering design methods for Enabling System Design from “influence” to “synthesis” through an enterprise focus of both the primary system functionality as well as the required enabling systems, concurrently during design. An architectural transformation is required to improve the affordable, full life cycle operational effectiveness of customer solutions. Challenged is the notion of the primary and enabling support systems as separate in achieving enterprise operational effectiveness. Enterprise-level, integrated requirements and trade studies drive optimal user performance while still embracing the independent development of each system. This work proposes that operational effectiveness can be enhanced through leverage of an enterprise framework of primary and enabling systems entitled: Systems of Systems – System Design for Operational Effectiveness (SOS-SDOE). The initial driver of this research began with improving the Department of Defense (DoD) acquisition and sustainment of complex and network-centric systems. The description of traditional approaches to design are framed by industrial and commercial methods, the International Council on Systems Engineering methods and the recent evolution for sustainment represented by System Design and Operational Effectiveness (SDOE) model from military and academic literature. The framework proposes performing a System of Systems (SOS) trade-space analysis as a logical extension of proven traditional methods. To convey this message, a soft system analysis, using systemigram methods developed by Dr. John Boardman, is implemented to examine the transition from the traditional practices to address customer and user needs with SOS-SDOE. The SOS-SDOE enterprise framework emerges from expanding the system design boundary to capture the causal relationships, which are relevant to system operational effectiveness. There is a shared contribution of primary and enabling systems and in the framework, creates a more complete trade space that facilitates improved long-term user effectiveness. The SOS-SDOE architectural framework embraces and captures the emergent system behaviors of the combined enterprise in addition to the traditional behaviors of the independent systems. In an attempt to address the historically persistent problem of measuring and improving operational effectiveness, this approach embraces the fundamentals of an enterprise system framework: 1. Structured and explicit relational views, through the use of Systemigram representations, which provide an accepted methodology for communicating information about the relationships, which are relevant to the architectural objective of managing the causal mechanisms which effect operational outcomes of an enterprise; 2. Explicit methods and trade space definitions which enable the system design discipline to gather and organize the data and construct the design solution in ways that help ensure integrity, accuracy and completeness of the design over its life cycle; and 3. Abstracting of empirical and heuristic phenomenon (system behaviors) in support of the method and as a utility verification of the framework.

Making Use of a Target Technical Architecture to Support Acquisition Business Decisions
Russell S. Boyd and Brian Boynton
Enterprise architecture (EA) documents current conditions, future visions, and the transition plan between them. It pertains to and encompasses one or all of the following: programs, offices, segments, solutions, departments, lines of business, and agencies. IT acquisition management (ITAM) includes the set of tasks required to accomplish the directed and funded efforts to provide a new, improved, or continuing information system or services capability to satisfy a business need. Thus, an EA contains business operation information for decision support and communication and informs decision-makers about what technology to acquire and when. This article illustrates how a technical architecture can both provide a clear picture of the technical goals that lie ahead for the enterprise, as well as providing decision support to selecting and acquiring a product that will help satisfy the organizational requirements and scheduling needs.

Book Review: Managed Evolution
Michael Linke reviews Managed Systems: A Strategy for Very Large Information Systems by Stephan Murer and Bruno Bonati.

Onwards

As a quarterly journal, JEA is always open for new contributions. JEA reaches a large number of enterprise architects, and is a great platform for sharing experiences and contribute to the growing body of knowledge in enterprise architecture as a discipline and profession.

When preparing your manuscript, please follow the format guidelines. And when submitting it, please fill out this submission form.