The Traditional Representation of EA as Static Framework Models

In developing an Enterprise Architecture, practitioners use both textual and graphical representations that comprise an integrated set of composite models that are normally presented in one of the major EA tools.  Once the models are contained in a tool it allows decision makers in an organization or extended enterprise the ability to query across all models the rippling effects of any actual or proposed change.  In this manner, as one banking executive expressed in a personal conversation, “taking a server offline for 30 minutes will affect up to a million and a half transactions in multiple locations.” Likewise a business decision or change in a business process can have a significant impact on technology, data and applications, resulting in many unintended consequences and costs.^1.

Architectural Representations from this Perspective

Architecture is viewed as an explicit representation of the elements of an enterprise, solution or segment and their relationships. Without this explicit representation the enterprise is presumed unable to:

• Prioritize resource allocations between the various competing demands for resources
• Determine the viability of transformation in terms of the impact, need for resources and change, and the ability to achieve the desired end states
• Govern the expending of current resources to determine if they are being correctly applied in achieving the enterprise’s mission
• Boil down transformational objectives crisply into initiatives (and projects that follow) that focus on aspects of the enterprise for change
• Develop roadmaps for modernization
• Develop roadmaps for orderly replacement of obsolete technology and infrastructure
• Develop roadmaps for acquiring skills and specialties in the workforce required to operate the enterprise for the future
   

Enterprise Architecture includes segment architectures of enterprises with top-level strategic plans, goals, and objectives as well as multiple projects and a portfolio of IT investments to manage. The types of questions that such Enterprise level architectures address include:

1. How do the business functions or capabilities relate to enterprise strategy and goals?
2. Are there dependencies among the capabilities or business functions?
3. How will business functions or capability performance be measured?
4. When will the capabilities or business functions be implemented and what projects will provide them?
5. What organizations will use the capabilities or business functions?
6. What organizations are in charge of which projects?

As Sowell² describes, there are seven essential questions for obtaining information to incorporate into models: The information depends on what problem you are trying to solve, but as for examining most problem areas architects should ask:

1. What is the problem that you want to examine?
2. What relevant actions occur in your enterprise?
3. Who performs those actions? 
4. Who needs to communicate with whom in order to perform these activities?
5. What information or goods do they need to exchange?
6. What hardware/software or services (if any) do they use to help them communicate and get the work done?
7. What technical standards do they need to follow?

Asking these questions and gathering the information to answer them can serve as the basis for analysis that will help pinpoint problem areas and develop solutions. 

Another Perspective: Agile, Adaptive and Emergent EA

While this perspective has been useful as a planning tool, it is problematic in implementation and for many enterprise strategic alignments in actual practice.  This is evidenced by challenges such as³:

• Unacceptable numbers of failed large IT projects
• The need for faster tempo of operations resulting in the need to detect and eliminate latencies and reduce the length of the connection to the customer. In the cases of military operations, the need to reduce latency of intelligence, imagery and other situation assessment and operating picture elements to provide better operational planning and execution capabilities;
• Mergers and divestitures where new parts of the IT environments are acquired from merged enterprises bringing in diversity in standards, information representations, architectures, cultures and equipment.
• Globalization where parts of the workforce are located in different regions of the world, with their own cultures and local constraints on power, equipment, languages, and other factors.
• A changing workforce with new ways of interaction and collaboration, different expectations of their work environment, increased exposure to computers, applications, information and networking
• Increasing expenses in information technology as a whole despite dramatic decreases in per unit cost of processing and memory because of labor, need to control obsolescence, evolution of changes in standards and the need to constantly provide faster and faster processing and increasing memory.
• Increases in complexity and scale of IT projects both in terms of scope and reach. Consequent needs for orchestrating work outputs of large numbers of professionals located all over the globe to complete projects successfully. Inability to fully assess impact of complexity and scale at the planning or at the implementation level.
• Rampant adoption of technology based on competitor’s use of technology, vendor push as well as the pressure to align to contemporary standards.
• Rampant outsourcing, based on financial analyses, competitive price pressures as well as the current enterprise focus on the core mission and the decision to outsource all non-critical supporting services.
• Dramatic opportunities posed by evolving architecture styles such as service oriented architectures and cloud computing that change the way systems have been built in the past, and introduce new planning challenges of migrating ponderous current systems infrastructures to a different type of architectural future.

