6

TOGAF Framework in Action with AWS

In contrast to traditional waterfall processes, architecture can be developed in an iterative manner. Evidently, Agile-Scrum methodologies have proven to be successful because they emphasize iteration. In this process, documentation and proper planning do not have to be neglected. In fact, they should be encouraged.

In this chapter, we will cover the following topics:

• TOGAF – Architecture Development Method (ADM) phases and approaches
• Cloud architecture development method
• Cloud ecosystem reference models
• Enterprise architecture principles of the cloud ecosystem

TOGAF – ADM phases and approaches

Our goal is to develop an Information Systems architecture that functions efficiently and effectively. But remember, this is not to create endless and unnecessary artifacts. Generally, agile projects involve iteration during the requirements phase. Projects rarely have clearly defined and understood business requirements, without needing to elicit and clarify them beforehand.

Listed in the following table are the ADM phases. Each phase covers a specific role and describes the essential aspects:

Preliminary phase

In this first phase, the enterprise is defining when, where, what, why, whom, and how the architecture should be done in the enterprise. The main aspects are listed as follows:

• Enterprise definition
• Key drivers and elements in the organizational context identification
• Requirements for the architecture
• Development of architecture principles
• Definition of the architecture framework
• Relations between management frameworks
• Assessment of enterprise architecture maturity

In order for executives, planners, architects, and engineers to coordinate, integrate, and conduct their activities effectively, the enterprise architecture provides a strategic, top-down view of the organization. Through the enterprise architecture framework, this team has a strategic framework that enables them to conduct their activities effectively. Therefore, enterprise architects must take into account the interoperability between their frameworks and those throughout the organization, so it is not possible to develop the enterprise architecture in a solitary manner. Aspirations and goals must be set at the strategic, interim, and tactical levels.

Enterprise

Architecture faces a number of challenges related to the scope of an organization. Enterprise architecture capability will have the most impact on stakeholders based on the enterprise’s scope and whether it is federated. In order for the resultant activity to have resources and clear support from management, at this stage, it is imperative that a sponsor is appointed. There might be many organizations within the enterprise, and the sponsor is responsible for ensuring that all stakeholder groups are included in defining, establishing, and utilizing the architecture capability.

Organizational context

An enterprise must understand the context surrounding the architecture framework it plans to use before it can make informed and effective decisions. The following list of specific areas should be considered:

• When no commercial model or budget is available for enterprise architecture, it should be based on the preliminary phase
• Identifying the key issues and concerns of enterprise stakeholders across the architecture life cycle
• Describing the business principles and goals of the organization, as expressed in the directions, imperatives, and strategies set forth by the board of directors
• Focusing on technology and information portfolio management processes and methods along with current systems design and development frameworks and methods
• Based on the baseline architecture, describe how the landscape is currently portrayed in the documentation, along with the state of the enterprise
• Organizations and enterprises adopting the framework must identify their skills and capabilities.

Requirements for architecture work

The requirements and performance metrics of enterprise architecture work are driven by business imperatives. It is essential that the business outcomes and resource requirements are sufficiently clear for this phase to define the scope of the enterprise architecture work to be done and define the outline of enterprise business information requirements and associated strategies. Some examples are listed here:

• Business requirements
• Cultural aspirations
• Organizational intents
• Strategic intent
• Forecasting financial requirements

It is important to articulate the key elements of each of these. As part of the process of defining and establishing an architecture capability, it is necessary for sponsors to identify all the relevant decision-makers and stakeholders.

Principles

Prior to commencing any architecture work for enterprise approval, the preliminary phase defines the architectural principles. In order to develop an enterprise architecture, the architecture principles must be defined. In addition to architecture principles, business principles play a role in enterprise architecture. The business principles are also part of the architecture principles themselves. Normally, the architecture function is not responsible for defining business principles. These principles might be cross-referenced with other business principles, strategic business drivers, or business goals if they’re formulated and promulgated within the enterprise.

Management frameworks

A TOGAF framework must coexist with other management frameworks, either formally or informally, that might exist within an organization. Most organizations develop solutions using a system, which in the majority of cases has an IT component. In business, systems are important because they include both people and processes. TOGAF is recommended to be coordinated with the following list of frameworks:

• Business capability management includes the definition of Return on Investment (ROI) and the performance measures needed to determine the business capabilities required to deliver business value
• The methods used to manage a company’s change initiatives depend on the project or portfolio
• Operations management describes how a business runs its day-to-day operations, including how it manages the IT of its business
• The process of delivering business systems according to the architecture of the IT system in accordance with the methods of solution development

Relating the management frameworks

To plan, create, and deliver the architectural components specified in the project charters, the portfolio management framework employs a solution development methodology. A new building, new skills, new equipment, hiring, marketing, and more are examples of deliverables, but they are not exclusive to IT. Business processes are supported by enterprise architecture, not just IT. For the benefit of the enterprise, the management frameworks need to complement one another and work together.

At the strategy level, enterprise architecture is guided by business planning. Providing updated planning at an annual level is a method of providing a more fine-grained level of guidance. Another method popular with businesses is capability-based planning. Sometimes, enterprise architects are moved to strategic direction groups or work closely with them within some organizations. Enterprise architecture frameworks are developed using TOGAF. As displayed in the following diagram, capability planning is a complex cycle that requires an understanding of multiple aspects of the business:

Figure 6.1 – The cycle of business development and capability planning

Business change maturity evaluation

Using capability maturity models, an organization can assess how well it can exercise its various capabilities. Typically, capability maturity models identify which factors must be present for the capability to be exercised. It is possible to identify sequential steps that will help improve a capability by measuring an organization’s ability to execute specific factors. Executives can use this as a tool to improve their capabilities pragmatically.

To develop and consume enterprise architecture, an enterprise architecture maturity model must cover the features that are necessary. However, it is recommended that organizations take existing maturity models, customize them, and then determine which factors they should consider.

Phase A – the architecture vision

Starting with Phase A, the sponsoring organization sends the architecture organization a Request for Architecture Work document. Additionally, it describes what is included and what is not included in the architecture effort, along with the constraints that must be addressed.

General

ADM cycle’s scope definition for architecture activity will be defined within the preliminary phase and embodied in the architecture framework for the architecture vision phase. The architecture vision phase will only address the specific objectives of the ADM cycle. Consider revisiting the preliminary phase and extending the enterprise architecture framework when the architecture framework in place does not align with the proposed architecture vision.

Creating the architecture vision

It is the sponsor’s job to sell stakeholders and decision-makers in the enterprise the benefits of the proposed capability through the architecture vision. By addressing stakeholders’ concerns, it meets the organization’s objectives while also addressing stakeholders concerns. Adapting to emerging technologies and the impact they might have on industries and enterprises is an integral part of the architecture vision, without which many business opportunities might be missed.

One of the key parts of this activity is clarifying and agreeing on the purpose, and the purpose needs to be reflected clearly in what is created for the architecture effort. In a broader business strategy or enterprise planning process, the enterprise mission, vision, strategy, and goals are part of an organization’s architecture vision. To build a bridge between the enterprise strategy and the goals and decisions underlying the architecture, it is imperative to verify and understand the documented business strategy and goals. Businesses model their benefits to customers and stakeholders, which is an important strategy artifact.

Let’s examine and search for materials on fundamental business architecture concepts, such as the following:

• Business capabilities:

These are specific abilities or abilities that a business might have or exchange to help it achieve a particular goal or objective. It is important that the architect determines whether the organization has a framework for representing business capabilities.

• Value streams:

These are activities that contribute to an overall result for a customer, a stakeholder, or an end user.

• Organization maps:

They show the relationships between the primary components of an enterprise and its partners and stakeholders.

Aside from enterprise architecture, the architecture vision also explores additional fields that are relevant to enterprise architecture. The stakeholder domains might consist of elements of the basic domains but also serve a distinct purpose. A few examples are listed as follows:

