Author: Con Kenney

If we define an EA as a store of information that people use to make decisions, it’s reasonable to ask the ways in which the information is organized and the decisions that need to be managed. EA provides several constructs for organizing information such as frameworks, controlled vocabularies, taxonomies or reference models, patterns or reference architectures, and methodologies. An additional construct, the narrative, may help us understand help us understand key differences between the varied types of EA information and identify ways to improve EA practice.

Merriam-Webster defines “narrative” as a “story or account” and as “a way of presenting or understanding a situation or series of events that reflects and promotes a particular point of view or set of values.” The latter definition is useful for the purposes of this discussion.

If we look at an EA as a set of narratives, each containing a different kind of information and making different truth claims, some of the complexity of an EA may become tractable. The practice of enterprise architecture supports many different types of decisions, so the importance of the EA narratives and order of their development depends on the information requirements of the specific decisions targeted by the EA effort.

A typical EA includes descriptive information about the structures, activities, products, and assets of an organization. Common names for the Descriptive EA narrative are ‘the current state’ or the ‘As Is.’ This part of the EA claims that these structures, activities, products, and assets exist and can be verified by other people. We could factually verify the descriptive EA narrative’s truth claims by enumerating and inspecting the assets, for example. Important consumers of this narrative might be business and IT analysts gathering requirements for a project, who require accurate information. The business and IT analysts might be interested in the interactions of two business processes or the number of devices using a particular operating system. Many routine IT-operations decisions depend on the Descriptive EA. This can also also inform business process improvement or software development projects.

Another EA narrative is concerned with predictive information about the structures, activities, products, and assets of an organization. Common names for the Predictive EA narrative are ‘the future state’ or the ‘To Be.’ This part of the EA claims what structures, activities, products, and assets will exist at one or more specified times in the future. As it is difficult to verify such claims, one relies on the agreement of organizational decision-makers and the available standards to verify Predictive EA claims. Important consumers of the descriptive narrative might be organizational decision makers making tradeoffs between different strategies, and they would expect the information to reflect their views in strategic plans and budgets. The organizational decision makers might be interested in the amount of planned change in a business unit or the impact of new competencies on innovation. Many strategic planning decisions depend on the Predictive EA that can also inform organizational redesign or standards development projects.

A third EA narrative, the Coordinative EA, includes information about planned changes to the structures, activities, products, and assets of an organization. A common name for this narrative is ‘the transition state.’ This part of the EA claims that these structures, activities, products, and assets are to be added, dropped, or altered within a specified time frame and that other people have been informed of these changes. The verification of Coordinative EA narrative’s truth claims can be done by reviewing project plans, budgets, and change management records. Important consumers of the Coordinative EA narrative might be project managers examining interdependencies between projects, and they would expect the information to be substantially accurate; the Coordinative EA is more dynamic than the Descriptive EA or the Predictive EA, so there is a greater likelihood of the EA being out of date sometimes. The business and IT analysts might be interested in the interactions of two business processes or the number of devices using a particular operating system. Many adjustments to project plans depend on the Coordinative EA that can also inform budgeting or standards development projects.

The Descriptive EA, Predictive EA and Coordinative EA narratives usually share a framework and are structured much the same. The reason these similarities are important is that they enable us to make comparisons across the three narratives using the same kinds of information. The one exception is that the coordinative EA includes a project view that is absent from the Descriptive EA and Predictive EA. This results in simpler and cheaper information gathering and analysis for EA consumers. Generally, we should expect that the differences between the Descriptive EA and Predictive EA narratives are explained by the Coordinative EA. For example, if a business process appears in the Descriptive EA and does not appear in the Predictive EA, we should see a project in the Coordinative EA that eliminates or outsources that process.

A fourth EA narrative, the Prescriptive EA, includes information about current, planned, and potential standards for the processes, information, and technologies of an organization. A common name for this narrative is ‘technical standards’ or ‘technology reference model.’ This part of the EA claims that these current standards for processes, information, and technologies have been defined explicitly, there is process for adding future standards, and that an authorized person or group have approved these standards. The factual verification of Prescriptive EA narrative’s truth claims can be done by reviewing the records of the standards decisions of the person or group. Important consumers of the Prescriptive EA narrative might be technology managers considering the adoption of new technology across an organization, and they would expect the information to be totally accurate. Given the pace of change of processes, information, and technologies, the prescriptive EA is likely to be incomplete. The technology managers might be interested in the definition of a technical standard or the progress toward selecting a single, required technology for the organization.

The implications flowing from the EA being composed of different types of narratives are significant. An EA is complex both in the amount of information it stores and in the frequency with which that information changes; this detail and dynamic complexity makes developing and managing an EA a challenge. The nature of EA depends on the organizational decisions it supports, and, as each organization is unique, the content of its EA and processes for making decisions and compiling information will also be unique. While common methodologies are very helpful, the path for each EA is different from all others, and enterprise architects may have to develop new sources and methods for their EAs. In studies of commercial and government EA efforts, researchers have noted that decision makers report enterprise architects devoting too much energy to the Descriptive EA or current state. Indeed, enterprise architects can demonstrate the factuality of the information in the Descriptive EA, and it’s easy to understand why people would be more comfortable providing information they can prove is correct. The value to decision makers of this kind of information may be low, however, as much of it is already known.

Further Reading

1. Boucharas, Steenbergen, Jansen, and Brinkkemper. The Contribution of Enterprise Architecture to the Achievement of Organizational Goals: A Review of the Evidence.
2. GAO. (2002). INFORMATION TECHNOLOGY: Enterprise Architecture Use across the Federal Government Can Be Improved. Washington: Government Accountability Office.
3. GAO. (2003). INFORMATION TECHNOLOGY: Leadership Remains Key to Agencies Making Progress on Enterprise Architecture Efforts. Washington: Government Accountability Office.
4. GAO. (2010). ORGANIZATIONAL TRANSFORMATION A Framework for Assessing and Improving Enterprise Architecture Management (Version 2.0). Washington: Government Accountability Office.
5. IDS Scheer. (2009). Why two thirds of Enterprise Architecture projects fail: An explanation for the limited success of architecture projects.
6. Simon, D. (2013). An Exploration of Enterprise Architecture Research. Communications of the Association for Information Systems. Volume 32, pages 1-72.
7. Turner, Mark. (1998). The Literary Mind: The Origins of Thought and Language. New York: Oxford University Press.