A major issue with the traditional perspective is that enterprise architectures are considered static, and their blueprints are unchanging unless purposefully revised. This view does not account for enterprises as emergent, complex adaptive systems that require an agile approach. One major organizational theorists postulated a number of years ago that “The effective organization is garrulous, clumsy, superstitious, hypocritical, monstrous, octopoid, wandering and grouchy (Weick, 1977).”⁴ This is because organizations/enterprises organically emerge out of the communication patterns that develop in the course of doing business and in response to the host of environmental variables in dynamically changing business landscapes. Enterprises are instances of complex adaptive systems, having many interacting subcomponents whose interactions yield complex behaviors. These dynamic interactions at the local level lead to new emergent organizational structures. Emergent enterprises are inconsistent with the traditional ontological view of an organization as an objectively observable activity. This objective view sees the enterprise as something that can be measured, labeled, classified, and related to other organizational processes. As discussed above, from this perspective, EA considers the enterprise as a static snapshot to serve as a baseline for target architectures.

Contrary to the objective view is the recognition of organizations as complex adaptive systems that give rise to considerations of emergence, leading to a recently derived definition of “emergent enterprise architectures”. This approach identifies organizations as non-linear and highly complex systems, suggesting a rethinking about how they are to be represented within the context of EA. Rather than static structures such as the architecture of a building, the enterprise architecture is an open and highly contingent system:

This view of the enterprise is a respecification of the nature of enterprise problems that are addressed by an adaptive and agile EA. As Russ Ackoff (1987) describes, “In a real sense, problems do not exist. They are distractions from real situations. The real situations from which they are abstracted are messes.  A mess is a system of interrelated problems. We should be concerned with messes, not problems. The solution to a mess is not equal to the sum of the solution to its parts. The solution to its parts should be derived from the solution of the whole; not vice versa. Science has provided powerful methods, techniques and tools for solving problems, but it has provided little that can help in solving messes. The lack of mess-solving capability is the most important challenge facing us.” ⁵ Robert Horn further describes this view of organizational messes⁶,  in that:

• Problems have solutions. Messes do not have straightforward solutions. 
• Messes are more than complicated and complex. They are ambiguous. 
• They contain considerable uncertainty – even as to what the conditions are, let alone what the appropriate actions might be 
• They are bounded by great constraints and are tightly interconnected; economically, socially, politically, technologically 
• They are seen differently from different points of view, and quite different worldviews 
• They contain many value conflicts 
• They are often a-logical or illogical

How to Architect for Emergence in Complex Adaptive Systems

Emergent systems do not necessarily require human intervention. For instance many systems emerge on the basis of swarm intelligence. There are situations in which coordinated behaviors occur without prior planning through communication. They are both common and effective in multi-agent systems – including both biological and computational. Self-organizing complex systems typically are comprised of a large number of frequently similar components or events. Through their process, a pattern at the global-level of a system emerges solely from numerous interactions among the lower-level components of the system. The rules specifying interactions among the system’s components are executed using only local information, without reference to the global pattern, which, as in many real-world problems is not easily accessible or possible to be found. In biological systems such emergence is represented by Stigmergy is coordination through changes to the environment. Stigmergy as a kind of indirect communication and learning by the environment found in social insects is a well know example of self-organization, providing not only vital clues in order to understand how the components can interact to produce a complex pattern. Biological strategies are used to create a system of human collaboration. The information and its organization emerge later – as a consequence of the system being put into operation.

For traditional organizational theorists, as well as business executives (and Enterprise Architects), biological systems will seem to break all the rules of both logic and commonsense. Traditional organizational theory, business strategy, management techniques and enterprise architecture have been based upon the premise that collaborative systems have to be ordered and brought under control. This seemed the only rational way to be able to specify results and to set and achieve goals and targets. The idea that a collaborative system should be deliberately designed to be unstable and chaotic would seem to be utter madness. Yet, this is the way biological systems work. However, biological systems can be highly organized and efficient, and possess abilities to process some kinds of information even better than the most powerful computer systems. 

Philip Agre⁷ offers a substitute for planning, participatory improvisation, “Improvisation, like Planning, involves ideas about what might happen in the future. Improvisation differs from Planning in that each moment’s action results, effectively, from a fresh reasoning-through of that moment’s situation.” Sense is retrospectively made of the interaction through a process Weick calls “sensemaking”. This is consistent with the rethinking of EA in emergent enterprise architecture. 

This proffers a revised approach to doing EA based on what the Gartner group initially described as emergent EA. They contrast this with the traditional model as follows:

This respecification has led to a critique about prevailing views of systems thinking, using document-based approaches and UML-based methodologies to model contents as static, in-coherent, system-perspective views. The traditional technical architectures developed using artifacts from the TOGAF Architecture Content Metamodel and the various types of models represented in FEAF, DoDAF, MoDAF and similar approaches and methodologies, are useful as specifications for integrating current systems and the project portfolios, but also needs to account for developing the dynamic situation awareness architectures required in mission analyses and planning, as well as the complex nature of the postmodern enterprise. 

