The Open Group Cloud Ecosystem Reference Model – Using the Cloud Ecosystem Reference Model with the TOGAF Standard (Informative)

Introduction

This chapter describes how to develop, manage, and govern an Enterprise Architecture of a fictitious organization named “CloudEcoSource” with use of the Cloud Ecosystem Reference Model and the TOGAF standard. It describes an approach for each phase of the TOGAF Architecture Development Method (ADM) and what the architect should consider when looking to apply the TOGAF ADM to an enterprise Cloud Ecosystem. This informative case study describes a generic approach to develop an Enterprise Architecture by utilizing Architecture Building Blocks (ABBs) identified in the Cloud Ecosystem Reference Model. The standard defines an approach to identify Solution Building Blocks (SBBs) to address the architectural capabilities of ABBs. For example, the following describes the relation of ABBs and SBBs for rapid provisioning and data protection in an enterprise Cloud Ecosystem:

An SBB for rapid provisioning can be provided by any of the participants of an enterprise Cloud Ecosystem delivering the Cloud Service (e.g., Cloud Service Provider, Cloud Service Broker, etc.). An ABB for these capabilities is, however, also part of the architecture of the consuming enterprise, because the architecture requirement for rapid provisioning will remain even if another participating entity in the enterprise Cloud Ecosystem provides the SBB.
A data protection ABB should also appear in every applicable participant’s architecture. From the perspective of the customer enterprise, each instantiation (SBB) of that building block is another participant with which there is a relevant relationship as part of the customer’s Cloud Ecosystem. This is because security policies applicable to the customer’s data need to be carried out consistently across all parties handling that data, regardless of how the building block is actually implemented.

CloudEcoSource Background

In order to illustrate how the TOGAF standard can be applied for the Cloud Ecosystem, a fictitious organization named “CloudEcoSource” with three separate initiatives will be referenced for each phase of the TOGAF ADM.

Besides having a strong IT function in the organization, CloudEcoSource has engaged multiple external Cloud Service Providers for its heterogeneous cloud infrastructure platform and software services to support its business needs. The organization intends to use the TOGAF standard for Enterprise Architecture practices to manage its Cloud Services as well. CloudEcoSource has currently three distinct cloud-specific initiatives that have the characteristics of IaaS, PaaS, and SaaS for cloud. This section will describe how CloudEcoSource plans to use the TOGAF standard to create and evolve an Enterprise Architecture for the Cloud Ecosystem. The following is a brief description of the cloud-specific initiatives of CloudEcoSource:

IaaS initiative: Infrastructure modernization and consolidation – An IaaS-focused initiative of CloudEcoSource with the expectations on how to transform and regulate dynamic resources consumption in a multi-tenant infrastructure environment with effective management of privacy of its tenants (i.e., enterprise customers).
PaaS initiative: Rapid application development platform – A PaaS-focused initiative to identify and describe architectural capabilities of a platform for CloudEcoSource business solutions. The instances of the platforms could be deployed and operated either solely by an enterprise or by participating entities of the Cloud Ecosystem.
SaaS initiative: Enhanced collaborations among multiple service providers – A SaaS-focused initiative where CloudEcoSource is assembling business capabilities for business collaborations that extend the organization’s traditional enterprise application boundaries with extended users (both internal and external to the organization).

Preliminary Phase

The TOGAF Preliminary Phase is about defining “where, what, why, who, and how we do architecture” in the enterprise concerned. It does the preparation and establishes the architecture framework needed for new Enterprise Architecture work. The TOGAF standard provides for incremental architecture development. Each cycle through Phases A to H creates an incremental addition to the Enterprise Architecture. (The cycles typically overlap, with Phases A to F of each new cycle being carried out in parallel with Phase G: Implementation Governance of the previous cycle.)

The Preliminary Phase does what is needed before the cycles can start. It is usually carried out when the TOGAF framework is first adopted by a particular architecture team for a particular enterprise. Its activities may be revisited as needed for subsequent architecture engagements.

The Preliminary Phase is where the architect adopts the principles of the Cloud Ecosystem, and organizational change flexibility. This affects two other outputs of the phase: the governance and support strategy, and the content of the initial Architecture Repository. It focuses on the following aspects to ensure that the organization’s architectural model has the support of necessary business and IT capabilities for the use of the organization’s Cloud Ecosystem:

Describe the business mission, goals, and objectives to ensure that Architecture Principles are in alignment with them.
Describe and ensure that there is a process to document business requirements and constraints (both internal and external) that will impact the Cloud Ecosystem.
Ensure that the organization model for Enterprise Architecture and the ADM are in alignment with the business goals and objectives of the Cloud Ecosystem.
Confirm that the architecture governance structure and guidelines will be able to provide support for all aspects of the organization’s Cloud Ecosystem.
Prepare to create a request for Cloud Ecosystem architectural work to get formal approval in Phase A.

Architecture Principles

Architecture Principles are a set of principles that relate to architecture work. They reflect a level of consensus across the enterprise, and embody the spirit and thinking of existing enterprise principles. Architecture Principles govern the architecture process, affecting the development, maintenance, and use of the Enterprise Architecture.

The Preliminary Phase defines the Architecture Principles that will form part of the constraints on any architecture work undertaken in the enterprise. They are typically developed by the lead Enterprise Architect, in conjunction with key stakeholders, and are approved by the Architecture Board. They are included in the tailored architecture framework, which is an output of the Preliminary Phase.

An enterprise participating in the Cloud Ecosystem will in general have an established set of Architecture Principles. These should be examined in the context of the Cloud Ecosystem for completeness and applicability. It is possible to identify several scenarios that could apply:

Existing principles, which fit poorly, if at all, with cloud. This can happen when a principle dates from an earlier period, when cloud in its current form did not exist. Should we keep the principle as-is and accept the consequences, even if it means little or no cloud? Can it be amended? In this case we need to look at the underlying Business Principle and evaluate whether the Architecture Principle can be phrased differently. It is possible that we may come to the conclusion that the principle is no longer valid.
Principles which are clearly still relevant but need to be expressed differently. This too may require revisiting the underlying Business Principle.
Existing principles whose implications need to be given particular attention in the cloud context.
New principles which are needed to address the specific challenges of the Cloud Ecosystem.

The Enterprise Architecture Principles of the Cloud Ecosystem defined in Section 3.2 can be listed with the Motivation Extension viewpoint of the ArchiMate standard. Figure 4 illustrates the viewpoint of an enterprise’s Cloud Ecosystem.

Enterprise Cloud Ecosystem Architecture Principles

The rest of this section describes the additional steps taken in the Preliminary Phase to achieve the overall goals of the architectural effort outlined for CloudEcoSource.

Define Governance Approach

The Cloud Ecosystem can leverage and extend the TOGAF Architecture Governance Framework to manage its cloud architectural activities and Cloud Service Providers as one of the participants within the Cloud Ecosystem as illustrated below. In addition, the established architecture governance board of CloudEcoSource will govern the project.

EA Governance Structure of CloudEcoSource – An Illustration

Organizational Implications

In order to effectively manage the CloudEcoSource Cloud Ecosystem, the management has determined that it will be ideal to augment the current structure with the recommended organizational roles defined in Section 4.3 (Specialized Organizational Roles).

Phase A: Architecture Vision

The Architecture Vision phase focuses on addressing the changing business requirements from both internal and external stakeholders and envisions a mechanism to meet those requirements in an optimal way. It focuses on the following to ensure that necessary adjustments to current business and IT capabilities are addressed, thus enabling an efficient use of the Cloud Ecosystem of an organization:

First and foremost, secure the organization’s top management support as well as commitment from all impacted stakeholders.
Ensure that the impact to all stakeholders’ interests is understood and agreed by relevant stakeholders.
Validate the business mission, goals, and objectives to ensure that Architecture Principles are in alignment with them.
Establish Key Performance Indicators (KPIs) for the Cloud Ecosystem to validate and align the Enterprise Architecture of an organization.
Describe and ensure that there is a process to document business requirements and constraints (both internal and external) that will impact the Cloud Ecosystem.
Ensure that the organization model for Enterprise Architecture and the ADM are in alignment with the business goals and objectives of the Cloud Ecosystem.
Ensure that existing architecture governance will effectively utilize the Cloud Ecosystem and provide guidance to address gaps and constraints.
Obtain formal approval for the architecture work of the Cloud Ecosystem.

The rest of this section describes the steps taken in Phase A to achieve the overall goals of the architectural effort outlined for CloudEcoSource.

Establish the Architecture Project

CloudEcoSource followed its corporate policies and procedures to ensure that its cloud initiatives have been recognized and endorsed by the appropriate management as a planned cloud architectural activity within the Cloud Ecosystem.

Identify Stakeholders, Concerns, and Business Requirements

In order to help us finalize the business requirements, expectations, and scope of the initiatives, we should identify the key stakeholders of CloudEcoSource. The following table shows stakeholder concerns, their classifications (with expectations), and mapping to architectural output to be developed to satisfy and communicate their concerns.

Stakeholder Map of CloudEcoSource – An Illustration

Stakeholder	Key Concerns	Class	Architectural Viewpoint/Output (Catalogs, Matrices, and Diagrams)
Corporate	High-level business drivers, goals, and objectives	Key Players	Organization Decomposition diagram Business Footprint diagram Business Goals to Cloud Services Mapping diagram
Program Management Office (PMO)	Business portfolio, product catalog, functional prioritization, funding	Keep Informed	Business Footprint diagram Functional decomposition diagram Portfolio catalog
Cloud Business Support	Service agreements, compliance, service demand, audit and reports	Key Players	Service-Level Agreements (SLAs) Actor/Role matrix Compliance and Reporting
Cloud Operations Support	Information assurance, service life cycle, capacity and performance, service resources	Key Players	Service Life Cycle diagram Information/Data Security diagram SLA Compliance reports Cloud Service Capacity Planning

Different stakeholders, playing different roles, also have different concerns (stakeholder viewpoints) which are the key drivers for the acceptance of the architecture program. Concerns are key drivers of the stakeholders, which, from their perspective, are decisive for the acceptance of the architecture program. There must be an inventory of all stakeholders and their concerns in the Architecture Vision phase.

Stakeholder Concerns Viewpoint of CloudEcoSource – An Illustration

Then these concerns must be related to the goals of the future architecture. This can be achieved using the Goal Refinement viewpoint (as proposed in the Motivation Extension) and instantiated for a subset of CloudEcoSource.

Goal Refinement Viewpoint of CloudEcoSource – An Illustration

Confirm and Elaborate Business Goals, Business Drivers, and Constraints

Once the business goals and strategic drivers of the organization are to be confirmed by key stakeholders, we should capture the applicable business, technical, and operational constraints of CloudEcoSource. These are essential items to ensure management endorsement for the cloud initiatives. For example, constraints pertaining to security, privacy, and confidentiality of information have to be clearly understood especially in the context of the CloudEcoSource Cloud Ecosystem where national security and privacy legislation differ. Addressing these constraints may well have a major architectural impact.

In order to highlight the capability evalation process, let’s consider that stakeholders of CloudEcoSource expect to improve existing Customer Relations Management (CRM) capabilities to reduce the number of complaints filed by its customers.

Evaluate Business Capabilities

CloudEcoSource business, technical, and operational capabilities related to the Cloud Ecosystem – see Chapter 4 – are currently immature. Figure 8 illustrates one of the possible ways to highlight the target business capabilities of CloudEcoSource to support the value chain targeted to achieve business agility.

Target Business Capabilities of CloudEcoSource – An Illustration

Once the capabilities are defined, the possible implications for the CRM capability, for example, can be assessed and visualized with the stakeholder view. The results of the assessment are documented in a Capability Assessment (refer to the TOGAF 9.1 Specification, Part IV, Section 36.2.10).

CRM and Manage Sales Capabilities Assessment View of CloudEcoSource – An Illustration

Assess Readiness for Business Transformation

Table 10 illustrates the result of the CloudEcoSource readiness assessment to perform architecture work of cloud initiatives for effective enablement of the organization’s Cloud Ecosystem.

Business Transformation Readiness Assessment – An Illustration

Assessment ID	Readiness Factor	Priority (Low/Med/High)	Readiness Status (Low/Fair/Acceptable /Good/High)	Transformation Assessment (Difficulty Level: Low/Med/High)
1	Business needs	High	High	Low
2	Financial support	High	Fair	Low
3	Sponsorship support	High	Good	Low
4	Business readiness	High	Good	High
5	IT readiness	High	Acceptable	High
6	Operational readiness	High	Low	Med
7	Governance readiness	Med	Fair	High

Business Transformation Readiness Assessment Matrix of CloudEcoSource – An Illustration

Readiness Factors Assessment of CloudEcoSource – An Illustration

Define Scope

CloudEcoSource developed a high-level strategic architecture that gives management and other stakeholders an overview of enterprise perspectives on the Cloud Ecosystem and the ways it will support business objectives. The scope also identifies the impacted segments (e.g., procurement, infrastructure, application platform, and solutions) and how to use the cloud Program Management Office (PMO) to manage the Cloud Services portfolio to ensure effective execution of architectural activities.

Confirm and Elaborate Architecture Principles, including Business Principles

The architecture team of CloudEcoSource confirmed that the Architecture Principles defined in the Preliminary Phase are in alignment with the enterprise principles, goals, and objectives and have been endorsed by the architecture governance board.

Develop Architecture Vision

The Architecture Vision of CloudEcoSource is to provide a Cloud Ecosystem that will support heterogeneous Cloud Service Providers in order to meet the objectives of its stakeholders. The architecture will enable a mechanism to effectively address all Cloud Service models (i.e., infrastructure, platform, and software) to minimize costs and to achieve business agility. Figure 12 illustrates a conceptual view of the Target Architecture of CloudEcoSource. It is based on the stakeholder concerns, business capability requirements, scope, constraints, and principles outlined for the CloudEcoSource Cloud Ecosystem.

Target Architecture of CloudEcoSource – An Illustration

Define the Target Architecture Value Propositions and KPIs

In order to track performance and to ensure that there are mechanisms in place to measure the architecture work of CloudEcoSource, the following performance measurements are defined:

Procurement of Cloud Services will be at least 20% cheaper than the development cost.
The operational cost of Cloud Services will be at most 85% of the current operational cost.
Any request instigated by a user will provide a response within three seconds.

Develop Statement of Architecture Work; Secure Approval

The Architecture Statement of Work is defined to capture the architecture approach and impact to all stakeholders of CloudEcoSource. It contained a roadmap and communications plan to ensure that all stakeholders are aware of the progress of the cloud initiatives. The Architecture Statement of Work has captured risks classification and assigned a risk mitigation strategy.

It has now been approved by the sponsor and all applicable signing authorities to proceed with the architecture work.

Phase B: Business Architecture

The Business Architecture describes the business values of the Cloud Ecosystem to the key stakeholders of an organization and ensures that the business strategy, organization’s structure, governance, business process information, as well as interactions between these concepts are well defined. One of the objectives of the Business Architecture is to establish a mechanism that allows the organization to quickly deliver business value to its customers. Organizations have to maintain business structure to enable business functionality to achieve business agility. Business structure not only describes products and services that an organization provides, but also describes functions, processes, and their inter-relationships. Organizations using Cloud Services might have extended business structures due to business services provided not only by internal units, but also by external organizational units.

The Business Architecture describes relationships between different instances of Cloud Service models to ensure that organizations have consistent and coherent cloud-enabled business capabilities. Cloud Services provided by external service providers are transforming business processes and require new approaches to manage the impact on the organization’s functions and its IT environment. The life cycle management of Cloud Services requires constant check to ensure that business objectives are met with efficient and effective business risk management. Organizations might have to transform and evolve existing business processes and practices for efficient IT management. To achieve business agility, the organizations need to formulate strategy and address Cloud Services-related business objectives to enable efficient IT management by:

Adopting Cloud Services as part of the enterprise strategy to transform business and IT functions
Establishing an effective mechanism for Cloud Services management that allows existing business processes to integrate cloud sourcing practices and guidelines
Evolving existing business processes to incorporate a business-driven approach to enable business process redesign that uses new capabilities to create optimal business solutions in order to achieve target objectives – this needs to be accomplished in an environment that is friendly to use
Assessing business capabilities and realizing that Cloud Services will require new organizational roles (e.g., Cloud Service Broker, Cloud Strategist) to efficiently manage the cloud environment that generally extends traditional organizational boundaries with the use of external Cloud Service Providers

Figure 13 outlines the expected input and output of the Business Architecture phase from a Cloud Ecosystem perspective:

Business Architecture – An Enterprise Ecosystem Perspective

Organizations have to build consistent and integrated business capabilities portfolios that are internally developed or procured from external Cloud Service Providers. The key aspects of the Business Architecture for the Cloud Ecosystem are to not only describe business processes, actors, roles, and collaborations, but also to depict the coherent relationships between Cloud Services in respect to their deployment models. The business-focused approach of the TOGAF ADM will be used to ensure that the organization’s business objectives of the Cloud Ecosystem support all stakeholders. A comprehensive Business Architecture not only provides and supports the recommended deliverables for the Business Architecture, but also specifies the extended business boundaries, roles, products, and services for the Cloud Ecosystem. The following recommended deliverables are to capture all relevant aspects of the Cloud Ecosystem:

Organization/Role/Location catalog: Describes a definitive listing of all actors/participants that interact with the Cloud Ecosystem.
Organization Structure diagram: Highlights the extended organizational boundaries.
Functional Decomposition diagram: Describes business processes, Cloud Services functions, and their inter-relationships.
Business Footprint diagram: Captures the relationships between business goals, functions, and how these functions map to services provided by the Cloud Ecosystem.
Information Flowsthat capture the information needs within and between business processes and organizational elements.
Conceptual Information/Data model that describes the high-level information elements (subjects, entities, attributes, and values) used by an enterprise.
Conceptual Metadata model that describes the data needed to manage, use, and share the data.

The Business Architecture for CloudEcoSource describes the Cloud Services strategy with functional, information, and services deployment aspects to achieve the organization’s required business agility. This will enable CloudEcoSource to execute evolving business needs at an acceptable cost, time, and quality with minimum risks. To sustain the business strategic objectives described above, initiatives need to be placed in the appropriate architectural context to develop a business portfolio that gets translated into concrete projects and criteria to measure success in executing those initiatives. One of the key deliverables in the Business Architecture is to ensure that business requirements effectively translate into the Target Business Architecture of CloudEcoSource.

In order to develop relevant architectural viewpoints to describe how stakeholder concerns are addressed, we will use value stream mapping and describe the relationships between the key business participants of CloudEcoSource. In addition, we should identify key business metrics to ensure the viability of cloud solutions. Once key participants for the Cloud Ecosystem are identified, a Functional Decomposition diagram and a Business Footprint diagram will be used to describe and capture their inter-relationships.

The rest of this section describes the steps taken in Phase B to achieve the overall goals of the architectural effort outlined for CloudEcoSource.

Select Reference Models, Viewpoints, and Tools

Use the Cloud Ecosystem Reference Model described in Chapter 3 as a foundation to determine viewpoints, to capture functional activities within CloudEcoSource. The Business Support Service and Operational Support Service viewpoints will demonstrate various stakeholder concerns and informational behaviors of the enterprise. Also, to measure the progress towards strategic objectives and to communicate that progress, Business Support Services will be associated with KPIs relative to the business functions of CloudEcoSource. These business functions are associated with standardized processes to translate business strategic objectives into operations. The service product catalog will manage required business building blocks and their relationships with external Cloud Service Providers.

The Functional Decomposition diagram will capture various business functional capabilities and their relationships. Also capturing reference models from external Cloud Service Providers will help to describe the impact on the organizational roles and responsibilities. Focus will not only identify and describe functional boundaries, but associated metrics for measurement.

Develop Baseline Business Architecture Description

Use the models identified in Section 5.4.1 as a guideline for creating new architecture content to describe the Baseline Architecture.

Develop Target Business Architecture Description

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified in Section 5.4.1 and the Baseline Architecture created above as a guideline for creating new architecture content to describe the Target Architecture.

Business Communication of CloudEcoSource – An Illustration

Actor Collaboration Diagram – An Illustration

Functional Decomposition Diagram – An Illustration

Business Functions/Processes Relationship – An Illustration

Requirements, Goals, and Process Relationship View – An Illustration

Business Footprint Diagram – An Illustration

Perform Gap Analysis

Verify the architecture models of CloudEcoSource and its Cloud Service Providers to ensure consistency and accuracy. Perform a trade-off analysis to resolve conflicts (if any) among the different views. Validate that the architecture and models support the principles, objectives, and constraints of the enterprise and test architecture models for completeness.

Identify gaps between the Baseline and Target Architecture.

CloudEcoSource has not performed Business Architecture work related to the Cloud Ecosystem earlier by engaging external Cloud Service Providers. Any new business processes or impact on existing business processes need to have the approval of key stakeholders. This includes training IT personnel to effectively manage Cloud Service Providers, and establishing a mechanism to determine which business functions and data are good candidates for public/private/hybrid clouds.

Define Candidate Roadmap Components

Following creation of a Baseline Architecture, a Target Architecture, and developing gap analysis results, a Business Roadmap is required to prioritize activities over the coming phases. CloudEcoSource has prioritized Cloud Services related to IaaS, PaaS, and SaaS services to ensure all stakeholder concerns are addressed. The initial Business Roadmap will be used as raw material to support cross-service models (i.e., IaaS, PaaS, and SaaS) roadmap within the Opportunities & Solutions phase.

Resolve Impacts Across the Architecture Landscape

Once the Business Architecture is finalized, it is necessary to understand any wider impacts or implications not only from existing internal architecture work, but services provided by Cloud Service Providers. Identify any services that could be leveraged from Cloud Service Providers in the CloudEcoSource Cloud Ecosystem. Envision the impact of Cloud Services provided by Cloud Service Providers and/or developed internally (both current and planned) on the Cloud Ecosystem.

Also, in order to effectively engage external Cloud Service Providers, CloudEcoSource must negotiate SLAs (e.g., price, liability, and service support and termination agreements) to ensure that its business and technical requirements and risks are fairly balanced with Cloud Service Providers.

Conduct Formal Stakeholder Review

Check the original motivation for the Cloud Ecosystem architecture and the Statement of Architecture Work against the proposed Business Architecture, asking if it is fit for the purpose of supporting subsequent work in the other architecture domains. Adjustments should be made in order to ensure that the proposed Business Architecture supports all stakeholder concerns.

Finalize the Business Architecture

Engaging Cloud System Providers in a Cloud Ecosystem will impact the working practices of an enterprise. CloudEcoSource will have to make adjustments to current practices, roles, and carefully analyze the impact of selected building blocks on the overall architecture of the Cloud Ecosystem. Re-using services in the form of building blocks as much as possible with captured rationale about decisions in the architecture documentation assists in architectural decisions in the future. All architectural decisions related to building blocks should be captured in the Architecture Repository along with clear traceability to business requirements. All gap analysis results and decisions to address those gaps should also be captured in the Architecture Repository.

Update Architecture Definition Document

In order to get a buy-in from all stakeholders, the Architecture Definition Document is updated. Prepare the business sections of the Architecture Definition Document providing a high-level description of the people and locations involved with key business functions and how a management footprint shall enforce standards, rules, and guidelines impacting the CloudEcoSource Cloud Ecosystem. The business section of the Architecture Definition Document also provides details on how relationships with Cloud Service Providers will have an impact on the skill matrix and working practices of CloudEcoSource.

Phase C: Information Systems Architecture

The objectives of Phase C of the TOGAF ADM are to develop Target Architectures for both the application and data (in either order) of an architecture project. This section describes the Data Architecture for a Cloud Ecosystem.

The Data Architecture requires a comprehensive assessment of an enterprise’s information and underlying data. This phase will extend the conceptual work completed in the earlier phases of the ADM. A structured and comprehensive approach to enterprise information/data management enables the effective use of data to capitalize on its competitive advantages.

The enterprise information model for a Cloud Ecosystem will facilitate a common understanding of the corporate structured and unstructured data and will serve as a basis for the Target Data Architecture. The model facilitates unified access across all types of enterprise data, consistently applies applicable business rules, and accelerates Cloud Services development. Data quality should be well defined and captured in the metadata for all data assets of an enterprise (refer to The Open Group White Paper: An Information Architecture Vision). These metadata attributes will dictate what technology constraints (e.g., caching, partitioning, and failover), service qualities (e.g., availability, performance, scalability), and service delivery concepts (e.g., DaaS) will be used within an enterprise Cloud Ecosystem. Data quality also drives the service levels requirements of Cloud Services.

The information security service ABB defines and manages the requisite security classifications, compartments, and legislative constraints on the use of the information within an enterprise Cloud Ecosystem. It is also critical to use the metadata to define access policies to support granular data access for individual, role-based, and governance-based security access controls.

Where applicable, architecture practitioners should consider including the following in order to complete the Data Architecture for an enterprise Cloud Ecosystem:

Practitioners should identify data migration to cloud requirements, with governance for data quality, and to ensure that an enterprise-wide common data definition is established by defining a system of records for enterprise data.
Architecting data for cloud also utilizes various data caching techniques aimed at improving data availability, performance, and scalability. The Cloud Ecosystem requires that cloud solutions are tolerant of network failures and data consistency. The Data Architecture might need to accommodate new assumptions that data consistency is generally sacrificed over data availability and requires an enabling mechanism (e.g., data partitioning) to relay/expose consistent data via cloud solutions.
The Data Architecture for CloudEcoSource describes the Cloud Services strategy to address the distributed nature of CloudEcoSource data resources. The architecture provides a flexible data integration mechanism and ensures that data in the cloud is appropriately shared and maintained.
Address big data and social networking data by utilizing semantic techniques to convey the intent of data during information exchange. This requires the treatment of data as information assets associated with appropriate categorization, quality, and their potential use in the Cloud Ecosystem. Within an enterprise Cloud Ecosystem, data categorization integrates disparate data to serve as common business objectives and make them securely available as information assets rapidly and efficiently.

The rest of this section describes the steps taken in Phase C to achieve the overall goals of the architectural effort outlined for CloudEcoSource.

Select Reference Models, Viewpoints, and Tools

Use the enterprise Cloud Ecosystem Reference Model described in Chapter 3 as a foundation to determine viewpoints to address various stakeholder concerns and to capture functional activities within CloudEcoSource. The Cloud Ecosystem requires addressing various regulatory, auditing, and compliance business requirements and selecting relevant Data Architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Data Architecture.

Determine appropriate tools, techniques, and modeling processes to create and manage data views to address all stakeholder concerns. Leveraging Cloud Services from heterogeneous Cloud Service Providers requires a consolidated view of the semantically consistent data inventory to reduce any possible overlaps and identify gaps in data relationships. Elaborated views to address all stakeholder concerns help achieve business objectives. The data used within and across the business processes of CloudEcoSource must be cataloged as the basis for further documentation. This catalog includes both structured data and unstructured content. Using conceptual data models to document data taxonomies will create consistent views and describe how data is created, distributed, migrated, secured, and archived in the CloudEcoSource Cloud Ecosystem.

Develop Baseline Data Architecture Description

In order to develop the Target Data Architecture of CloudEcoSource, and assess the current state, develop cross-reference information entities in the Baseline Data Architecture to promote consistency, re-use, and avoid redundancy. The Baseline Architecture can use existing data models to understand existing data sources and then add any needed extensions for cloud into the baseline models. Otherwise, use the guidelines identified in Section 5.5.1 for creating a new Baseline Data Architecture that clearly identifies a system of records and Data Architecture building blocks that enable secure sharing of information on the cloud.

Develop Target Data Architecture Description

Sharing data in a cloud is considered a paradigm shift and the Target Data Architecture should address the structural and operational changes for the Cloud Ecosystem.

Develop a target description for the Data Architecture, to the extent necessary to support the Architecture Vision and Target Business Architecture. Ensure that non-functional data requirements are incorporated in the Target Data Architecture and translated into SLAs. For example, some critical non-functional requirements in the cloud are:

Data security measuring criteria (e.g., privacy, confidentiality, data obfuscation, etc.)
Data availability and tolerance threshold on data loss
Data reliability
Volume of data

SaaS and Data Requirements – An Illustration

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Section 5.5.1 as a guideline for creating new architecture content to describe the Target Architecture.

Perform Gap Analysis

The purpose of gap analysis is to attain business and IT objectives and validate that architecture models support established principles and guidelines to support expected data consistency and accuracy. If required, develop several alternatives, with analysis of the work and trade-offs associated with each alternative to achieve the stakeholder objectives. Also provide a mechanism to address any implications of closing the identified Data Architecture-related gaps in the current organizational context to effectively achieve the Target Data Architecture. Ensure that there are effective data governance policies and that compliance procedures are established for the CloudEcoSource Cloud Ecosystem.

Define Candidate Roadmap Components

Define the Data Architecture Roadmap based on the Baseline and Target Architecture gaps in order to prioritize other architectural activities. The defined candidate roadmap will also be utilized in the Opportunities & Solutions phase to create a consolidated/integrated Architecture Roadmap for the CloudEcoSource Cloud Ecosystem.

Resolve Impacts Across the Architecture Landscape

It is necessary to resolve the impact of the cloud Data Architecture on architectures of the CloudEcoSource Cloud Ecosystem. The Cloud Ecosystem provides an efficient underlying mechanism for the delivery of on-demand compute capacity. The infrastructure services are highly variable in nature (i.e., elastic) and the Data Architecture must assume and plan for the inconsistent failure of any component (i.e., infrastructure, platform, software components) in order to provide efficient and effective mechanisms for the business solutions of the Cloud Ecosystem.

An additional challenge is the need to integrate data with various cloud deployment scenarios of the CloudEcoSource Cloud Ecosystem. Some capabilities to address these are provided at SaaS and PaaS level and will have impact not only on the Data Architecture but on the entire architecture landscape of CloudEcoSource.

Conduct Formal Stakeholder Review

Check the original motivation for the Cloud Ecosystem architecture and the Statement of Architecture Work against the proposed Data Architecture. Determine whether it is fit for the purpose of supporting subsequent work in the other architecture domains. Adjustments to architectures should be made in order to ensure that the proposed Data Architecture supports all stakeholder concerns. Identify any impact or constraint on the Application and Technology Architecture of the CloudEcoSource Cloud Ecosystem.

Finalize the Data Architecture

Finalize all work on the Data Architecture and conduct a final check to ensure that all stakeholder concerns are addressed. Ensure that the ABBs of the Data Architecture support the business requirements and don’t impact adversely on the CloudEcoSource Cloud Ecosystem.

Create Architecture Definition Document

Create Data Architecture sections of the Architecture Definition Document describing data logical models. Highlight how the Data Architecture addresses any data interoperability and data security requirement with rationale for building block decisions in the Architecture Definition Document. Route the document for review by relevant stakeholders, and incorporate feedback.

Phase D: Technology Architecture

In order to realize a Technology Architecture that provides a flexible and adaptable technology infrastructure for the Cloud Ecosystem, enterprises will have to carefully align short-term and long-term business objectives with a modular set of technology services to support information systems services. By incorporating the concerns of the stakeholders, these technology services enable the functioning of explicit and comprehensive capabilities that address the identified technical services gaps in the enterprise Cloud Ecosystem. New technical services and their underlying technology building blocks need to be defined and detailed to ensure that all applicable technical considerations (some of them are outlined in Section 4.6 (Technical Considerations)) are considered and incorporated into the Technology Architecture. To determine whether these capabilities are to be built within the enterprise or utilize Cloud Service Provider services, trade-off analyses need to be performed to identify, evaluate, and address the impact on the Cloud Ecosystem of any new technology services introduced/modified/eliminated. Required architectural viewpoints should be created to demonstrate how stakeholder concerns relating to technology are addressed.

Architecture practitioners should consider including the following as part of the activities/deliverables for both the Baseline and Target Technology Architecture in order to complete Phase D:

Determine the overall Technology Architecture approach and determine any cloud-specific technology resources required (e.g., matrices, diagrams, patterns, etc.) for the Cloud Ecosystem. For example, it would be beneficial to have cloud product/technology metrics to highlight relationships that could be used for technology assessment.
Technology capabilities and their decomposition showing the technology required for the Cloud Ecosystem in order to realize a particular Cloud Service (i.e., IaaS, PaaS, and SaaS). The technology deployment model (e.g., on-site/outsourced) will have implications on supporting expected non-functional requirements that are generally described and measured by SLAs of the Cloud Ecosystem. SLAs define measurements for services performance, availability, maintainability, and supportability aspects of Cloud Services. Also, services in the Cloud Ecosystem may have impact when inter-service communications over various network boundaries are utilized.
Architectural capabilities to support essential cloud characteristics (e.g., resource pooling, rapid elasticity, measured services, etc.) and handle their impact on the architecture by providing technology management capabilities that allow self-service administration within a context of participants (e.g., consumers or providers) of the enterprise Cloud Ecosystem.
Interactions of technology capabilities and their relationships to information systems ABBs of the enterprise Cloud Ecosystem.
Applicable view of environments (e.g., development, test, rroduction) outlining physical deployment locations (public/private/hybrid/community) in the context of the enterprise Cloud Ecosystem. These technology views describe interactions of architectural capabilities and relationships to enable multi-tenant environments.
Security: The Technology Architecture must include applicable security implications for utilizing Cloud Service Providers in the enterprise Cloud Ecosystem. This includes different levels of security controls that are required to support variations of cloud deployment models and impact on the workload processing and network/communications capabilities of the enterprise Cloud Ecosystem.
Portability and Interoperability: The Technology Architecture must enable mechanisms to support data portability and service interoperability in order to effectively communicate between multiple cloud environments with minimum impact to the service availability of the Cloud Ecosystem. Standardized information exchange mechanisms will effectively allow Cloud Service Consumers to utilize multiple Cloud Service Providers and the efficient migration of data and services of the Cloud Ecosystem when required.

The Technology Architecture of the Cloud Ecosystem describes the technology services strategy to address the Cloud Ecosystem’s technical services requirements. The architecture realizes both the logical and physical technical aspects of the infrastructure, platform, and software services capabilities of the Cloud Ecosystem in order to support business objectives. The architecture will provide guidance in establishing ideal SBBs of the Cloud Ecosystem in the later phases of the ADM. Understanding the existing Technology Architecture and assessment of its features and functionality will identify technology gaps.

The Technology Architecture for the Cloud Ecosystem will enable comprehensive technical services for the Cloud Ecosystem where each tenant has mechanisms to effectively control demand and manage the life cycle of services.

The rest of this section describes the steps taken in Phase D to achieve the overall goals of the architectural effort outlined for CloudEcoSource.

Select Reference Models, Viewpoints, and Tools

Review and validate the set of Technology Principles. These will normally form part of an overarching set of Architecture Principles with alignment to the enterprise principles that include Cloud Ecosystem principles as described in the Preliminary Phase (see Section 5.2.1 (Architecture Principles)). Guidelines for developing and applying Technology Principles are established that promote ubiquitous access and self-service administration of technology services. This will ensure that all essential characteristics necessary for the Cloud Ecosystem are supported in the technology services.

Select relevant Technology Architecture resources (reference models, viewpoints, matrices, diagrams, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, stakeholders, and their concerns.

Identify requirements for appropriate tools and techniques to be used to support the infrastructure, platform, and software services of the Cloud Ecosystem. These technical requirements will set the foundations for viewpoints required for the Cloud Ecosystem and to demonstrate how the stakeholder concerns are being addressed in the Technology Architecture. For example, the Technology Architecture will have to support viewpoints to demonstrate essential cloud capabilities for:

Real-time allocation of computing resources to Cloud Services in order to provide required elasticity and scalability capabilities
Automatically adjust computing resources between various Cloud Services instances and processing requirements in order to achieve targeted performance measurements
Tenant-based resources usage tracking and billing based on Cloud Services consumption
Technical capabilities to securely interoperate and port workloads of the Cloud Ecosystem

Develop Baseline Technology Architecture Description

In order to support the Target Technology Architecture and to address stakeholder concerns, a baseline description of the existing technology capabilities will have to be assessed through developing the Baseline Technology Architecture. The scope and level of detail to be defined will depend on the extent to which existing technology components are likely to be carried over into the Target Technology Architecture, and on whether architectural descriptions exist.

Identify the relevant Technology Architecture building blocks and existing cloud-enabled technology services. Evaluate associated assumptions about security and interoperability, by drawing on any artifacts held in the Architecture Repository. If nothing exists within the Architecture Repository, define technology capabilities for each application in line with the product catalog and associated entry in the Technology Portfolio catalog. The Technology Portfolio catalog maintains a list of all technology services and associated information of the Cloud Ecosystem.

Develop Target Technology Architecture Description

Develop a target description for the Technology Architecture to support the Architecture Vision and how the Technology Architecture will address stakeholder concerns. Describe the value of Cloud Services to stakeholders (e.g., consumers and external parties involved) by showing the technology composition of each Cloud Service and associated contract(s) and agreement(s). The scope and level of details will depend on the use of existing Cloud Services and if relevant architectural descriptions exist in the Architecture Repository.

The Technology Architecture practitioners may add additional technology requirements to address the architectural needs identified in earlier phases in order to describe a broad and comprehensive Target Architecture for the Cloud Ecosystem.

The Target Technology Architecture of CloudEcoSource describes how software, platform, and infrastructure services are used to support cloud business solution requirements, their usage, and relationships. This provides an overall perspective on technical dependencies to enable an effective Cloud Ecosystem. The architecture describes SLAs that measure the effectiveness of the overall Cloud Ecosystem architecture, evaluates compliance with business policies, and enables practitioners to select the right ABBs by conducting a quick trade-off/fit-for-purpose analysis. The CloudEcoSource architects decided to use all available Cloud Service models to deliver their Cloud Services. The following view of the Target Technology Architecture highlights the seamless use of Cloud Services provided by Cloud Service Providers (depicted with CSP-*) and their use to deploy cloud solutions on the CloudEcoSource Cloud Ecosystem:

Technology Architecture Viewpoint of CloudEcoSource – An Illustration

Perform Gap Analysis

The purpose of gap analysis is to attain the business and IT objectives of the Cloud Ecosystem and validate that architecture models support established principles and guidelines to support the expected technology consistency and accuracy. If required, develop several alternatives, with analysis of the work and trade-offs associated with each alternative to achieve stakeholder objectives. Also provide a mechanism to address any implications of closing the identified Technology Architecture-related gaps in the current organizational context to effectively achieve the Target Technology Architecture. Ensure that there are effective data governance policies and compliance procedures established for the CloudEcoSource Cloud Ecosystem.

Define Candidate Roadmap Components

Define the Technology Architecture Roadmap based on the gap analysis in order to prioritize other architectural activities. The defined candidate roadmap will also be utilized in the Opportunities & Solutions phase to create a consolidated/integrated Architecture Roadmap for the CloudEcoSource Cloud Ecosystem.

Resolve Impacts Across the Architecture Landscape

It is necessary to resolve any impact of the Cloud Technology Architecture on architectures of the Cloud Ecosystem. The Cloud Ecosystem Technology Architecture capabilities shall enable an efficient underlying mechanism to deliver on-demand Cloud Services. Analyze the artifacts to identify:

Does this Technology Architecture create an impact on any pre-existing architectures and are associated assumptions still valid for the Cloud Ecosystem?
Have recent changes been made that impact the Technology Architecture of the Cloud Ecosystem? The changes may include any outsourced/built-in Cloud Services, impact of new applicable business policies, and technology advancements.
Identify any opportunities to standardize technology of the Cloud Ecosystem and analyze the impact to stakeholders.

Conduct Formal Stakeholder Review

Check the original motivation for the Cloud Ecosystem architecture and the Statement of Architecture Work against the proposed Technology Architecture. Determine whether it is fit-for-purpose. Adjustments to architectures should be made in order to ensure that the proposed Technology Architecture supports all stakeholder concerns. Identify any impact or constraint on the Application and Data Architecture of the CloudEcoSource Cloud Ecosystem and refine the proposed Technology Architecture if necessary.

Finalize the Technology Architecture

Finalize all work on the Technology Architecture and conduct a final check to ensure that all stakeholder concerns are addressed. Ensure that ABBs of the Technology Architecture support the business requirements, consistent with the defined business policies, and don’t impact adversely the functional effectiveness of the CloudEcoSource Cloud Ecosystem.

Create Architecture Definition Document

Create the Technology Architecture sections of the Architecture Definition Document describing technology logical models. Highlight how the Technology Architecture addresses the business requirements and policies with rationale for building block decisions in the Architecture Definition Document. Route the document for review by relevant stakeholders, and incorporate received feedback to determine whether review of the document is once again required.

Phase E: Opportunities and Solutions

Phase E concentrates on how to deliver the architecture. It takes into account the complete set of gaps between the Target and Baseline Architectures in all architecture domains, and logically groups changes into work packages within the enterprise’s portfolios. This is an effort to build a best-fit roadmap that is based upon the stakeholder requirements, the enterprise’s business transformation readiness, identified opportunities and solutions, and identified implementation constraints. The key is to focus on the final target while realizing incremental business value.

The emphasis of Phase E is on the approach to deliver the Target Architecture and starts the transformation of the ABBs from Phases B to D into SBBs. The Cloud Ecosystem architecture implementation considers the different types of cloud deployment model in addition to the on-premises extension to the Cloud Ecosystem. It may also consider new implementation(s) on the Cloud Ecosystem.

The project life cycle in the Cloud Ecosystem is drastically reduced due to the cloud computing capability of services that can be rapidly assembled through IaaS, PaaS, and SaaS. Phase E identifies the process to deliver the Target Architecture through projects, programs, or portfolios.

The traditional gap analysis between the current ABB and target ABB is not directly relevant since it is an infrastructure replacement. In the Cloud Ecosystem the Target Architecture consists of services of ABBs.

From the Architecture Vision phase it is essential to define the Target Architecture in terms of services components. Overall Phase E output will be candidate work packages, which would become Architecture Roadmap components and incremental delivery though the Transition Architecture through Phase F.

Phase E considers architecture reference materials of the Cloud Ecosystem. The Cloud Ecosystem needs to be monitored as it evolves with new standards and new capabilities of Cloud Services that are offered by the vendors on a regular basis.

At this juncture the implementation issues such as financial, technical, and contractual need to be considered.

The implementation model and type depends on some of the following considerations:

Time to market
Legacy applications dependency and phasing out
Cost versus risk
Capability of the organization
Cloud readiness

The objectives of Phase E are to review the target business objectives and capabilities, consolidate the gaps from Phases B to D, and then organize groups of building blocks to address these capabilities. Additional tasks may include:

Confirm the enterprise’s capability for undergoing change
Derive a series of Transition Architectures that deliver continuous business value through the exploitation of opportunities to realize the building blocks
Generate and gain consensus on an outline Implementation and Migration Strategy

The rest of this section describes the steps taken in Phase E to achieve the overall goals of the architectural effort outlined for CloudEcoSource.

Determine/Confirm Key Corporate Change Attributes

The main objective of this step is to analyze the business culture, abilities, and skill sets for effective implementation of the Enterprise Architecture. An enterprise adoption of the Cloud Ecosystem brings its own advantages and challenges. The key advantage is the rapid assembly of applications services. Also, the services may be consumed based on pay per usage, reducing capital expenditures.

The challenges are to build confidence about the new deployment model that is not located on the premises.

Creation of an Implementation Factor Assessment and Deduction matrix serves as a repository for helping make architecture implementation migration decisions. The step also includes assessments of the transition capabilities of the organizations involved considering the culture and abilities (to adopt emerging technology). It also provides for assessments of the enterprise and IT organization skill sets (cloud computing).

Implementation Factor Assessment and Deduction Matrix – An Illustration

Factor	Description	Deduction
Change in application implementation	Application implementation on cloud rather than on-premises	· Business to be aware of the new model · Compliance/governance to be modified for moving business services to the cloud · Essential skills training
SaaS to address business need	Business application assembled from SaaS to fulfil business requirements	· Capability to provide identity management, access control, and customize services · Business units deploying their own applications due to low cost and ease of deployment thereby introducing security holes
Scalability and elasticity	Applications able to scale and shrink as per the demand	· Skills to design applications to take advantage of scalability on-demand
Application integration	Integration of application services on the cloud and on-premises	· Skills to do integration with on-premises and legacy enterprise applications with the cloud
Enterprise data segregated into cloud silos	Each SaaS utilized creates its own data	· Integration challenges · Extract transform load data from various services · Data integration and replication solutions
Business functions and data	Traditional business functions and data reside locally on premises	· Establish a mechanism to determine the business functions and data that can be hosted in public/private/hybrid

Determine Business Constraints for Implementation

The business drivers that triggered the adoption of the enterprise-based on the Cloud Ecosystem need be reviewed. The initial factors to consider may be a business-driven adoption of technology to reduce cost, automate processes, shorten time-to-market, improve competitiveness, etc.

IT systems in large enterprises may have evolved over the last two or three decades. A revisit of Phases B to D may be required, as there may be other services and the need to convert manual processes to automated processes.

Educating the business users to use business process management tools gives more control to the business users to manage the business with less dependency on IT. There may be also constraints such as time-to-market, cost, skills, etc.

The Enterprise Architecture maturity assessment is reviewed, to identify whether they are able to meet the targeted maturity.

Review and Consolidate Gap Analysis Results from Phases B to D

An enterprise adopting the Cloud Ecosystem brings its own challenges due to the business services consumed from different vendors. The gaps identified in Phases B to D need to be assessed and analyzed for potential implications due to the change in application deployment model from package/bespoke solution to a Cloud Services model.

Consideration must be given to the dependencies of applications in the Cloud Ecosystem as they span across the on-premises deployment model and cloud deployment model. Also there may be inter-dependencies with Cloud Services consumed from different Cloud Service Providers.

Consolidated Gaps, Solutions, and Dependencies Matrix of CloudEcoSource – An Illustration

Architecture	Gap	Potential Solutions	Dependencies
Business	Organization has not performed Business Architecture work related to the Cloud Ecosystem earlier by engaging external Cloud Service Providers.	New business processes or impact on existing business processes need to have key stakeholders’ approval.
Business	Business Agility	Business process assembled through services.	Existing business process integration
Data	Data consistency and accuracy implications of data in different SaaS/PaaS providers.	Ensure that there are effective data governance policies and the compliance procedures are established for the CloudEcoSource Cloud Ecosystem.
Technology	To support expected technology consistency and accuracy.	To have an effective technology stack validation and selection process.

Review Consolidated Requirements across Related Business Functions

To assess the requirements, gaps, solutions, and factors to identify a minimal set of requirements whose integration into work packages would lead to a more efficient and effective implementation of the Target Architecture.

To identify the shared services that can be utilized across the enterprise through provision of shared resources.

Consolidate and Reconcile Interoperability Requirements

In the Cloud Ecosystem, interoperability requirements are a critical success factor, as business services are provided by one or more Cloud Service Provider.

Based on the solution, the services can be consumed either from an information system deployed on a PaaS or business services from a SaaS. The interoperability between PaaS and SaaS needs to be considered. See The Open Group Guide: Cloud Computing Portability and Interoperability for detailed information.

In addition to interoperability, the APIs provided by the cloud vendors need consideration as potential factors accounting for services consumption and future extension.

Refine and Validate Dependencies

Dependencies are identified. These provide constraints in determining the sequencing of the Implementation and Migration Plan. The key dependencies usually are existing implementations of business services and information systems or changes to them. In the Cloud Ecosystem it is very important to understand the dependencies as the implementation duration is greatly reduced due to rapid infrastructure provisioning and business service availability with SaaS.

Dependencies assist in sequencing the efforts required, grouping the related projects, identifying milestones and logical/actual delivery points, and in planning the project duration.

Determining the dependencies becomes a critical key factor for migration planning in the Cloud Ecosystem, especially as more vendors are involved.

Confirm Readiness and Risk for Business Transformation

The Business Transformation Readiness Assessment previously conducted in Phase A is reviewed to determine its impact on the Architecture Roadmap and the Implementation and Migration Strategy.

Risks associated with transformation are identified, classified, and mitigation planned and documented as Cloud Ecosystem risks are very different from traditional on-premises technology projects risks.

The Architecture Roadmap, focused on the cloud deployment model, has the capability of rapid provisioning of the services. The solutions are to be thoroughly analyzed to find the dependencies between the services.

Formulate Implementation and Migration Strategy

The overall strategic implementation direction that guides the Transition Architecture(s) are considered based on:

Greenfield: A completely new implementation of the Cloud Ecosystem.
Revolutionary: A radical change moving the on-premises deployment model to the Cloud Ecosystem.
Evolutionary: A strategy of convergence, such as parallel running or a phased approach to introduce new capabilities such as a hybrid model of extending the on-premises capability with the Cloud Ecosystem.

Identify and Group Major Work Packages

Key stakeholders, planners, and the Enterprise Architects need to assess the missing business capabilities identified in the Architecture Vision and Target Architecture gap analyses.

In the Cloud Ecosystem the information system will be moved from on-premises to the cloud based on the Migration Strategy as Greenfield, Revolutionary, or Evolutionary. Group the work packages to suit the Migration Strategy.

Identify Transition Architectures

Where the scope of change to implement the Target Architecture requires an incremental approach, then one or more Transition Architectures may be necessary.

In the Cloud Ecosystem the type of services based on IaaS, PaaS, or SaaS will determine the number, type, and duration of Transition Architectures. Also the Migration Strategy as Greenfield, Revolutionary, or Evolutionary becomes a determining factor.

Create the Architecture Roadmap & Implementation and Migration Plan

The Architecture Roadmap is consolidated from the work packages and Transition Architecture that describes the timeline of the progression from the Baseline Architecture to the Target Architecture. The identified Transition Architectures and work packages should have a clear set of outcomes.

To create a roadmap for delivery of services based on cloud solutions:

Revisit the initial implementation planning.
Identify the major implementation projects that can be implemented on the Cloud Ecosystem.
Decide on approach (make versus buy versus re-use through services and shared services; COTS services for cloud and on-premise application)
Assess priorities of business services that can be migrated to the Cloud Ecosystem based on business readiness and business user acceptance.
Identify dependencies of services within services between cloud and on-premises.
Develop an impact analysis on the existing IT systems.
Group projects into Transition Architectures.

The Implementation and Migration Plan demonstrates the activity necessary to realize the Architecture Roadmap based on the Cloud Ecosystem. The projects and resource requirements consider the Cloud Ecosystem in addition to the on-premises application. The application implementation needs to consider the priority of the services based on the business requirement identified earlier.

Finally, update the Architecture Vision, Architecture Definition Document, and Architecture Requirements Specification with any additional relevant outcomes from this phase.

Phase F: Migration Planning

Migration Planning assumes a very important role in successful cloud adoption. The migration projects will have to be sorted according to the Cloud Vision of the organization, the Cloud Transformation Roadmap, the benefits to the organization, the mutual dependencies among projects, and, finally, the financial feasibility.

The Cloud Vision of the organization should be analyzed and the drivers for the projects to move to the cloud should be understood. The key business drivers could be:

Providing agility
Making the organization future-ready
Cost optimization by bringing elasticity in the solution
Exposing a re-usable solution to a wider audience

The rest of this section describes the steps taken in Phase F to achieve the overall goals of the architectural effort outlined for CloudEcoSource. Each of the steps below is taken in cooperation with the appropriate project/program office.

Prioritize and Create a Migration Roadmap

Prioritize the cloud migration projects by assessing the migration benefits, project internal upgrade plans, mutual dependencies among projects, and financial feasibility. Create a Cloud Migration Roadmap based on the priority determined above. Derive a migration schedule based on the roadmap and individual project timelines and distinct milestones.

Determine Resource Requirement and Cloud Infrastructure Provider

Determine the resources required for each of the projects. Determine the SLAs and elasticity requirements for the migration projects. Choose the Cloud Infrastructure Provider – whether this provider should be the organization itself, building a private cloud environment, or whether the organization would manage a private cloud in a third-party provider environment. In case of a private cloud within the organization boundary, determine whether it will be on-premise or near-premise (a physical establishment separated by geographical boundary but part of the organization’s physical infrastructure). Understand the infrastructure available to support the cloud project. Discuss the migration projects and corresponding SLAs and elasticity requirements with the Cloud Infrastructure Provider.

Determine the Cost/Benefit

Assess the funding required and the benefit that the organization would achieve if migration is performed. Chart the projects to visualize the cost/risk versus the benefits. Request the funding from the appropriate funding authority.

Determine the Risks

Assess the overall risk of migration to the cloud. Assess the risk of individual projects and identify the high-risk projects.

Create a Cloud Migration Roadmap

Create a roadmap based on the outcome from the above steps and approvals obtained from the funding authority. Create a Cloud Migration Roadmap with distinct milestones.

Create Detailed Implementation Plan

Working closely with the appropriate PMO, assist in the creation of a Detailed Implementation Plan based on the preliminary Migration Roadmap and individual project timelines (developed in Phase E).

Create Formal Migration Contract

Create a formal contract with the Cloud Infrastructure Provider with a detailed description of SLA requirements, elasticity requirements, subscription process, and fees. The final Migration Roadmap and Detailed Implementation Plan should also be part of the contract.

Phase G: Implementation Governance

Implementation Governance focuses on making sure that implementation projects conform to the agreed Cloud Ecosystem Target Architecture(s). This must not be seen as a silo’ed effort but as an aligned activity that supports an organization’s corporate, IT, and architecture governance.

Conformance is achieved through the proactive execution of an architecture compliance process. Rather than executing a compliance check at the end of the implementation, compliance is performed throughout the implementation at agreed compliance gates.

The rest of this section describes the steps taken in Phase G to achieve the overall goals of the architectural effort outlined for CloudEcoSource.

Confirm Scope and Priorities for Deployment with Development Management

The CloudEcoSource governance body decides on the scope and priorities of the Implementation Governance activities. This includes reviewing project and architecture artifacts, deployment challenges, and newly identified/updated CloudEcoSource Cloud Ecosystem SBBs being cataloged and marked for development.

Identify Deployment Resources and Skills

CloudEcoSource cloud implementation resources have to be made aware and educated on the architecture compliance process. In turn, this details the expectations of the implementation resources regardless of the method they utilize to implement the project.

Guide Development of Solutions Deployment

The goals, objectives, and plans for each CloudEcoSource implementation project are reviewed and conformance recommendations are made.

Perform Enterprise Architecture Compliance Reviews

The architecture compliance process is proactively executed where individual CloudEcoSource implementation projects are reviewed to make sure that they comply with the defined and agreed architecture, stated business objectives, and the overall cloud strategy.

Implement Business and IT Operations

Utilizing DevOps (Development Operations), CloudEcoSource leverages a strong collaborative relationship between the implementation teams and IT operations, which assists in decreasing the time, and lowering the risk in deploying the implementation projects.

Perform Post-Implementation Review and Close the Implementation

Once the implementations have been deployed to the Cloud Ecosystem they are reviewed and the results are then published.

Phase H: Architecture Change Management

The Architecture Change Management process ensures that the deployed architecture delivers maximum business value during its life cycle and that the architecture achieves its original target business value. This requires constant architecture assessment to ensure a well-managed architecture life cycle of the Cloud Ecosystem. It also ensures that the architecture capabilities have the flexibility to address ongoing changes in business and technology.

In order to ensure that the architecture continuously achieves its target business objectives and to avoid any business disruption, the Architecture Change Management process evaluates and evolves the Enterprise Architecture to appropriately address both internal and external factors to improve overall business performance. The following is a list of factors that need to be frequently assessed and appropriately addressed during the life cycle of the Enterprise Architecture:

Incremental improvements to architectural capabilities that are critical to the enterprise’s business processes transformation through automation
New performance improvement opportunities that enable efficient operational decision-making activities to enhance customers’ (both internal and external) experience
Business requirements to create/change how customers, partners, and suppliers interact with the Enterprise Architecture capabilities to enhance Enterprise Architecture value proposition and business operations
Ensure that service contracts with Cloud Service Providers have adequate provisions that allow enterprises to enable a change/exit/migration strategy without negatively impacting the Cloud Service delivery
Perform routine risk assessments for the enterprise on Cloud Service Providers and the utilization of Cloud Services; the assessments must reflect the changing landscape with possible timely adjustments to enable efficient use of the enterprise’s Cloud Ecosystem

The rest of this section describes the steps taken in Phase H to achieve the overall goals of the architectural effort outlined for CloudEcoSource.

Establish the Value Realization Process

In order to achieve business agility, CloudEcoSource must establish a cloud-first business policy to realize benefits and exploit its enterprise Cloud Ecosystem capabilities. This might require changes to organizational processes, performance matrices, and culture. Investments may be necessary to deliver the capabilities of the Cloud Ecosystem and to ensure that clear guidelines are established for the business value realization process. Establish benchmarks to assess the overall costs, service levels, and maturity level of business capabilities enabled by the enterprise Cloud Ecosystem.

CloudEcoSource needs to develop a catalog of IT services in order to track performance and costs associated with each service on its capabilities, usage, and the potential roles of Cloud Service Providers.

Deploy Monitoring Tools

CloudEcoSource established a cloud compliance process at the PMO level. The Cloud PMO identifies services and application re-use potential, establishes and shares change management best practices on service optimization and utilization of services provided by Cloud Service Providers, and tracks benefits realization by deploying monitoring capabilities. These monitoring capabilities provide critical information to assess the impact of business and technology changes on the enterprise Cloud Ecosystem. Having capabilities to track business performance, Quality of Service (QoS), and maturity assessments of services, CloudEcoSource has efficient operating models to better assess the overall viability (both internal and external Cloud Services capabilities) of the enterprise Cloud Ecosystem.

Manage Risks

Establish routine risk management to evaluate performance, financial position, and leadership of existing and potential Cloud Service Providers for the enterprise Cloud Ecosystem. Manage Enterprise Architecture risks and proactively adjust any Cloud Service Provider engagement in order to avoid any business disruption.

Provide Analysis for Architecture Change Management

Use the deployed monitoring capabilities for analysis and proactively identify business performance benchmarks for routine maturity assessments of the Cloud Ecosystem. Analyze Cloud Services maturity indicators to identify opportunities for improvement in the business capabilities of the enterprise Cloud Ecosystem. Ensure that any change requests to business capabilities adhere to established Enterprise Architecture governance guidelines, policies, and processes.

Develop Change Requirements to Meet Performance Targets

The change requests to the business capabilities of the Cloud Ecosystem must meet the performance targets for CloudEcoSource. Ensure that there is a clear understanding of current and future capabilities of Cloud Services and change requirements have a viable roadmap to deliver the required business capabilities (whether to build internally and/or use services provided by Cloud Service Providers).

Manage the Governance Process

CloudEcoSource must utilize the established governance process to evolve the enterprise Cloud Ecosystem in order to reduce the number of exceptions to the process. Any new/changed service must be in compliance with the Cloud Ecosystem Reference Model in order to minimize the exceptions to the Enterprise Architecture. The governance body of CloudEcoSource meets regularly to decide on ways to handle identified architectural changes to the enterprise Cloud Ecosystem.

The effectiveness of the governance process must be assessed periodically and applicable refinements made to the process.

Activate the Process to Implement Change

Activate the change process as described in the overall architecture governance process. The changes will be documented in the Architecture Definition Document and will describe the business performance objectives. The document describes how architecture change addresses new business requirements and policies.

Route the document for review by relevant stakeholders, incorporate received feedback, and determine whether review of the document is once again required. Once architecture change is approved and finalized, upload the documents in the Architecture Repository.

Requirements Management

Requirements Management is a process that is triggered by some organizational change that needs to be addressed (refer to Iacob et al.: Delivering EA with TOGAF and ArchiMate). It is a dynamic process in which the Enterprise Architecture requirements together with the subsequent changes are identified, stored, and used by the relevant ADM phases. As changes in requirements occur they may require iteration of the ADM. The focus of the Requirements Management process is to manage the requirements across the ADM rather than addressing and prioritizing the requirements (this is done within the relevant phase of the ADM) – refer to the TOGAF 9.1 Specification.

When a new architectural problem is assigned to the architecture team, the first task is to analyze the problem based on goals and requirements. This can be done with the Motivation Extension of the ArchiMate standard. The goals and requirements help to identify which combination of products, services, processes, and applications are needed to solve the problem and translate them into Enterprise Architecture models. If there are still unclear issues, the architecture team must repeat this process in order to refine and realize the elements of the architecture (refer to Iacob et al.: Delivering EA with TOGAF and ArchiMate).

Requirements Management and CloudEcoSource

The first step in the process of developing an Enterprise Architecture for the Cloud Ecosystem is to identify the architectural requirements. In order to identify and understand the requirements, the organization has to conduct need assessment and requirement analysis. The information can be gathered from the related stakeholders, cloud vendors, and cloud computing experts. A workshop (potentially using a business scenario) will be useful to identify the services that the organization needs and also the details of each service. More useful sources to elicit cloud-specific requirements are the cloud computing building blocks, service delivery models, deployment models, enabling technologies, and the essential characteristics of cloud computing. Advocate interviews can be the primary source of data collection to do requirements analysis. Below is a list of the cloud-specific requirements of CloudEcoSource.

CloudEcoSource Requirements – An Illustration

⇒ Acronyms

Open Platform 3.0™ Publications

The Cloud Computing Work Group

Open Platform 3.0™ Home

The Open Group Cloud Ecosystem Reference Model – Using the Cloud Ecosystem Reference Model with the TOGAF Standard (Informative)

Introduction

CloudEcoSource Background

Preliminary Phase

Architecture Principles

Define Governance Approach

Organizational Implications

Phase A: Architecture Vision

Establish the Architecture Project

Identify Stakeholders, Concerns, and Business Requirements

Confirm and Elaborate Business Goals, Business Drivers, and Constraints

Evaluate Business Capabilities

Assess Readiness for Business Transformation

Define Scope

Confirm and Elaborate Architecture Principles, including Business Principles

Develop Architecture Vision

Define the Target Architecture Value Propositions and KPIs

Develop Statement of Architecture Work; Secure Approval

Phase B: Business Architecture

Select Reference Models, Viewpoints, and Tools

Develop Baseline Business Architecture Description

Develop Target Business Architecture Description

Perform Gap Analysis

Define Candidate Roadmap Components

Resolve Impacts Across the Architecture Landscape

Conduct Formal Stakeholder Review

Finalize the Business Architecture

Update Architecture Definition Document

Phase C: Information Systems Architecture

Select Reference Models, Viewpoints, and Tools

Develop Baseline Data Architecture Description

Develop Target Data Architecture Description

Perform Gap Analysis

Define Candidate Roadmap Components

Resolve Impacts Across the Architecture Landscape

Conduct Formal Stakeholder Review

Finalize the Data Architecture

Create Architecture Definition Document

Phase D: Technology Architecture

Select Reference Models, Viewpoints, and Tools

Develop Baseline Technology Architecture Description

Develop Target Technology Architecture Description

Perform Gap Analysis

Define Candidate Roadmap Components

Resolve Impacts Across the Architecture Landscape

Conduct Formal Stakeholder Review

Finalize the Technology Architecture

Create Architecture Definition Document

Phase E: Opportunities and Solutions

Determine/Confirm Key Corporate Change Attributes

Determine Business Constraints for Implementation

Review and Consolidate Gap Analysis Results from Phases B to D

Review Consolidated Requirements across Related Business Functions

Consolidate and Reconcile Interoperability Requirements

Refine and Validate Dependencies

Confirm Readiness and Risk for Business Transformation

Formulate Implementation and Migration Strategy

Identify and Group Major Work Packages

Identify Transition Architectures

Create the Architecture Roadmap & Implementation and Migration Plan

Phase F: Migration Planning

Prioritize and Create a Migration Roadmap

Determine Resource Requirement and Cloud Infrastructure Provider

Determine the Cost/Benefit

Determine the Risks

Create a Cloud Migration Roadmap

Create Detailed Implementation Plan

Create Formal Migration Contract

Phase G: Implementation Governance

Confirm Scope and Priorities for Deployment with Development Management

Identify Deployment Resources and Skills

Guide Development of Solutions Deployment

Perform Enterprise Architecture Compliance Reviews

Implement Business and IT Operations

Perform Post-Implementation Review and Close the Implementation

Phase H: Architecture Change Management

Establish the Value Realization Process

Open Platform 3.0^™ Publications

Open Platform 3.0^™ Home