TOGAF and Cloud Enterprise Architecture

Enterprise Architecture (EA) is a key enabler for effective adoption of several architecture styles like SOA and Cloud Architecture. SOA and cloud in association with the big data movement are the leading EA-enablement technologies. EA is very much necessary regardless of changes to underlying technologies. In the last few years we have seen several architecture frameworks have evolved and helping companies (big and small) to develop and manage enterprise architectures. In this article we focus on how TOGAF can be used for developing and managing Cloud architecture in any enterprise. Cloud computing without EA will result in “spaghetti clouds” aligned with “cloud architortures”.

Keywords: EA practices, enterprise architect, TOGAF, Cloud Enterprise Architecture.

1.     Cloud computing and EA

Cloud computing is characterised by virtualised computing resources, incredible capacity and scalability, dynamic provisioning, multi-tenancy, self-service and pay-per-use pricing model. For businesses to adopt cloud computing in a way that aligns with their business strategy, EA is an absolute necessity (see below picture).

Based on a global study by Booz and company, organisational EA maturity levels are assigned a number between 1 and 5 and is called EA Maturity Index. In the picture below, we can see business value is realised only when EA maturity is “standardised”. Cloud computing is a good fit when the EA maturity is at least standardised.

This means the following:

• Different TOGAF Architecture domains are well defined and layered
  • Business Architecture
  • Data Architecture
  • Application Architecture
  • Technology Architecture
• Well defined Interoperability (ADM guidelines and Techniques)
• Internet / Web as the target
• Cost issues are identified
• New product and service offerings are identified and in line with the business strategy.

Leveraging on the standardised EA maturity, TOGAF ADM iterations should then be “Cloud Aware” and the Enterprise Architecture team drives the architecture development process working collaboratively with business and IT.

2.     Cloud aware TOGAF ADM

The TOGAF framework provides a model and process that is capable of incorporating both business-led and IT-led Cloud requirements in a holistic framework. This section assumes the TOGAF iteration involves all phases of ADM and no customisations are adopted.

Preliminary Phase

In the Preliminary Phase we should consider the addition of a step related to the creation of a strategy for the consumption and management of cloud services (public/private/hybrid clouds, semantic management, security, transactions). The governance framework also needs to include the processes, roles and responsibilities related to cloud services and operations. At this stage, we need to identify who in the business owns the cloud from both a user and service provider management perspective. New principles may be created referring to the Cloud when the organisation has a fairly mature Enterprise Architecture (maturity model) in order to fully take advantage of the Cloud.

Phase A

During Phase A, you may use a Business Scenario where you would identify in a workshop what are the business problems, business Requirements and identify a potential business solution. Stakeholders in this workshop may come from Business and IT Operations, Procurement, PMO, Data Center, Development, CxOs. Interoperability will be an important element of the phase. The Enterprise Architecture team will collaborate with the business to understand and scope the needs; align them with the Strategic Enterprise Architecture. Given the relatively low barrier to market entry, in the scenarios where the Business is not sure of the viability of their proposal, they could go straight to the Cloud instead of “experimenting” before solidifying their requirements. The result of this is that the business may embark on a path of no return. To avoid this, make sure that the Business Scenario is complete, only refer to business solutions without referring to any architecture style (as this will be discussed during Phase E) and signed off.

Phase B

During Phase B, some variations are needed to make the business architecture cloud aware. While the over all business goals of a SaaS enabled application will not change, the Business users themselves will be variable in a multi-tenant scenario and hence this View may need to be adjusted for different groups that the Cloud service will cater .  Especially the questions like  Who Does It, What Do They Do will change for Cloud Applications when compared to traditional on-premise enterprise applications. Cloud reference models could come in very handy at this stage. The following are some Cloud reference models to consider:

• IBM Cloud Computing Reference Architecture
• The Accenture Cloud Reference Model
• The Open Cloud Consortium Cloud Reference Architecture

The Security activities from TOGAF will have to be applied to all phases taking into account the company’s Security strategy. The TRM should be extended with cloud services.

Phase C

In Phase C, as in the previous phase, variations are required. The core Entity Relationship modeling of a cloud application may match that of its  traditional on-premise enterprise application counterpart , however  multi tenancy aspect will introduce new variations to the Logical Data Model. Also the process models for,  Data Security View  will be totally different from a on-premise application. Also, data integration may be an issue for cloud computing as it pushes information back into siloes, that IT may not have direct access to. It is also recommended to determine Data and privacy classification and to prioritise the risk criteria of what goes in the cloud and what stays on-premise.

Phase D

Within the application architecture, the Platform as a Service (PaaS) will abstract several traditional components that are part of the Application Architecture View and hence this view will be different from a traditional enterprise application.

Technology architecture will see the maximum changes in the Cloud context. When addressing concerns around acquiring Commercial Off-the-Shelf (COTS) software and hardware for teh system, Cloud architecture is way different from its on-premise counterpart.

Due to the nature of Cloud deployment, we need to consider factors like virtualised server environment, PaaS platform, on demand instances, dynamic provisioning of virtual storage, scalability (both vertical and horizontal) and so on.

Phase E & F

There is a need to understand the Cloud resources which may exist or not. A new step will also be dedicated to identify candidates’ services in the Cloud.

Instead of providing standardized ROI or cost-benefit analysis justifying the products that need to be bought or charge-backs that need to be agreed upon upfront for shared assets, the Business can provide operational expenditure outlines and may go out to the Cloud to source their requirements.

Overall, what matters is defining the value to business. Value can be defined in many ways. It does not just mean the financial values of Total Cost of Ownership (TCO) and Return on Investment (ROI), but can also mean customer value, seller provider value, broker value, market brand value, corporate value, as well as technical value of the investment. The picture below shows the Cloud ROI savings models:

Phase G

In the Governance phase, the following activities may be included on top of the standard ones.

• Business processes (Process-as-a-Service)
• Applications (Application-as-a-Service)
• Data (Information-as-a-Service and Database-as-a-Service)
• Technical services (Storage-as-a-Service and Infrastructure-as-a-Service)
• Security and operations implementation will have to be taken into consideration during the relocation. Security can also be considered as “Security-as-a-Service”.

3.     Conclusion

The following picture summarises the additional activities which should be considered in the ADM cycle.

Cloud services can be mapped to the TOGAF metamodel as shown below:

The design and development team now have to be familiar and conform to the Cloud API and services. This makes it relatively easier to govern the architecture usage within the enterprise.

With some exceptions, traditionally the Enterprise Architecture team were not relevant to the Operation side of the organisation, but with the Cloud, even that seems to be disappearing. The common cloud management platform will provide the relevant tools for management and reporting and take away the onus of patch management, version upgrades, high availability, disaster recovery and so on.