第10章エンタープライズアーキテクチャーとソリューションアーキテクチャーの管理

DevOps describes an approach to improving collaboration between the development and operation of services. DevOps is a blend of the terms development and operation.

ArchDev is an example of an Accelerated Architecture-Driven Digital Transformation Process, which helps companies proactively embed stakeholder interest and sustainability into the company’s digital growth. Agile EA Management (AEAM) is a methodology used for software development and project management. AEAM uses divide and conquer methodology by breaking individual projects into smaller pieces to make them easier to manage, which speeds up design processes and produces quality products. ArchDev is enabled by methodology, tooling, and IP. It incorporates AEAM, and is compatible with TOGAF, to assess As-Is and To-Be states and a gap analysis to identify transformation initiatives that feed into the portfolio management process.

The business context driving prioritization is a major factor in selecting appropriate architectures for initiatives. Where DevOps integrates the tasks required to accelerate the development to deployment cycle, ArchDev (SecOps) integrates the disciplines required to identify a target architecture, which informs the solution design, monitors its implementation, and ensures its continued validity in the face of a changing environment. If changes in requirements or business context necessitate architecture revisions at any point in the development cycle or thereafter, ArchDev (SecOps) processes facilitate identifying the best replacement and following the most efficient path to migrating to it. ArchDev (SecOps), therefore, enables businesses to strike a balance between expedience and architecting business, which allows preserving business agility and sustainability.

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.

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

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.

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.

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.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.

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.

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.

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.

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.