Cloud Computing requires Enterprise Architecture and TOGAF 9 can show the way

Enterprise Architecture is necessary regardless of changes to underlying technologies. If managed properly, Enterprise Architecture will iterate and adjust to the winds of change. Client/server, SOA, RFID, Cloud, and other technology developments should be considered as styles, but Enterprise Architecture is at the heart of change. Cloud computing should have little impact on Enterprise Architecture.

It is the role of the Enterprise Architecture team to:

· Investigate if any style is simply hype or whether it holds real business value

· Understand the benefits and risks of a specific style

· Communicate these to Business and IT

· Develop an adequate governance framework

· Align the “style” with business requirements

· Give guidance for sustainable innovation

If Cloud computing does not take Enterprise Architecture into consideration, it will result in “spaghetti clouds” (aligned with “spaghetti architectures”).

Cloud computing is often characterised by: virtualised computing resources, seemingly limitless capacity and scalability, dynamic provisioning, multi-tenancy, self-service and pay-for-use pricing. Enterprise Architecture can help to make the shift to cloud computing smooth.

For organisations focusing more on Technology Architecture, Cloud computing could be a “big hit”. But for businesses that want to successful adopt cloud computing in a way that aligns to their business strategy, Enterprise Architecture is imperative (refer to above diagram).

Cloud computing may be a fit when the core of internal Enterprise Architecture is mature. This means:

· As recommended in TOGAF. well defined and layered:

o Business Architecture

o Application Architecture

o Data Architecture

o Technology Architecture

· Well defined interoperability (ADM Guidelines and Techniques)

· Low level of security agreed (during the Architecture Vision)

· Web as a target

· Costs issues

· New products and services

Cloud computing may not be a fit when the core of internal Enterprise Architecture is immature. This means:

· Business, Application and Data architectures are tightly coupled

· Low level of interoperability defined

· High level of security required

· When applications have IPAs (Information Provider Applications) with only proprietary interfaces

· When solutions are legacy

Where there is could be a good fit, a TOGAF iteration should then be “Cloud Architecture aware”. The Enterprise Architecture team drives the programme and works collaboratively with both the business and the IT department.

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

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, COO/CIO/CTO. 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 (bringing to bear the existing technological capabilities that can satisfy those needs thereby promoting sharing, reusing or building new ones if needed). Given the relatively low barrier to 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.

Start the architecture considering Phase B, C and D.

At that stage, it is be recommended that you consider a Cloud Reference Model. This is a description of the appropriate Cloud industry standards, the dimensions of the Cloud problem space, and the decisions and choices that apply to a Cloud computing for an organisation. A Cloud reference model, reference architecture and reference implementation approach is an accepted approach for planning and implementing Cloud computing. Different Cloud Reference Models can be considered such as those published by

· The Open Cloud Consortium

· The Cloud Security Alliance

· The Cloud Computing Reference Model (CC-RM) and Reference Architecture framework from AgilePath

· The Accenture Cloud Reference Model for Application Architecture with its 7-layers. Like the OSI Model for networks, this Cloud Model is layered to separate concerns and abstract details

There is also an on-going initiative by the Open Group to deliver a Cloud Reference Model.

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.

In phase C: Data Architecture, Data integration, in particular 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.

During phase E and 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 now having to provide 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. No surprises with CapEx, decreased new product introduction training line item expenditures (many products are “standards “which means, lots of documentation and books available, e-learning, etc.), different charge-back agreements between Finance and Business Units (the organisation may have accesses to the service independently from his internal structure), in short, no need to conform to existing enterprise-wide Reference Architectures to meet individual project needs. In relation to this, the recent Open Group white paper “Building Return on Investment from Cloud Computing” is a valuable source of information.

During Phase G, activities may also include the relocation of:

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

The following diagram summarises the additional activities or concerns which should be considered in the ADM:

Below is a diagram which maps the various Cloud services to the TOGAF Metamodel.

The development and deployment teams would now be sourcing from and conforming to the Cloud API and services, without the Enterprise Architecture team becoming policeman, enforcing the reference architectures or corporate standards at various checkpoints (compliance and dispensation activities will remain for internal new systems). With overarching cross-project oversight not relevant anymore, each project would tend to work in its own Cloud development sandbox, party engendered by the partitioning paradigm of the Cloud itself.

Barring some exceptions, traditionally the Enterprise Architecture team has not been relevant to the Operation side of the organisation, but with the Cloud, even that seems to be disappearing. The Cloud providers will furnish the relevant tools for management and reporting and take away the onerous tasks of patch management, version upgrades, high availability, disaster recovery and the like.

New technologies styles are exciting, but using technology styles just for the sake of technology does not bring a real value. Technology use should be driven not by its "coolness factor", but rather by business requirements and an underlying Enterprise Architecture such as TOGAF. Moving some applications to the Cloud can make some infrastructures go away, but badly designed solutions won’t be improved by relocating to the Cloud.

What is Enterprise Analysis: does it differ from Enterprise Architecture?

Enterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?

At first sight, business opportunities are not always considered as being part of an Enterprise Architecture initiative, more as an activity which should be considered as an input. But let’s look at this in more detail.

Let’s look at this in more detail by way of mapping activities between BABOK v2* and the TOGAF 9 Framework*. The BABOK is the collection of knowledge within the profession of business analysis and reflects generally accepted practices. It describes business analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in the execution:

BABOK v2 Knowledge Area Activity in Enterprise Analysis	Definition	Enterprise Architecture (e.g TOGAF 9)	Differences, observations
Requirements Elicitation	This describes the interview and research process-how to best extract needs from stakeholders (and even how to recognize needs they don't know they have).Elements such as metrics (tracking the amount of time spent eliciting requirements) and elicitation techniques (prototyping and brainstorming are just a couple) among the topics covered	Phase A: Architecture Vision is the initial phase of an architecture development cycle. It includes information about scope, the key steps, methods, information requirements and obtaining approval for the architecture development cycle to proceed	Business scenarios are a useful technique to articulate an Architecture Vision. A Business Scenario describes, a business process, an application or set of applications enabled by the proposed solution , the business and technology environment, the people and computing components (called “actors”) who execute it, the desired outcome of proper execution To build such a Business Scenario, workshops with business users (stakeholders) would be organized
Business Requirements Analysis	This describes how to write/state requirements that will meet business needs. Key objectives include methods for prioritizing and organizing requirements, as well as the most beneficial techniques for requirements presentation (including state diagrams, prototyping, data flow diagrams, and process modeling, and more). Business Requirements for future project investments are identified and documented. They are defined at a high level, and include goals, objectives, and needs are identified	Business Requirements are collected from business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above). That document identifies what will be the business solutions in generic terms	The Enterprise Architects will define the Architecture Vision phase based on the goals, and objectives of the enterprise gathered from the business. There are two steps: 1. Business people will have defined the goals and the objectives of the enterprise independently from the Enterprise Architecture team 2. The Enterprise Architecture team which include business people gather the requirements based on the previous activity
Enterprise Analysis	Begins after a Business executive team develops strategic plans and goals This outlines the crucial (and sometimes political) process of keeping everyone in the loop and on the same page regarding project's direction and progress. This activity delves into such details as the requirements review and approval processes (including record-keeping).	Most of these activities are taken into account in doing Enterprise Architecture or done directly by the Business executive team before starting an new Enterprise Architecture project
	Strategic plan development		Done outside of the Enterprise Architecture process by business people but is a key source of information
	Strategic goal development		This is done outside of the Enterprise Architecture initiative by business people but is a key source of information
	Business Architecture development		Done during Phase B:Business Architecture, looking at the baseline and target architecture, delivering a gap analysis, a plan and a roadmap
	Feasibility Studies		Done during Phase A: Architecture Vision (with a Business Scenario)
	Business Case Development		Done during Phase A: Architecture Vision (with a Business Scenario)
	New Project Proposal		This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning
	Selecting and Prioritizing New Projects		This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning
	Business Opportunities		This is done during the Phase A: Architecture Vision and the Phase E: Opportunities and Solutions
	Launching New Projects		This is done during Phase F: Migration Planning
	Managing Projects for Value		This is done during Phase F: Migration Planning
	Tracking Project Benefits		Once the project is in production, it is no longer part of the Enterprise Initiative
Solution Assessment and Validation	Details how to choose the best solutions for specific business needs (as well as assessing how well the chosen solution worked after its implementation).This should also cover risks, dependencies, and limitations that must be identified before proposing any solution	Solutions are identified during Phase E.: Opportunities and Solutions. This phase is directly concerned with implementation, identifying major work packages to be undertaken and creating a migration strategy. Risk management, dependencies are taken into consideration.
Business Analysis Planning and Monitoring	Explains how to decide what you need to do to complete an "analyst effort" (in other words, how to plan a project). This helps intelligently decide which stakeholders, tools, tasks and techniques we will need to get the job done	Covered mostly in the Architecture Vision phase, then in the Business Architecture Phase	Stakeholder management techniques are used within TOGAF, tools and techniques are identified in the Business Architecture phase (modeling, reference models, viewpoints)
Requirements Management and Communication	Describes how to identify business needs (the why of the project; whereas requirements are the how) and state the scope of their solutions. This is a crucial piece of the analyst's work. SMART criteria of measurement, SWOT analysis and other measurement factors that make identifying this root cause data objective and tangible are used	Business Requirements are collected with the business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above).	SMART techniques are equally used. Communication plans are defined.

 

This diagram below is a draft map BABOK® and TOGAF 9; more work is required!

 

Observations

There are obviously overlaps between Enterprise Analysis and Enterprise Architecture, but activities are not always done in the same sequence.

• Enterprise Analysis is more a business initiative than an Enterprise Architecture which includes both business and IT people
• Enterprise Analysis provides the context in which an Enterprise Architecture should be conducted
• Enterprise Analysis is about defining the strategic goals and the strategic planning taking into account the environment and market trends, identify business issues, focus on remaining competitive, profitable, efficient. Enterprise Architecture is reusing all this information.
• Enterprise Analysis is only covering the initial activities of Enterprise Architecture but does not address other Enterprise Architecture activities such as: - Application Architecture, Data Architecture, Technology Architecture (and Solution Architecture).
• Enterprise Analysis does not include all aspects related to governance such as the IT Governance and the Enterprise Architecture Governance Framework. Touch points with other frameworks are not addressed.
• Enterprise Analysis may not completely address the need of working with other parts of the enterprise such as IT, PMO, development teams, IT partners.
• Enterprise Architecture suggest a Preliminary phase which is about defining ‘‘where, what, why, who, and how” Enterprise Architecture will be done, establishing the business context, customizing the framework, defining the architecture principles, establishing the Architecture Governance structure.

Enterprise Analysis complements Enterprise Architecture but also overlaps in some areas. Organization looking into Enterprise Architecture and specifically TOGAF 9 may consider adopting a Business Analysis framework such as BABOK and integrate them in the Preliminary Phase. If both approaches exist in a company, this would be a great opportunity for optimizing the alignment between Business and IT, and to run an Enterprise Architecture program from a complete business perspective.

About Business Analysis Body of Knowledge® (BABOK®)

The Business Analysis Body of Knowledge® (BABOK®) is the collection of knowledge within the profession of Business Analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the Business Analysis professionals who apply it in their daily work role. The BABOK® Guide describes Business Analysis areas of knowledge, their associated activities and the tasks and skills necessary to be effective in their execution. The BABOK® Guide is a reference for professional knowledge for Business Analysis and provides the basis for the Certified Business Analysis Professional™ (CBAP®) Certification.

BABOK® Guide 2.0 represents the development of a common framework to understand and define the practice of business analysis.

http://www.theiiba.org/am/