We need to be aware there are often “good organizational reasons for bad organizational behavior.” What we see at the macro level as a problem often has justifiable reasons when looked at closely. The bad behavior is emergent. As one moves from the global to the local or shop floor level we often “lose the phenomenon.” The enterprise arises from local interaction of often-independent units that exist within a common environment. Each unit or entity interacts with its immediate environment according to a set of low order rules. The combined effects of these lower order interactions within an environment gives rise to higher order organizational phenomenon or organizational culture. Organizational culture emerges from localized interactions, and is grounded at the local level. Hence, culture is highly resistant to change. Changing culture and transforming the enterprise entails re-specifying local level rules rather than simply imposing change from the top. This is the particular value of Active Knowledge Modeling where structures are recognized as dynamic, emergent and adaptive; yet capable of description. Utilizing an emergent enterprise architecture and characterized by such dynamic models proffers a mechanism to initiate positive change.

We have referred to the postmodern view of organizations and to postmodern organizations, and that this has implications for enterprise architecture. In the traditional, or what we can refer to here as modernist, approaches of enterprises, society is characterized as rational, stable and well ordered.  However, in the postmodern approach we contrast value as counter rational, reflexive, and other-oriented global and require networked models for organizational study. In the postmodern organization we see flexible structures where workers are in need of continual learning – which can be understood as emergent knowledge spaces. In the postmodern enterprise, self-managing teams replace top-down management and quality is part of the knowledge process⁸. Rather than management being a role at a point in time, it is now team or project-based. The very concept of a stable blueprint for the enterprise needs to be replaced by one that encompasses agility and recognizes emergence as the basis for changing and to-be models.

This has implications in EA and particularly for the Architecture Development Methodology (ADM) in TOGAF. In the postmodern, non-traditional architecture view the “to be” is a moving target, and the continual iterations of the ADM Phases fluctuate as the enterprise adapts to transitional architectural steps. Consequently the areas of focus transform into ellipse change cycle patterns. Interaction and interference from different areas of focus is to be expected, and requirements management takes on a “hive” or swarm intelligence structure. This raises a new set of concerns:

• Is there a need to change the language of architecting?
• Is there a need for a more dynamic approach showing adaptation over time?
• Perhaps architecture artifacts of the future will become more like films, only with the animation drawn out over a much longer period of time?
• Should we model clusters, swarms, and centroids of architectures, with some level of coupling (tightly or loosely) and generalized functionality across the sub-architectures (for example, generalized audit trails for SOA-based systems)?
• Will future focus be increasingly on user experience driven design, while constrained by QoS necessities and cost of resources?
• What is the role of knowledge modeling as artifacts? 
• How can we create an acquisition process that allows for emergence?

In conclusion we need to consider architecture as a crucible that entails the trade-offs between resource availability and constraints, along with meeting organizational/enterprise goals and user experience. Agile is a set of actions that focuses and models the results to meet acceptance criteria, while enabling ongoing adaptation and accounting for emergence. Architecture is the representative artifact of the solution. We must consider how agile augments and changes architecture methods to produce solutions that embrace greater user experience, while enabling adaptation. We must recognize how architecture brings focus and system discipline to agile.

Authored by: Dr. Beryl Bellman, PhD Principal Instructor

Note: This discussion is drawn from an earlier published paper on Emergent and Adaptive EA co-authored with Ken Griesi and Mark Bergman of MITRE.

CItations:

1. See Rao, Reedy and Bellman, 2011
2. FEAC Book on Enterprise Architecture, University Readers, 2007
3. See Rao, Reedy and Bellman, Certified Enterprise Architect All-in-On McGraw Hill 2011, chapter 2
4. On Re-Punctuating the Pre Exam Guide 
5. Ackoff, Russ, The Art of Problem Solving, 1987, Wiley
6. Horn, R. E. (1998) Visual Language: Global Communication for the 21st Century, Macro VU, Inc. Bainbridge Island, WA
7. Philip Agre Computation and Human Experience, Cambridge University Press (July 28, 1997)
8. See Hatch, 2006, Organizational Theory: modern, symbolic and postmodern perspectives

References:

• Bellman, Beryl (ed.), The FEAC Book on Enterprise Architecture, 2007, University Readers
• Hatch, M., Organizational Theory: modern, symbolic and postmodern perspectives, Oxford University Press, 2006
• Lillehagen, F and Krogstie, J. Active Knowledge Modelling of Enterprises, Springer 2008
• Rao, P, Reedy, A and Bellman, B., The FEAC Guide to Enterprise Architecture Certification, McGraw Hill 2011
• Ross, Weil and Robertson, Enterprise Architecture As Strategy: Creating a Foundation for Business Execution, HBR Press, 2006
• TOGAF 9.2 Van Haren Publishing; 11th edition, 2018
• Weick, Karl On Re-Punctuating the Problem in New Perspectives on Organizational Effectiveness; Jossey Bass 1977