• Information
• Security
• Digital network
• Network management
• Knowledge
• Industry-specific domains
• Services
• Partnership
• Cybersecurity

Our baseline and target architectures can be described based on this architecture vision for the business, data, applications, and technology domains. Further development of this outline will follow.

Phase B – the business architecture

Throughout this report, you will be presented with a holistic overview of capabilities, end-to-end value delivery, information, and organizational structure, along with the connections among those components, products, policies, and initiatives. Taking a domain-based approach, business architecture relates business elements to business objectives and other domain elements.

General

Knowledge of business architecture is a prerequisite for all other architecture activities and should be the first step in the process, particularly when it isn’t addressed in other organizational processes. Furthermore, business architecture is often needed so that key stakeholders can be convinced of the business value of subsequent architecture work and are convinced of the benefits they will receive from supporting and participating in the subsequent work.

Business strategy defines the business strategy and its objectives, although not necessarily how to achieve them. The scope of Phase B’s work is primarily determined by the architecture vision of Phase A. Phase B defines, in detail, the role of the business architecture. To the greatest extent possible, existing material should be reused. There might already be existing architecture definitions in more architecturally mature environments, which might have been maintained since the last architecture development cycle.

Developing the baseline description

A baseline description should be based on existing architecture descriptions if an enterprise has them. A business capability map or a core set of value streams might have already been included in Phase A when developing the architecture vision.

These materials should be updated if a new value stream has been implemented, a business capability is missing, or a change of organizational unit has occurred that wasn't considered in the enterprise architecture project. Taking information and developing business architecture models should be carried out if architecture descriptions do not exist.

Applying business capabilities

As part of the architecture vision phase, business capability maps are developed from the perspective of a separate business, independent of organizational structures, business processes, information systems, and other products or services included within the portfolio. A map of those business capabilities must be created within the scope of the enterprise architecture project, based on organizational units, value streams, and information systems. In this way, each of those domains is aligned and optimized more efficiently.

Applying value streams

In the architecture vision phase, document the business’s initial value stream models. There might be a need for new value streams within the context of a specific enterprise architecture project if the scope of the project is sufficiently broad. Through heat mapping or by developing use cases around a complete definition of the value stream, a new or existing value stream can be analyzed within the scope of the project.

Applying the organization map

Organizing an enterprise ecosystem involves identifying the key organizational units, partners, and stakeholder groups that constitute it. Organization maps are based on the business unit concept. Unlike an organizational chart that only shows hierarchical reporting relationships, the map should also show the working relationships between those entities. This map depicts the interactions and relationships between various business entities and is, typically, represented as a network or web.

Applying modeling techniques

Business capabilities, value streams, and organizational maps, as described in Phase B, are expanded and applied to the business in this phase through modeling and mapping techniques. In order to succeed in its goal, organizations must expand their operating models. The operating model is a representation of how an organization performs across various domains. There are many other modeling techniques that can be applied in addition to capability maps, value streams, and organization maps, such as the following:

• Activity models/business process models – These describe the functions associated with the enterprise’s internal exchanges, such as business activities, the data, and/or information exchanged between activities.
• Use case models – These are based on the purpose of the modeling effort; they describe either the business processes or systems functions.
• Class models - These describe informational behaviors. Several types of granularity can also be modeled with them, as can many of the other models.

The architecture repository will be explored by the architecture team during Phase B, specifically the following list:

• Reference models for the industry for which the organization operates
• Views specific to a business enterprise such as capability maps, value stream maps, and organization maps
• Building blocks that are specific to your enterprises such as process components, business rules, and job descriptions
• Applicable standards

Phase C – key considerations for data architecture

The enterprise must address data management issues when undertaking large-scale architectural transformation. The utilization of data to capitalize on its competitive advantages is made easier by a systematic and comprehensive approach to data management.

Data management

Issues must be understood and addressed when an enterprise chooses to undergo a large-scale architectural transformation. The effective use of data can be achieved through a structured and comprehensive approach to data management. Data management considerations include the following list:

• It should be determined which of the application components in the landscape will serve as the enterprise master data system or reference
• See whether there are any enterprise-wide standards that all software packages and application components must adopt
• Understand how data entities are used in business processes, functions, and services
• Be able to clearly understand how, where, and for how long enterprise data entities are stored, transported, and reported
• In order to support information exchange between applications, what level of data transformations are required?
• In what ways will the software be required to support the integration of enterprise data with that of its customers and suppliers?

Data migration

A new application must migrate data from an existing application when it is replaced. The data architecture should include the level of data transformation, weeding, and cleaning necessary to present data in a format that meets the requirements and constraints of the target application. Data quality is the goal when populating the target application. Additionally, a common data definition needs to be developed for the transformation to be successful.

Data governance

To ensure the enterprise is able to successfully transform, data governance considerations will ensure the necessary foundation is in place, which includes the following:

• Structure – The data entity aspects of change can be managed by an enterprise if it has the requisite organizational structure and standard bodies to do so.
• Management system – In order to manage the governance aspects of data entities throughout their life cycle, enterprises should have the necessary management systems and data-related programs in place.
• People – This dimension identifies what skills and roles an enterprise needs to be successful in transforming its data-based business model.

It is important that businesses acquire these skills, and that existing employees are trained through well-defined learning programs if such resources and skills are lacking.

Architecture repository

Within this phase, the architecture team works on understanding the existing resources in the organization’s architecture repository when it comes to data architecture. It particularly focuses on generic data models specific to the organization’s industry sector:

• Energistics® – The oil and gas industry’s standard for data exchange
• National Information Exchange Model (the US government)

A model for operational data and a model for a data warehouse from the Association for Retail Technology Standards.

During this phase, the architecture team will need to consider which available resources in the architecture repository are relevant with respect to application architecture. In particular, the generic business models that are relevant to the vertical sector, along with common high-level business functions, such as electronic commerce, supply chain management, and more. Please note the following:

• There are multiple vertical domain task forces within the Object Management Group (OMG) that develop software models for specific vertical domains, such as healthcare, transportation, and finance
• A detailed reference model for application architecture has been developed by the Open Group for the IT segment of organizations
• For organizations with IT segments, the Open Group has developed a detailed reference model for application architecture

Phase D – technology architecture

Enterprises looking for new and innovative ways to operate and improve their business are driven by the evolution of new technologies. In adopting new technology, technology architecture has the opportunity to take advantage of transformational opportunities available to the organization.

Emerging technologies

By enabling the TOGAF ADM to be flexible, technology becomes a resource and driver of change rather than the IT department. Therefore, the technology architecture might act as a driving force to deliver business capabilities and meet the information system requirements.

Architecture repository

The architecture repository is considered to identify relevant technology architecture resources, particularly the existing IT services as per the IT service catalog and the adopted technical reference model. Moreover, the technology models related to the business vertical of an organization are available in the market, for instance, The ™ forum – a comprehensive technology model has been developed related to the telecommunication industry.

Phase E – opportunities and solutions

Delivering the architecture is the focus of Phase E. All gaps between the target architecture and the baseline architecture are highlighted, and any changes are grouped into work packages within the enterprise’s portfolios as needed. The primary objective is to identify a roadmap that fits the needs of stakeholders, the business transformation readiness of the enterprise, the opportunities and solutions that exist, and the available implementation constraints. In order to realize incremental business value, we must focus on the final goal.

Phase F – migration planning

Phase F consists of collaborating with the project and portfolio managers to develop an implementation and migration plan. We will complete the incomplete roadmap and implementation and migration plan in Phase F and integrate both with the rest of our change activities.

Phase F will develop the final implementation and migration plan that will include portfolio and project-level details based on the architecture roadmap, version 0.1. At that point, lessons learned from the architecture development cycle should be documented in order to promote continuous improvement.

Phase G – implementation governance

All the information that is needed for the successful implementation of the various projects can be found here. The execution of a process specific to your organization runs parallel to Phase G, where you perform the actual development. In order to minimize risk in the transformation and migration program and to enable the early realization of business value and benefits, it is advisable that you deploy the target architecture as a series of transitions. In addition to advancing the organization toward its goal, each transition generates business benefits on its own.

Phase H – architecture change management

Added business value to architecture is the goal of an architecture change management process. A cohesive, architected process is required to manage changes to the architecture. Typically, processes such as these are used to continuously monitor governance requests, technological developments, and business environment changes. Change management will decide whether a new cycle of architecture evolution needs to be launched when changes are identified.

An enterprise’s architecture governance process is very closely tied to the architecture change management process. Additionally, the architecture function manages contracts between itself and the enterprise’s business users. The governance body must determine in Phase H whether a change request should only be treated as an architecture update or whether a new architecture development method cycle needs to be started.

Requirements management

A flexible approach is crucial to dealing with changing requirements. By its very nature, architecture involves uncertainty and change – the gray area between what stakeholders want and what can be specified and planned. As a result, requirements for architecture will always change over time. Additionally, architecture encompasses many drivers and constraints beyond the control of an organization (such as changes in market conditions and new legislation), which results in unexpected changes in requirements. Requirements management processes do not deal with, decide upon, or prioritize requirements. They manage them in the relevant phases of the ADM meaning, managing requirements throughout the entire process of the ADM.

Resources

There are numerous recommendations and processes for managing requirements that are emerging in the world of requirements engineering. These processes simply stipulate what should be achieved by a successful requirements management process. The TOGAF standard does not mandate any particular processes or tools. To discover and capture business requirements, the business scenario technique is an effective and appropriate tool.

In addition to architecture definition and realization, all cloud architecture development activities follow an iterative process. The organization takes this step-by-step approach to transform its architecture along with its business goals and opportunities.

Cloud architecture development method

In the context of developing next-generation cloud-native services and applications, taking a top-down approach makes the most sense as they should be designed, architected, and constructed from the ground up. Adapting TOGAF to build cloud architectures includes specific steps.

Preliminary phase

How the enterprise does architecture will be defined during this preliminary phase. It is important to figure out the framework to use and to define the architectural principles to serve as a guide for any architecture-related work. Reusing architecture assets within an enterprise is integral to the framework and architecture principles. A mechanism has been identified and established for identifying and establishing architecture principles:

In order to establish architecture governance, once the proper methodology has been determined, the architecture principles are important.

A – the architecture phase

A high-level description of the architecture develops in Phase A to reflect cloud-based characteristics. Cloud-specific concerns related to data security, privacy, compliance, scalability, ROI, and transparency will be addressed:

B – the business architecture

There is no change in the business goals associated with a cloud-enabled application. However, in a multi-tenant scenario, the business users themselves are variable. Accordingly, this view might need to be adjusted to match the needs of different groups of users. Cloud-based applications require the management of security, privacy, and other quality attributes, and must be synchronized with an enterprise resource. Another important aspect to consider is governance, visibility, and controllability:

C – information system architecture

Cloud applications might be similar to their traditional on-premise enterprise counterparts in terms of entity relationship modeling. Nevertheless, multi-tenancy aspects of the logical data model will introduce new variations. There will be different processes for an on-premises application than those for the data security view. In addition to data integration, cloud computing might cause problems with silos of information that IT does not have direct access to. The classification of data and privacy is also important, as is prioritizing the risks associated with both data going to the cloud and data remaining on-premises:

D – technology architecture

As we assess our current capabilities and develop an environment, we will be using TOGAF to guide our efforts. Several traditional components included in the application architecture view will be abstracted by the Platform as a Service (PaaS), making this view different from a traditional enterprise application. Cloud architecture will be different from on-premises architecture:

E/F – migration planning

In order to deploy services in the cloud, you need to understand the cloud’s available resources. Keep in mind that value can be defined in many ways, and it certainly doesn’t mean the financial values associated with the total cost of ownership and ROI:

G – implementation governance

Consider the inclusion of business processes, applications, the data and database, and technical services, along with the implementation of security and operations during the relocation. This plays a key role in Phase G of the implementation. The various implementation projects are managed here with all the information needed for success:

H – architecture change management

As a result of Phase G, a new enterprise architecture baseline will be established, which will be managed through an architecture change management process:

As a result of this, an architecture change management process is leveraged to set a new baseline for the enterprise architecture.

Cloud ecosystem reference models

This model describes how to realize and facilitate architectural capabilities in an enterprise cloud ecosystem through participation by at least one of the new or existing participants.

Business support services and ABBs of the cloud ecosystem reference model

The purpose of this section is to discuss the interoperability of an IT and business taxonomy. The following sections make up a comprehensive list of services that will simplify enterprise business operations and reduce complexity.

Accounting and billing

Bills for cloud services usage data are generated and managed based on predefined billing policies. The providers of cloud services might permit consumers to receive one bill for multiple subscriptions to qualify for volume discounts. Other accounting functions are also handled by the program.

Auditing and reporting

The audit and reporting service keeps a record of all activities for an agreed period of time, which will assist with future investigations. This helps reduce the risk of disruptive business processes and performance degradation. Reports that perform client‐facing business operations activities are generated.

Availability and continuity

This service handles redundancy and workload mobility between cloud service providers. The primary objective is to ensure the selection of high availability practices and considerations in the design of cloud services.

Compliance and policies

Corporate governance and compliance with applicable laws and regulations are some of the activities that the compliance and policies service defines. The organization maintains an organizational structure, processes, tools, and business policies to ensure these services.

Consumer service

To ensure cloud service consumers receive effective care and that information about their relationships with the company is well handled, the consumer service provides an authoritative view of consumer information.

Contract and agreement

Various aspects of cloud services are offered and managed by the contract and agreement service with regard to the contract life cycle and contract life cycle management. As part of the contract, cloud service consumers are notified of applicable policies and SLAs for using cloud services.

Metering service

Cloud services and their underlying resource usage are billed/charged using the metering service. A certain level of abstraction is applicable depending on the service type provided by this metering system.

Order service

Cloud service orders are managed by the order service. In this case, cloud services are configured, service life cycle services are orchestrated, and billing and accounting are offered.

Service demand

Based on past business activity patterns and future growth projections, this service identifies the business demand for cloud services.

Subscription service

Subscription services provide cloud service providers with the option to charge for cloud services according to different subscription models. Subscribers can opt for fixed-rate, tier-based, or pay-as-you-go subscriptions. Providers monitor the allocation, consumption, and chargeback of cloud services to their subscribers.

Operational support services

Enterprise cloud ecosystems can be operated efficiently by operational support services.

Capacity and performance service

Cloud capacity and performance are optimized through the capacity and performance service. Real-time analysis and automatic workload adjustment are performed while cloud services are running.

Incident and problem handler service

In this service, problems and incidents that are related to the service are handled and the root causes are analyzed. Data is stored in a knowledge support repository for further analysis.

Inter-cloud connection service

To enable interoperability between cloud services, the inter-cloud connection service serves as a seamless bridge between different environments. Connecting with the cloud service facilitates remote access, allows users to cross different network boundaries, and improves performance.

IT asset and license service

License agreements for cloud services related to various aspects are controlled by the IT asset and license service. Additionally, some providers allow cloud service consumers to purchase licenses directly from software/solution vendors or to lease as and when needed.

Service orchestration

Cloud service orchestration allows the management of capacity and performance for cloud services on an automated basis. In this way, multi-cloud services are coordinated seamlessly.

Template service

Service templates are used to create reusable instances. The template service enables the automatic provisioning and redeploying of applications on cloud service platforms.

Cloud security services

Data, applications, and infrastructure that are stored in the cloud are protected by cloud security technologies, policies, controls, and services.

Data protection

Despite the fact that data, in today’s world, is an invaluable asset, most of it remains worthless if it isn’t protected. We need to protect data at every stage of the life cycle, for all data types, and at all levels of the data life cycle. To provide data protection, a variety of controls must be implemented, including data life cycle management, data leakage prevention, intellectual property protection, digital rights management, and cryptographic services.

Enterprise data management

To securely share information among enterprise cloud ecosystems, information/data is a crucial enterprise asset that must be managed. All phases of the life cycle of all categories of data must be addressed by enterprise data management. Data governance, information planning, IT architecture, record and archive provisioning, and privacy are core enterprise data management functions.

Governance risk and compliance

Compliance and governance encompass, integrate, and align various corporate governance, enterprise risk management, and regulatory compliance activities. Among these components are vendor management, audit management, IT risk management, policy management, technical awareness, and training.

Infrastructure protection services

Data security is the practice of making sure that containers and pipes of data are secure using a traditional defense-in-depth approach. Generally, infrastructure protection services are considered preventive technical controls. Most traditional or non-advanced attacks can be defended against relatively effectively.

Information security

Information security aims for the implementation of appropriate measures to eliminate threats and vulnerabilities related to data. In international enterprises, data transit and storage might differ significantly as a result of different national legislation and consequently affect information security concerns often related to privacy and confidentiality.

Policy and standards

An information security policy outlines how much security should be applied to protect the business. However, often, technical solutions are not mentioned in policies, which specify what should be done. In order for the many different components to be integrated into systems, security standards are an abstraction at the component level.

Privilege service

As part of Identity and Access Management, the privilege service ensures that users have the access that is necessary to perform duties. Examples include identity management, authentication services, authorization services, and privilege usage management. It allows access to the right resources across increasingly heterogeneous technologies and meets increasingly stringent compliance requirements.

Threat and vulnerability service

Threat and vulnerability management deals with core security matters. An enterprise must track and monitor its assets, scan for known vulnerabilities, and take action by patching the software. This is called vulnerability management. In order to identify the vulnerabilities effectively, threat modeling and security testing are also required.

Performance services

Performance services ensure SLAs are adhered to for the cloud services. It includes monitoring resource utilization, analyzing resource performance in a cloud computing environment, and assessing service performance in real time.

Resource health monitoring

In order to provide better performance, accountability, and business results, resource health monitoring generates cloud resource performance reports. This solution allows the monitoring of SLAs based on defined metrics.

Service health monitoring

Service health monitoring allows users to view the health of their cloud services, create reports on the performance of cloud services, and improve performance, accountability, and results. SLA metrics are also supported.

SLA enforcement

In order to avoid penalties, SLA enforcement ensures the SLAs are strictly enforced. As the subscription renewal process approaches, data related to SLAs can also be captured and used to make adjustments to contracts and agreements.

Interoperability and portability services

A cloud ecosystem requires effective integration with all its stakeholders through interoperability and portability services.

Data interoperability

Cloud service consumers can seamlessly manage both structured and unstructured data through interoperability. Data that is semantically consistent can be shared across multiple enterprises. A suitable semantic standard could be based on cloud-specific metadata, for instance, Open Group’s Universal Data Element Framework (UDEF) or the US Government’s National Information Exchange Model (NIEM). The information/data in a cloud ecosystem can be shared and reused.

Service interoperability

Data and services can be consumed across multiple cloud service providers with a unified management interface through cloud service interoperability.

Cloud service providers are able to access information related to underlying resources and provision a workload seamlessly using IaaS interoperability.

Interoperability at the PaaS level revolves around developing and deploying platform services, as well as licensing them, seamlessly. However, SaaS consumers expect their SaaS applications to have critical features supported across multiple channels.

Data portability

Data migration allows data to be transferred from one cloud environment to another or from one computer to another. On the other hand, the synchronization of data within a cloud ecosystem is the mechanism to ensure consistency across all duplicated target data storage for a single set of source data. The data is kept continuously coherent over time.

Product catalog services

An enterprise’s cloud services are cataloged in the cloud ecosystem’s product catalog.

Change and configuration services

Cloud services configurations are kept compliant with changes in policies and compliance by the change and configuration services. They ensure that the cloud services that are offered in the catalog are configured correctly.

Service catalog

Cloud service consumers can subscribe to services listed in the service catalog and the catalog information can be configured easily. Cloud consumers can describe and manage cloud services more easily by using a self-service cloud service provisioning portal. Alongside describing cloud service provider capabilities, the service catalog could describe how well they meet cloud performance ratings.

Resource catalog services

Cloud ecosystems manage underlying cloud services resources through resource catalog services.

Change and configuration service

Cloud services are configured in compliance with changing policies and compliance requirements through the change and configuration service.

Resource catalog

A resource catalog manages information about the resources that are needed to support the provisioning requests of cloud services. These are captured through the self-service cloud service administration.

In catalogs, metadata represents resource characteristics that can be analyzed by humans and machines for further analysis.

Enterprise architecture principles of the cloud ecosystem

Architectural Building Blocks (ABBs) defined in the cloud ecosystem reference model for managing the life cycle of cloud services maintain enterprise architecture principles for the use of the ABBs across the enterprise. Enterprise principles and a consensus, in terms of architectural design, should underpin these principles.

Auto-provisioned sharable system infrastructure

A cooperative infrastructure is supported by shared and auto-provisioned computing resources. The underlying computing resources of the IaaS cloud service provider utilize a multi-tenant environment in order to maximize profit. If moving workloads across IaaS is done right, the overhead can be reduced, and the SLAs can be met.

Cloud solutions are designed to address performance variance

Due to performance variances, latency fluctuations, and network failures, some cloud solutions that rely on public networks and the Internet Protocol (IP) are insecure. Cloud computing is characterized by the ability to access cloud services through standard and public internet connections. It is essential that cloud solutions address unreliable IP services and variances in latency.

Solutions for cloud computing should provide seamless connectivity and meet performance-related SLAs.

Automated ways to measure and optimize cloud solutions

The measurement and optimization of cloud services can be automated through the use of metering and cloud service solutions.

The cloud service provider and the cloud service consumer need real-time visibility of cloud services’ utilization in order to minimize investment in cloud services.

Loosely-coupled cloud services

The cloud infrastructure should be loosely coupled between SaaS, PaaS, and IaaS. Dynamic and scalable cloud environments are supported by cloud services. Provide a multi-tenant deployment model with minimal customization of cloud services.

Cloud service abstraction and control

Provide a level of abstraction with cloud services that allows them to be securely exposed while hiding all of the implementation details. Providing service agility is achieved by separating the deployment details and hiding the implementation details within cloud services.

The concept of cloud services must be abstracted from the implementation details.

Multi-tenancy

Multi-tenant clouds must support tenant and solution isolation. In every case, it is critical to separate the assets of each client from the assets of other clients, regardless of the storage medium. Ensuring that their clients have secure isolation between assets is a major priority for cloud service providers. Their isolation control mechanisms do seem to succeed in controlling this capability, although they find it difficult to demonstrate.

Summary

Understanding the TOGAF architecture domains and exploring cloud ecosystems in context to AWS is what this chapter is all about. We also reviewed the reference architectures and models and shed light on how to approach each phase of TOGAF ADM in AWS cloud transformation. The aim is to understand the non-functional aspects of the system including security, reliability, operational excellence, performance efficiency, and cost optimization. Moving forward, we will talk and explain WAR alignment with TOGAF principles.

The interoperability of an IT and business taxonomy along with the comprehensive list of services that will simplify enterprise business operations and reduce complexity were also mentioned in this chapter.

Next, we will find the answer to the following questions: how do you select the IT initiative across your enterprise, and what is the strategy that drives ABBs and solution building blocks? With a deep study of multiple architectural phases and implementations, we will discuss and explain strategies for infrastructure implementation, including on-premises, cloud, and hybrid. Furthermore, we will dig deeper into SAFe and learn more about aligning enterprise architecture and SAFe for any business to determine how it caters to AWS cloud customers.