Enterprise architecture management, a theory of constraints, formal trade-off analysis methods and game theory

This article was submitted by Dmitri Ilkaev. Dmitri has over 20 years of experience in technical leadership and IT Strategy development that aligns with business drivers and objectives. He holds a Master’s degree in Physics from Moscow State University as well as a Ph.D. in Computer Science from Moscow Institute of Physics and Technology. Dmitri worked as Vice President, Engineering for Choice Hotels International and has held various executive positions in IT Architecture at companies such as SunTrust Banks, Bank of the West, Thermo Fisher Scientific, Unisys and Tier Technologies.

Currently, Dmitri works as a Director of Enterprise Architecture at Rogers Corporation.

We are looking at the Enterprise Architecture as actionable and adaptable blueprints, evolving through the multiple lifecycles. It factors in frequently changing stakeholder requirements and market trends, whilst reacting to the business strategy, and incorporating lessons learned from the business and IT operations, etc. We also operate with the EABOK (EA Body of Knowledge) which is a collection of common EA artifacts and deliverables, such as current and future states, business capabilities mapping, technical domain reference architecture, and respective roadmaps.

For the purposes of this article, we should also introduce EAM – enterprise architecture management. Wikipedia (https://en.wikipedia.org/wiki/Enterprise_architecture_management) describes enterprise architecture management as a “management practice that establishes, maintains and uses a coherent set of guidelines, architecture principles and governance regimes that provide direction and practical help in the design and development of an enterprise’s architecture to achieve its vision and strategy.”

CIOIndex (https://cio-wiki.org/wiki/Enterprise_Architecture_Management_(EAM)) provides additional details:

Enterprise Architecture Management (EAM) is the practice of enabling and driving business value using enterprise architecture. EAM sets the direction, strategy, and governance for enterprise architecture planning – vision, mission, goals, guidelines, policies, principles, communications, monitoring, control, and other activities that ensure the development and deployment of enterprise architecture in support of business value.

EAM sets the direction for all activities related to enterprise architecture
EAM connects business strategy and enterprise architecture
EAM uses enterprise architecture for business transformation
EAM promotes collaboration between all the stakeholders in the enterprise

Large-scale transformation efforts affect multiple domains and layers within an enterprise, performed simultaneously in different projects and programs. Providing coordination in the course of enterprise transformation aims to ensure that the overall transformation targets are met, and that the enterprise as a whole evolves in a consistent way. The rationale behind EAM is that an approach focusing solely on local optimization within projects, without having an overarching coordination mechanism, will not necessarily lead to the development of the enterprise in the intended direction.

We should note that there are multiple views/representations of similar things; in such a way EAM can be viewed as a flavor of TOGAF ADM, and EABOK as the TOGAF Enterprise Continuum, if a reader is more inclined to follow one or another of the established EA frameworks.

In EAM/EA space we are quite familiar with the need to consider multiple options for solutions, analyze their pros and cons and try to find an acceptable tradeoff to satisfy the requirements coming from different stakeholders. The first good step is to apply the formal trade-off analysis method in order to find an optimal solution. The Architecture Tradeoff Analysis Initiative at the Carnegie Mellon Software Engineering Institute (SEI) has developed a number of architecture-centric methods including:

the SEI Architecture Tradeoff Analysis Method (ATAM),
the SEI Quality Attribute Workshop (QAW),
the SEI Cost-Benefit Analysis Method (CBAM),
the SEI Active Reviews for Intermediate Designs (ARID), and
the SEI Attribute-Driven Design (ADD) method.

We find ATAM and CBAM, used in combination, as the most practical approach to performing this trade-off analysis.

ATAM is a structured process to assess the consequences of architectural decisions, in light of defined quality attributes, which are essentially a collection of non-functional requirements. The CBAM takes the architectural decision analysis done during the ATAM, and through the introduction of the utility function and its optimization, helps make it part of a strategic roadmap for software design and evolution. It does so by linking such parameters as priorities, costs, and benefits with architectural decisions. In general, the CBAM utility function can be extended to a multidimensional function combining inputs, outputs and constraints of the EA analysis, together with the derived quantitative benefits in the form of ROI, TCO, etc. Developing optimal solutions would be in finding the combination of the parameters resulting in the maximum value of the derived benefits, or applying a formal optimization technique to determine the global or local extrema of this multi-parameter utility function.

We feel that moving such ATAM/CBAM analysis to the enterprise level and applying the theory of constraints (TOC), will be the next important step in the decision-making process and evolution of EAM practices. As Jack Vinson wrote in his blog (https://www.jackvinson.com/blog/2018/5/2/enterprise-architecture-and-toc-tocico18) :

“TOC comes into the picture in the direction of the questions. Where is the constraint inside the organization? What blocks flow in operations? What about the customer? What changes are required to remove limitations for them? What does the customer need? What about the larger ecosystem of suppliers, partners, and customers – how does the current system block or slow flow of value? What needs to change to improve the entire ecosystem?”

In such a way, an EA driven analysis will look as depicted below.

Figure 1. EA analysis and recommendation process

We need to note, that EA is not a decision-making function, it provides recommendations based on their understanding of requirements, constraints, and interpretation of the priorities and acceptable tradeoffs for different stakeholders. During the decision-making process, additional requirements, constraints, and factors may arise, and this analysis (or some of its parts) may be reiterated several times in order to achieve acceptable outcomes.

At the enterprise scale, it is a highly repeatable process, as business and IT strategies always evolve. This results in the continuous need to perform such analysis and come up with the decisions related to changes in technology, processes, vendor engagement and quite a few additional problems, where EA is one of the stakeholders and the driver of the analysis process.

Quite often, stakeholders’ requirements are considered as independent, and the history of stakeholder interactions and collective decisions is also not taken in the account.

As Ahlemann et al. had been pointing out: “In an organizational context, stakeholders are mutually dependent on each other’s actions: To achieve an organizational goal, each stakeholder has to choose a particular action. The organizational goal, e.g. the intended transformation result, is reached only if all involved stakeholders choose the appropriate action, i.e. if they coordinate on cooperative behavior. However, stakeholders’ individual goals may agree or conflict with organizational goals and may also be influenced by the actions of their peers: For example, a group of line managers may want to choose a particular action only if they believe their peers will do the same.”

A good way to describe interactions between stakeholders, taking into account stakeholders’ actions mutually influencing each other, is provided by game theory. Game theory formalizes the behavior of players and provides a classification system for decision handling between people. It describes the coordination situations in terms of games played between players, and analyzes the different payoff matrices. By doing so it helps to define the requirements for coordination support in different scenarios, which will be influencing EAM outputs as well. Of course, transparency and visibility of EAM information to stakeholders is a key requirement in all game strategies in our context. We will not explain here Nash Equilibrium and Pareto Efficiency, but they are two main dimensions that game strategy efficiency is being evaluated against.

Game theory comes with different interaction models (called games) and related strategies, from classic prisoners’ dilemma, to the more sophisticated but closer to reality coordination game. Stakeholders know each other and run the decision-making process repeatedly. Stakeholders also remember past actions of their peers. In many game simulations, players can realize a higher benefit by collaborating, especially when they are willing to sacrifice some personal utility to work towards a common goal. As an example, this YouTube movie https://www.youtube.com/watch?v=BOvAbjfJ0x0 visualizes the impact of different strategies in an iterated prisoner’s dilemma game. With this in mind, the analysis and decision-making process will look as below:

Figure 2. EA-driven decision-making process

Conclusion

An established EA practice delivers information in a manner that enables effective decision making. Enterprise Architecture Management addresses the establishment and continuous development of EA. It controls the evolution of EA, and business change, from an architectural perspective and becomes a strong enabler of enterprise transformation. EAM is driven by business and IT-related scenarios, based on stakeholder goals. Identifying conflicting stakeholder needs and perspectives, and coordinating between them, is one of the critical EAM challenges. Providing a game theory-driven perspective on stakeholder motivations and payoffs, influencing their behavior and integrating this perspective into the structured constraint-based EA driven analysis and decision-making process, is the next step in the evolution of EAM, serving as a critical decision support function.

References: