10.2 Enterprise Architecture Management Frameworks

Enterprise Architecture

There are many activities/business processes associated with an enterprise; however, its focus is on activities that allow it to meet current and future objectives. A business process is a series of steps a group of stakeholders performs to achieve an enterprise concrete goal or set of objectives. Current objectives reflect an enterprise’s mission and short-term strategies, while future objectives reflect their vision and long-term strategies. To ensure successful development and execution of these strategies in either the short or long term, an enterprise will rely on EA as shown in Figure 10.10.

Figure 10.10 The goal of EAM is to provide enterprise capabilities to keep business solutions aligned with the enterprise strategy. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

As illustrated in Figure 10.11, EA follows the requirements of a preestablished operating model, helps establish meaningful strategic boundaries, supports the management of core business capabilities that enable the development of a business platform for the execution of routine business tasks, and allows people to concentrate on improving the business rather than just purely running it. A foundation for execution is a combination of IT infrastructure (i.e., hardware, software, communication, and data) and digitized processes that automate the company’s core business capabilities. The goal of the foundation for execution is to develop alignment between business and IT strategy. Creating and maintaining a foundation for execution relies on the company’s operating model, strategy adoption road map, and a view of its reference architecture. A road map is used to guide an organization with planning and achieving business goals over time through technology.

Figure 10.11 This figure depicts the EA foundation design for execution. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Figure 10.12 illustrates various operating models known as diversification, coordination, replication, and unification. These models correspond to variations in the way business processes are standardized and integrated.

Figure 10.12 Operating models known as diversification, coordination, replication, and unification correspond to the way business processes are standardized and integrated. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

The enterprise IT strategy is based on a collective set of principles. These principles form a consistent framework for technology decision-making and reflect a level of consensus among key stakeholder technology groups. The technology groups include senior leadership, the architecture council, and leading architects. Figure 10.13 shows the principles are intended to guide decision-making at all levels and are organized as a business, information, application, and infrastructure.

Figure 10.13 The organizing framework includes information security principles, technology delivery principles, enterprise architecture principles, and architectural design principles. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Figure 10.14 summarizes typical enterprise capabilities within various business units such as manufacturing, corporate, and technology.

Figure 10.14 Typical enterprise capabilities within various business units such as manufacturing, corporate, and technology are shown. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Investment in technology may have possible impacts, such as goals, desired expectations, and metrics. In the goals, we estimate many factors, such as the required time, the deliverables information, the cost of quality, and the outputs. In the desired expectation, we evaluate the project (e.g., right project, right cost, right timing, and right resources). In the metrics, we measure the investment demand, employee satisfaction, and quality of service (i.e., availability and cost). Figure 10.15 illustrates the possible impact of investment initiatives in technology capabilities as they are arranged in the plan and solution section, built into the solutions section, and deployed into products delivered to customers. The process will start with planning solutions and investments, then building solutions, and, finally, running solutions.

Figure 10.15 There are many possible impacts of investment initiatives in technology capabilities. Each section lists the assigned capabilities and/or impacts. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Business and technology executives are responsible for ensuring that an IT project achieves division-wide and company-wide objectives by engaging with the enterprise architects. EA is an evolving practice that takes time, investment, and patience. It should provide a strategic framework for organizations to handle technological disruptions by aligning IT systems with business goals while helping decision-makers implement changes that drive innovation, resilience, and efficiency to ensure short-term initiatives and long-term projects can contribute to the success of the company.

A leading health-care organization aimed to reduce operational costs while streamlining patient care. They used EAs to identify the need for a unified data system. The system needed to integrate patient records, billing, and telemedicine services. The EA team presented recommendations, including adopting cloud-based platforms and automated workflows. This helped the organization handle business disruptions, minimize data silos, and improve service delivery. The project aligned with division-wide objectives, showcasing how EA practices can drive strategic transformation in response to industry challenges.

Aligning Business and Technology Strategies

Aligning business and technology strategies is typically difficult on an ongoing basis because of the lack of alignment with enterprise-driven initiatives. Enterprise architecture helps align business and technology strategies, as illustrated in Figure 10.16. This alignment is a continuous process and is achieved through the business-IT alignment life cycle.

Figure 10.16 The business-IT alignment life cycle is a continuous improvement process that helps align business and technology strategies. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

The business IT alignment life cycle helps organizations align their business goals with IT strategies through different stages. The first stage is initiation, which involves checking the problem facing the enterprise or available opportunities. The second stage is strategy, which involves designing solutions. The third stage is planning, which involves planning how to implement the solution. The fourth stage is execution, and it involves implementing the solution. The last stage is assessment, which entails evaluating the solution.

The enterprise team should be careful when developing business IT alignment because enterprise business solutions may lack alignment with the enterprise-driven initiative. In other words, business solutions should take into account the architectural guidelines that are set forth at the enterprise level and not just reinvent the wheel. Figure 10.17 shows the four symptoms that may lead to the lack of alignment.

Figure 10.17 When the four symptoms do not overlap, enterprise business solutions lack alignment with enterprise-driven initiatives. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

The first symptom appears when the created solution is not aligned with the enterprise goal. The second one appears when the business solutions are not delivered on time and on budget or if the outcome doesn’t reach the expected quality. The third one appears when it’s difficult to maintain the system or the solution. The fourth symptom appears when it’s hard to evolve the business solutions.

In addition to the alignment, enterprise architecture management uses enablers to provide enterprise capabilities to keep business solutions aligned with the enterprise strategy. An enabler supports the activities needed to extend the architectural runway to provide future business functionality. Figure 10.18 shows five different kinds of enablers, which are listed in Table 10.1.

Figure 10.18 Enterprise architecture management provides enterprise capabilities, known as enablers, to keep business solutions aligned with the enterprise strategy. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Figure 10.19 This figure shows how the generic EAM Awareness-Desire-Knowledge-Ability-Reinforcement change management methodology applies in the context of a Business Pattern-Driven Modeling process pattern. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Enterprise Architecture Frameworks

EAM is 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. EAM brings the highly distributed knowledge of all experts to the table and allows every participant to provide such knowledge and input in terms that best fit the experience and expectations of the contributing stakeholders.

As EA and EAM regard the enterprise as a large and complex system or system of systems,³ it is necessary to manage the scale and complexity of this system. To address this requirement, an enterprise architecture framework (EAF) provides tools and approaches that ensure that enterprise solutions are in alignment with the evolving vision and strategy of the organizations that use these solutions to operate and conduct day-to-day business. EAFs provide structured guidance that is divided into three main areas:

1. Descriptions of architecture: how to document the enterprise as a system
2. Methods for designing architecture: overarching enterprise architecture process composed of phases and broken into lower-level processes composed of finer-grained activities
3. Organization of architects: guidance on the team structure and the governance of the team, including the skills, experience, and training needed

To describe architectures, EAFs employ flexible data models built upon metamodels that provide evolving outlines for capabilities and relationships. At a high level, EAFs provide foundational principles, an organizing framework, a comprehensive and consistent method, and a set of governing processes and structures, as illustrated in Figure 10.20.

Figure 10.20 This high-level view of EAF reference architecture shows the main components: principles, framework, method, and governance. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

The reference architecture is built upon principles. A principle forms the foundational rules that guide its design and implementation. The reference architecture uses architectural terms as well as numerous principles, policies, and guidelines to govern the architecture. The framework serves as the organizing structure and outlines architectural domains and disciplines to ensure separation of concerns and alignment between business goals and IT. The method consists of defined, repeatable processes that ensure a consistent and controlled execution of the reference architecture. The processes and organizational structures that ensure adherence to the reference architecture are considered governance.

As the practice of EA evolves, the supporting EAF frameworks that enable communities and enterprises to apply EA also evolve. Indeed, as solution complexity increases, the ingenuity needed to master it must continuously improve. In fact, architecture strategies keep playing an enormous and ever-increasing role in determining whether an enterprise is successful. The next generation of EAFs is focused on enabling the creation of dynamic ecosystems and related architectures that provide value for all business participants via systems of insight that integrate and facilitate decisions across systems of record (i.e., focus on costs), systems of operations/automation (i.e., focus on operational expense [Opex]), systems of design (i.e., focus on innovation), and systems of engagement (i.e., focus on customer experience). Figure 10.21 shows the evolution of EA frameworks that has taken place over the years.

Figure 10.21 This chart shows the relationship representation of IT/business drivers and IT evolution over time. The evolution ranges from the mainframe to smart computing. The next-generation EA framework will optimize human, physical, and environmental assets. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

The architecture subsumed by this new breed of ecosystems is illustrated in Figure 10.22. It relies on various layers that can be modeled (using next-generation EAFs) as follows:

• Trust models ensure that all participants within the ecosystem share and agree on additional values rather than just operate only for financial profits (e.g., respect privacy, guarantee security, provide customer-oriented value and social values, improve the level of quality) as well as shared outcomes, including externalities such as pollution or regulation.
• Business models ensure that the values identified in trust models are shared and business models can be established that split the margin and revenue between ecosystem participants.
• Orchestration models optimize the split of responsibilities and orchestrate services to deliver the best values for customers at the right price/quality (e.g., the links navigation digital experience journey or the knowledge flows journey maps to services and processes at the ecosystem level). Shared services models include supporting data and application services.
• Business networks enable the sharing of processes and data; for example, cloud applications shared between partners in digital business networks via a mix of shared and multitenancy architectures.

Figure 10.22 Using next-generation EAFs, various layers can be modeled as trust models, business models, orchestration models, shared services models, and business networks. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

To provide adequate support, next-generation EAFs must supply an extensive set of generic capabilities as part of an underlying meta-framework. A meta-framework describes the framework in more detail, as illustrated in Figure 10.23. Clearly, these capabilities go beyond modeling and related features and must be spanned across EAF requirements for IT automation, IT governance, and IT context management. IT automation is the process of creating systems to reduce manual intervention. IT governance is the process that ensures the effective and efficient use of IT in enabling an organization to achieve its goals. IT context management is a dynamic IT process that uses data in one application to point to data resident in a separate application.

Figure 10.23 EAF requirements for IT automation, IT governance, and IT context management are shown. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

There are many examples of EAFs, such as TOGAF, Gartner Enterprise Architecture, C4ISR, CORBA, Federal Enterprise Architecture, Zachman Framework, and many more. Each one of the EAFs follows a specific format and uses a different specification.

Table 10.2 shows examples of EAFs and their specifications.

The Open Group Architecture Framework

The Open Group Architecture Framework (TOGAF) is an EA methodology and framework used by leading organizations to improve business efficiency. TOGAF focuses on elements of consistent methods, standards, and communication. TOGAF enables organizations to pursue a systematic approach toward the development process in order to reduce errors, manage timelines, stay within planned budget and scope elements, and have efficient processes to produce quality results. TOGAF helps practitioners avoid being locked into proprietary methods, utilize resources more efficiently and effectively, and realize a greater return on investment.

In 1995, the original development of TOGAF Version 1 was published as a reference model for enterprise architecture, offering understanding into the U.S. Defense Department’s (DoD) own technical infrastructure, including how it’s structured, maintained, and configured to align with specific requirements (Figure 10.24). As of today, the TOGAF is a detailed method and a set of supporting tools for developing an enterprise architecture. It may be used freely by any organization desiring to develop an enterprise architecture for use within that organization.

Figure 10.24 This timeline shows the development of TOGAF over time. The first version was in 1995, and the most recent version was in 2018. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

TOGAF is the widely used framework to establish and define enterprise architecture; it presents an approach to planning, designing, implementing, and governing the enterprise-level information technology architecture of the organization. It mainly focuses on four modular structures, which include application, business, technology, and data. The main purpose of defining the TOGAF framework was to have an architectural model that can be replicated with few errors in each progressing phase. Establishing a common language and understandability mechanism bridges the gap between IT and the business by bringing clarity to the information, establishing methodology, and having practical implementation guides.

The TOGAF standard includes the Architecture Development Method (ADM), which is a detailed step-by-step process for developing or changing an enterprise architecture. It also allows for changing a content framework to help drive greater consistency in the outputs that are created when using the ADM (Figure 10.25). The TOGAF content framework provides a detailed model of architectural work products. Common system architectures are used by many enterprises. Industry architectures are industry-specific, while organizational architectures are company-specific.

Figure 10.25 The most generic component of the continuum is the foundation architecture, which is usable by any IT organization. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

The categories of patterns are specification patterns, vision patterns, process patterns, governance patterns, migration patterns, usability patterns, information patterns, business patterns, and interoperability patterns. The phases suggested by the ADM are as follows:

• Preliminary Phase. This phase defines enterprise principles, IT principles, and architecture principles (i.e., how do we do architecture?). It is not considered a part of the ADM cycle, as it may be revisited at any point throughout the cycle. This phase involves the organization and governance of the architecture, its general principles, methods, tools, and the architecture repository, and is the jumping-off point during which an organization starts an ADM cycle. The outputs of this phase are framework definition, architecture principles, and reference to an organization’s principles and goals.
• Phase A: Architecture Vision. This is the first phase of the ADM cycle and begins with the receipt of a request for architecture work within a sponsoring organization. During this phase, an organization establishes the project, identifies business goals, reviews architecture and business principles, defines the scope and constraints of an architecture effort based on an assessment of resource and competence availability, and identifies stakeholders and business requirements. A vision is developed regarding the project’s organization, orientation, road map, baseline architecture, and risks. In the end, a business has a document statement of architecture work to submit for approval. Phase A is where the organization answers the questions of where we are going, how we are getting there, and with whom.
• Phase B: Business Architecture. During this phase, an organization describes the baseline business architecture that currently exists and the target business architecture that they will work to implement. The next step is creating business architecture models, organization structure, business goals and objectives, business functions, business services, business processes, business rules, correlation of organization and function, and trade-off analysis reports. To accomplish this, gap analysis and modeling must be performed for and between the baseline and target business architectures. The gap analysis includes people, processes, tools, information, measurement, financial, and facilities. Such modeling may include a variety of tools, including activity models, use-case models, class models, node connectivity diagrams, and information exchange matrices. Figure 10.26 illustrates common activities among several phases.

Figure 10.26 Phases B, C, and D of TOGAF AMD represent multiple activities that include describing the baseline architecture, describing the target architecture, measuring gaps, evaluating impact, and drafting the road map. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

• Phase C: Information System Architecture. Information system architecture is composed of data architecture and application architecture subphases. The design framework that structures how data is collected, stored, managed, and utilized within a system is called data architecture. The patterns used to design and implement an application are considered its application architecture. The objective of this phase is to develop target architectures covering either or both subphases, depending on the project scope. The business processes supported in this phase are those that are supported by IT, as well as the interfaces of those processes with non-IT-related processes.
  Data architecture reviews and selects principles, reference models, viewpoints, and tools. It creates data architecture models for each viewpoint, such as the C4ISR Architecture Framework and conceptual data model map to business architecture. Then, it performs trade-off analysis, completeness, and conformance. After that, it selects data architecture building blocks, conducts check point review of the architecture model, reviews qualitative criteria, completes the data architecture, conducts checkpoint/impact analysis, performs gap analysis, and creates reports.
  Application architecture subphases develop a baseline applications architecture description; review and validate application principles by selecting reference models, viewpoints, and tools; create architecture models for each viewpoint; identify candidate applications (i.e., business architecture and data architecture); conduct checkpoint review; review the qualitative criteria; complete the applications architecture; perform gap analysis; and create report.
• Phase D: Technology Architecture. The purpose of this phase is to develop a technology architecture that defines the platforms and execution environments on which the organization’s applications run and the data sources are hosted. The key steps involved in this phase are:
  1. Develop the baseline technology architecture description to the extent required to support the target technology architecture.
  2. Develop the target technology architecture by considering different architecture reference models, viewpoints, and tools. Then, create an architecture model of building blocks, select the services portfolio required per building block, confirm that business goals and objectives are met, choose the criteria for specification selection, complete the architecture definition, and conduct gap analysis.
• Phase E: Opportunities and Solutions. Phase E identifies the key business drivers, the change parameters, the major phases required, and the projects that are undertaken to move the organization to the target environment. Phase E reviews gap analysis (i.e., studying the gap between the current system and the future system), performs architecture assessment, and identifies software packages for projects. This phase also involves the study of the technical, organizational, and financial requirements and constraints of the project.
• Phase F: Migration Planning. During this phase, the various projects required to implement the architecture are sorted into priority order based on dependencies and the cost-benefit assessment of the various projects. Migration schedules (i.e., outline the timeline, tasks, and resources needed), risk assessment (i.e., identifying and analyzing potential risks), project goals (i.e., defines the goals and outcomes), project constitutions (i.e., outlines the main principles of the system), implementation road map (i.e., steps to follow in the implementation), and project organizations are established.
• Phase G: Implementation Governance. This phase establishes the final version of architecture contracts that govern the overall implementation and deployment process and involves developing recommendations for each implementation project. Implementation governance functions to ensure implementation projects conform to the defined target architecture. The steps in this phase are:
  1. Formulate project recommendations
  2. Document architecture contract
  3. Establish architecture compliance review process
• Phase H: Architecture Change Management. This phase establishes the process through which the deployment of the architecture is managed. Architecture change management provides for continuous monitoring of factors that may affect the implementation process, such as change requests, new developments in technology, or changes to the business environment. Such factors may trigger new ADM cycles as the project evolves. The steps involved are:
  1. Monitor technology changes
  2. Monitor business changes
  3. Assess changes
  4. Hold architecture board meetings

TOGAF’s foundation architecture sets forth the following:

• Architecture building blocks and standards
• Generic services and functions to build specific services
• Technical reference model
• Standards information base

TOGAF also provides an Enterprise Continuum that addresses the Architecture Continuum and the Solution Continuum, and an Architecture Governance with guidelines relating to the following:

• Management and control of architecture works at an enterprise level
• Repositories
• Process flow control
• Architecture board, including architecture compliance and contracts
• Process and content details (Table 10.3)

Strategic Adoption Road Map

EA is typically used by companies to produce a blueprint of the future state and a road map for getting there.

Companies’ shift to lean and flexible operating models directly affects how their IT workforce architects design future business solutions, wherein it needs to enable the new operating model by advancing business capabilities through efficiently integrated and standardized business processes and corresponding solutions. EA ensures the alignment of business architectures with solution architectures by providing a holistic view that links all architecture domains through an enterprise reference architecture (ERA).

The result of this work, which is produced through an integrated planning process and methodology, aligns and sequences IT investments to optimally achieve the companies’ strategies. The assembly of the road map draws upon three distinct architectural domains:

• Business architecture
• Business solutions architecture
• IT solutions architecture

The adoption road map results from implementation planning, as illustrated in step 8 of Figure 10.27. Creating a road map requires a current state assessment, future state definition, and gap analysis.

Figure 10.27 These are the steps of adopting a road map. The first step is current state assessment followed by future state definition, and the last step is road map implementation. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Creating a future state model definition requires an understanding of future state needs and the definition of a target strategy based on various business and IT drivers, as illustrated in Figure 10.28.

Figure 10.28 Business and IT drivers define the future state need and how it will be validated by individuals and stakeholders. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Developing business drivers requires an evaluation of the dynamics of change that are necessary to keep sustaining the business. Businesses often use the five Porter forces illustrated in Figure 10.29 to analyze business dynamics. To ensure that a product competes in the market, you should study these factors: is there any barrier to entering the market? Are there any competitors competing with your product’s price? Is there any threat of substitute products? What is the buyer and supplier power?

Figure 10.29 Analyzing business dynamics using the five Porter forces: entry barriers, internal rivalry, threats of substitutions, supplier power, and buyer power. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Enterprise Business and Technical Architectures

A reference architecture diagram may be used to create a view of a company’s enterprise architecture. For example, fictional Airlines opted for a unification operating model, and its reference architecture is depicted in Figure 10.30. In the current competitive environment, Airlines concentrates on products and services through the value chain to increase customer satisfaction and the company’s profit.

Figure 10.30 Airlines’ enterprise architecture includes the customer experience pipeline to support the Airlines system with events and to create relationships between the records. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Figure 10.31 illustrates how various business and enterprise technical architecture assets may be represented. The technical architecture is divided into three layers: future state business capabilities models (e.g., Management Liability, Claims, Finance, and MIS stakeholders), business needs for the next three to five years, and the technology architecture model to support the evolving business needs with respect to best practices and strategic IT goals.

Figure 10.31 The technical architecture is divided into three layers: future state business capabilities models, business needs, and the technology architecture model. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

These assets are architectural drawings referred to as blueprints and are stored in an asset catalog according to their domains and levels of abstraction. Different UML models and blueprints provide high-level architectural details meant to help visualize the big picture. Figure 10.32 shows different levels of abstraction, including conceptual, logical, and physical.

Figure 10.32 Focusing more on an application domain in the enterprise provides more details about the level of abstraction. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Enterprise Architecture Process Frameworks and Related Patterns

Various process patterns may be applied to create enterprise architecture assets. EAFs such as TOGAF implement specific processes and provide patterns and templates that may be followed to derive enterprise architecture assets. TOGAF provides an architecture metamodel that allows content adaptations in order to meet specific enterprise requirements. A metamodel provides evolving outlines for capabilities and relationships. Figure 10.33 illustrates a business architecture blueprint. The blueprint represents client focus, risk and financial management, business management and support based on product, and sales and/or service.

Figure 10.33 Business management focuses on the client and manages the risk for products, sales, and services. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Figure 10.34 illustrates a sample application (information system) architecture blueprint. The blueprint represents participants, interaction through electronic business gateways, processes, services, components, data about all of the components, rules, and technical services.

Figure 10.34 This sample representation of the blueprint for an information system shows all of the components and how they relate to each other. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Figure 10.35 illustrates a sample information architecture blueprint. The blueprint shows the relationships among transactional data stores (e.g., database that keeps track of daily transactions for one store), operational data store (e.g., database that keeps track of daily transactions for all stores), data warehouse (e.g., data management system that facilitates analytics and business intelligence queries at the enterprise level), and data marts (e.g., data management system that facilitates analytics and business intelligence queries at a business unit or department level). After running the data bus, the reporting and analysis step starts to produce operational reports, management reports, analytic reports, and e-commerce files. The blueprint for enterprise architecture helps align business and IT strategy, as well as provides a clear vision on how technology supports the enterprise goals. In addition, it’s a main reference tool to coordinate the collaboration between the different enterprise components.

Figure 10.35 This sample representation of the blueprint for information architecture shows the relationships among the components. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Figure 10.36 illustrates a sample technology infrastructure architecture blueprint. This blueprint shows three different types of clients:

1. Browser client that is using the browser to access the Internet web service
2. Pervasive client that is using public/private network to access the gateway
3. Partner service with a database that uses a public/private network to access the gateway

In addition, the blueprint represents the interaction and security level for each user to access the integration application and data bus.

Figure 10.36 This design shows a sample representation of the technology infrastructure architecture blueprint. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Blueprinting Templates

An enterprise architecture blueprint is a visualization of the architecture at the conceptual, logical, and physical level of an enterprise, showing concepts, their elements, and the components that implement the elements and their interrelationships. Various blueprinting templates are available to help derive architecture diagrams. Figure 10.37 illustrates a template that may be used to create conceptual business architectures. The diagram shows how the template may be applied in an insurance industry context. The diagram represents the enterprise value chain, which includes sales and marketing, product development, underwriting, finance and accounting, servicing, and claim processing. The blueprint includes many components and services, such as BPM processes, business capabilities, and business services.

Figure 10.37 The diagram represents the enterprise value chain, which includes sales and marketing, product development, underwriting, finance and accounting, servicing, and claim processing. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

To specify the conceptual business architecture of the underwriting value chain element, Figure 10.38 drills down into the “underwriting” value chain element.

Figure 10.38 Underwriting is an element of the value chain and incorporates new business and fulfillment. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Representing the logical architecture models using a blueprint template is different. Figure 10.39 illustrates a blueprint for the logical architecture model, shows the separation of concerns through layering, and enables high cohesion and low coupling across the application component. This blueprint represents interaction integration, bus process integration, application integration, service integration, data integration, and infrastructure integration. Using this template helps to create a detailed logical architecture model that may then be split into separate layers to convey more readable details.

Figure 10.39 This blueprint represents interaction integration, business process integration, application integration, service integration, data integration, and infrastructure integration. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Architectural and Implementation Styles

As you may recall, the specification of architectures starts at a high level within the enterprise to help align business and IT strategy. The main strategies are typically to achieve operational excellence as well as competitiveness. Figure 10.40 represents the relationship between the customer and the enterprise to improve the digital customer experience and digital operational excellence. The digital customer experience architect roles develop architecture strategy for a customer life cycle, collaborate on digital product and service design, and guide customer technology choice. The digital operational excellence roles guide integration with ecosystem partners, support innovation with technology, and codevelop agility strategy.

Figure 10.40 The relationship between the customer and the enterprise can improve the digital customer experience and digital operational excellence. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

This leads to the creation of enterprise reference architectures and specific business and technical architecture blueprints that represent the various views of architecture within the business, application, information, and technology domains. The scope of these views may then be refined to drill down into specific business units (portfolio) and project-level architectures. Within each level of scope, it is possible to apply architectural styles and corresponding implementation styles available within a pattern catalog. As we have learned, patterns can be applied to project-level architectures as part of high-level design and via leveraging of the architecture management umbrella activity.

Architectural and implementation styles may be reflected within blueprints. For example, Figure 10.41 represents how a conceptual technical architecture blueprint leverages the Business Process Management (BPM) architectural style. The diagram answers six questions:

1. Who is initiating the business event?
2. What is the classification of the business event type?
3. What channels are provided to initiate the business event?
4. What is the method used to digitize recognized business events?
5. How are business events digitally managed during their life cycle?
6. What automation, organizations, and processes are needed to support digital business event management?

Figure 10.41 A conceptual technical architecture blueprint leverages the Business Process Management (BPM) architectural style. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Figure 10.42 illustrates a technical implementation architecture blueprint that leverages specific implementation styles, and Figure 10.43 illustrates the same along with callouts identifying specific products and related vendors selected to implement and deploy the solution.

Figure 10.42 A technical implementation architecture blueprint leverages specific implementation styles. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Figure 10.43 Technical implementation architecture blueprint shown earlier with callouts specifying products and related vendors selected to implement and deploy the solution. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Human-Centered Computing Architectures and Related Patterns

Human-centered computing (HCC) is a newer term that subsumes human-computer interaction (HCI) and includes social computing and HCI. HCC studies the design, development, and deployment of mixed-initiative human-computer systems. HCC/HCI is a subfield within computer science that is concerned with the study of interaction between people and computers.

The main objective of HCC/HCI is to make computer systems more user-friendly and more usable. HCI studies the design, evaluation, and implementation of user interfaces for computer systems that are receptive to the user’s needs and habits. It is a multidisciplinary field, which incorporates computer science, behavioral sciences, and design. The field of computing basically seeks to provide a framework for the integration of human sciences and computer science in a manner that promotes the progress of human activities. With this respect, human-centered computing models design computing systems that support and enrich human existence.

Users interact with computer systems through a user interface, which consists of hardware and software that provides means of input, allowing users to manipulate the system, and output, allowing the system to provide information to the user. The design, implementation, and evaluation of interfaces is, therefore, a central focus of HCC/HCI. Corresponding process patterns are applied when designing HCC/HCI architectures. Pattern-based frameworks may be used to study, analyze, and translate the interactions of people with their surroundings into collaborative solution architectures.

Cloud-Based Architectures and Related Patterns

Big clouds (e.g., Amazon AWS, Google Cloud Platform, IBM Cloud, Microsoft Azure) are available today to help put together complex solutions in an enterprise context by providing Platform as a Service (PaaS) capabilities that can be assembled very quickly. For example, the cloud-based implementation architecture shown in Figure 10.44 uses three different clouds (social media cloud for data collection, private cloud for predictive analysis, and public cloud for data mining). These clouds collaborate in a mashup configuration and provide a cost-effective way to devise and implement solution architectures that leverage data collection, secure data mining, and intelligent analytics patterns. Scalable data processing framework implementations (e.g., Hadoop, Spark) are also readily available on the big clouds to provide efficient means of handling large amounts of data.

Figure 10.44 Three different clouds that include a social media cloud for data collection, private cloud for predictive analysis, and public cloud for data mining are collaborating in a mashup configuration. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Microservices Architectures and Related Patterns

A microservices architecture, called a microservice, is an approach to building a software solution as a set of small services (i.e., independent parts) that may be deployed locally or on the cloud. The cloud holds data, software, and services that run on the Internet instead of on a local computer. While microservices architectures are mainly oriented toward providing backend services, the approach is also being used to enable solutions’ front ends. Each service runs in its own process and communicates with other processes using protocols such as HTTP/HTTPS, WebSockets, or AMPQ. Each microservice implements a specific business capability within a certain context boundary, and each must be developed autonomously and be deployable independently. Finally, each microservice should own its related domain data model and domain logic and could be based on different data storage technologies such as SQL or NoSQL, and different programming languages. Figure 10.45 illustrates many patterns associated with microservices architectures such as motivating patterns and solution patterns. Multiple service hosts, database per service, access token, and health check API are examples of microservices. At a high level, microservices provide long-term agility and enable better maintainability in complex, large, and highly scalable systems by making it possible to create applications based on many independently deployable services that each have granular and autonomous life cycles.

Figure 10.45 Multiple service host, database per service, access token, and health check API are examples of microservices. (data source: C. Richardson, "Microservice Architecture pattern," https://microservices.io/patterns/microservices.html; attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

As an additional benefit, microservices can scale out independently. Instead of having single monolithic applications that must be scaled out as units, specific microservices may be scaled instead. This enables scaling just the functional area that needs more processing power or network bandwidth to support demand rather than scaling out other areas of the application that do not need to be scaled, which results in cost savings because less hardware is required.