Skip to main content
╳

Togaf For Cloud Transformation

Cloud transformation is the process of moving a specific work or organisation to the Cloud to improve business operations, profitability, and resilience. This could mean moving organisation’s applications, internal and client data, and software programs. Cloud is a computing model, where computing resources are available on demand, can be accessed over a network, enables sharing of resources between multiple applications and tenants, scales elastically based on dynamic computing needs, and provides measured service.

It began with Software as a Service (SaaS), where vendors started providing business applications over internet, to consumers without being worried about hardware, deployment, maintenance, operation and support associated with on-premises commercial software. “Cloud” really got popular with Platform as a Service (PaaS), Infrastructure as a Service (IaaS) and now “Everything as a Service” (XaaS).

Cloud Transformation Challenges

Cloud transformation has impact on business and IT processes, operations, technology/platform, applications, people, and security. Most organizations have cloud on their road map, and adoption is increasing dramatically but still many organizations, especially those who have been running their business traditionally on-premises, face many challenges going through this transformation. Cloud transformation has different meanings for different organizations based on cloud model – public, private, community and hybrid.

Some of the challenges are -

  • Deciding right cloud model – public, private, community or hybrid cloud
  • How and where to start from, which applications, services, location should be moved first
  • Approach for moving applications to cloud – fork lift, optimize and move or move and then optimize for cloud
  • Understand the impact on the business processes, people, skills, application development, deployment, disaster recovery, security, operation and support model
  • Adopting new IT finance model – cap-ex to op-ex. Comparing total cost of ownership (TCO) for on-premises and cloud
  • How to govern and operate cloud and cloud services
  • Moving from traditional operation/support to DevOps approach required for cloud

What Is Togaf?

TOGAF is a popular enterprise architecture framework. Core of TOGAF is its ADM (Architecture development method), a step by step process to develop the enterprise architecture. TOGAF provides ADM, tools, guidelines and guides to establish, apply, and govern enterprise architecture. Enterprise architecture aligns IT to business, enabling business to achieve its goals. TOGAF can be used for any enterprise transformation, such as IT expansion, technology/platform upgrade, infrastructure/data centers consolidation, in response to business change. TOGAF can be used to establish enterprise architecture practice capability within an organization.

TOGAF defines Building Blocks, which are reusable business, IT, and technology components, combined with another building block to deliver the architecture and solution. There are two categories of building blocks. Architecture Building Blocks (ABB) used to define the enterprise architecture and high-level capabilities. Solution Building Blocks (SBB) are used to realize the enterprise architecture. For example, if architecture has a database architecture building block, during implementation this can be delivered by RDBMS or No-SQL solution building block based on requirement.

Enterprise Architecture Engagement Types For Cloud Transformation

How Enterprise Architecture function/practice can be engaged during enterprise cloud transformation -

  • Identification of changes for cloud transformation– To assess and ensure cloud transformation is aligned to business strategy, objectives and goals. Assess baseline application, technology, and platform and plan how to support business during cloud transformation.
  • Defining the cloud transformation– Understand the cloud transformation and align business and various IT stakeholders – support, operation, infrastructure, and security around it. Understand what needs to be changed based upon target cloud model.
  • Defining the cloud transformation– Understand the cloud transformation and align business and various IT stakeholders – support, operation, infrastructure, and security around it. Understand what needs to be changed based upon target cloud model.

Adm For Cloud Transformation

Architecture Development Method (ADM) forms the core of TOGAF framework designed to address enterprise’s business and IT needs by providing-

  • set of architecture views (business, data, applications, technology)
  • Guidelines on tools for architecture development
  • A Method for managing requirements

It recommends a sequence for various phases and steps involved in developing an architecture.

Each phase goes through primarily three steps-

  • Inputs – output from previous phase
  • Activities
  • Output

Preliminary Phase

This is preparatory phase for cloud transformation endeavour.

  • Enterprise tailored TOGAF – organization should tailored the TOGAF according to their need
  • Business and IT function objectives, goals, and strategy
  • IT Organization Governance model
  • Architecture repository
  • Architecture principals
  • EA governance model

Activities

  • Decide the frameworks for cloud transformation e.g. AWS Cloud Adoption Framework, project/portfolio management framework
  • Define how cloud transformation is aligned to business objectives and goals
  • Create new principals for cloud based IT organization Specially, the security principals should be revised carefully to ensure same level of security in cloud as on-premises. Define new principals in the area of
    • Cloud service provider portability, service provider agnostic solution
    • Cloud resources provisioning automation
    • Cloud resource utilization optimization
    • Cloud monitoring and auditing, cloud matrices for effective optimization

Phase A: Architecture Vision

Objective of Phase A is to develop aspired cloud vision, and define the business value of Cloud Transformation.

Input

  • Governance Strategy
  • Architecture repository

Activities

  • Define the scope for cloud transformation. Scope can be based on
    • Organization size and/or business segment/division
    • Location e.g. move to specific cloud region or move a data center to cloud
  • Location e.g. move to specific cloud region or move a data center to cloud
  • Identify the stakeholders, their concerns and business requirements.Main stakeholder are-
    • Business – how its current SLA with IT will be improved in new cloud model
    • IT – most impacted stakeholder. IT operations & support, security, technology, applications, services, and application development, will be affected by adopting cloud
    • Finance –adopt new IT cost model, from cap-ex to op-ex, pay-as-go
    • Security & Compliance – requires to mitigate risks, address security and compliance concerns related to cloud e.g. IP protection, cloud service provider security assessment.
  • Security & Compliance – requires to mitigate risks, address security and compliance concerns related to cloud e.g. IP protection, cloud service provider security assessment.
    • Management willingness and support – Fortunately most CIOs have cloud on their strategic road map, no one wants to feel left behind
    • Business case for cloud – what value, cloud will bring to business
    • Funding – Does organization have funds for cloud transformation project
    • Governance – Specially, does IT has capabilities to govern cloud based IT
    • IT Readiness – Does IT has skills required to operate and support cloud
  • Define architecture vision. Decide the appropriate cloud model for organization-
    • Public
    • Private
    • Hybrid
  • Identify the metrics to measure the Cloud Transformation business value e.g.
    • Cloud total cost of ownership (TCO)
    • Reduction in provision time & in help desk tickets due to self-provisioning
    • Increased innovation and research
  • Identify the Risk and mitigation e.g. Compliance, Security, SLA

Output

  • Statement of Cloud Transformation architectural work
  • Cloud Transformation architecture vision & Business Readiness assessment
  • Cloud Transformation stakeholder map, concerns, requirements, and communication plan

Phase B: Business Architecture

In context of Cloud Transformation, business mostly means IT function. This phase will describe the IT services, strategy, organization, processes, and geographic aspect of IT environment.

Inputs

  • IT principals, goals and drivers
  • Existing business architecture artifacts

Activities

  • Define Baseline business architecture
  • Define Target business architecture based on cloud model
  • Define Target business architecture based on cloud model
    • Process & People gap
    • Application/tools gaps- new tools required for cloud operation and support
    • Location/physical facility gap

Output

  • IT services-interaction catalog
  • IT processes – including new processes for cloud model
  • IT Service SLA/contract – draft modifications for contract with existing vendors and draft contract for Cloud service provider
  • IT Actor catalog – new roles in cloud based IT organization – e.g. Cloud Solution Architect, DevOps, Cloud Administrator

Phase C: Information Service Architecture

This phase involves analysis of applications and data architecture, using data or application driven approach. Application driven architecture approach is more suitable for Cloud Transformation as most of changes will be happening at application platform level. Data-driven approach, is suitable for business process transformation e.g. replacing ERP system

Input

  • Data architecture principal
  • Data regulatory and compliance requirement
  • Application architecture principals
  • Application portfolio
  • Architecture repository

Activities

  • Define baseline Application and Data architecture
  • Define target application and data architecture, based on target cloud model
  • Gap Analysis Baseline to target data architecture building blocks

Output

  • Updated data security model
  • Application change list
  • Matrices
    • Application-cloud/on-premises mapping
    • Baseline to cloud (target) application architecture building blocks
    • Baseline to cloud (target) data architecture building blocks
  • Diagrams - Data dissemination diagram – including data distribution, replication, archival

Phase D: Technology Architecture

Logical and physical architectures for previous architecture phases are developed in this phase. Technology architecture defines platform and runtime environment for applications and services. For Cloud Transformation, most of work will be related to Technology architecture phase.

Input

  • Architecture repository and existing Technical reference model
  • Cloud Reference Model e.g. The Open Group Cloud Ecosystem Reference Model
  • Technology architecture principals and application-technology matrix

Activities

  • Define baseline technology architecture
    • Define logical and physical technology architecture building block
    • Collect infrastructure sizing and capacity information
    • Infrastructure deployment topology
    • Technology configuration – servers configuration, VM images, network configuration
  • Define target technology architecture based on target cloud model
    • Define the Technology architecture building blocks available in cloud model
    • Map baseline technology architecture to target cloud technology architecture building blocks based on cloud model. If baseline architecture building block is not available then find the alternative. E.g. some license server cannot be deployed on VM, find the license service available in cloud
    • Address non-functional requirements including integration and interoperability
    • Define any security impact, risks and mitigation strategy for target technology architecture
    • Identify tools to operate and support cloud based technology architecture – monitoring, auditing, logging, deployment
    • Identify cloud network building blocks including connectivity between on-premises and cloud
  • Gap Analysis
    • Infrastructure gap - e.g., Disposition of current infrastructure if moving everything to public cloud.
    • Platform gap - Certain hardware/OS version may not be available in cloud, it will require to upgrade application platform stack.
    • Network architecture gap - Segregation of resources in cloud using cloud network building blocks.
    • Security architecture gap - e.g. On-premises HSM vs cloud HSM
  • Based on the gap analysis it may be required to go back to Architecture Development Phases B or C.

Output

  • Updated technology catalog
  • Updated application-technology matrix with cloud building blocks
  • Deployment topology diagram with cloud regions
  • Network and communication diagram with connectivity between cloud and on-premises

Phase E: Opportunity/solutions Phase

In this phase, the architecture road map for delivering the target architecture, is defined. Architecture road map may have one or more transition architectures. This phase also start outlining cloud solution building blocks, corresponding to architecture building blocks identified in previous architecture phases.

Input

  • Architecture repository
  • Outputs from previous phases

Activities

  • Cloud Transformation implementation factors assessment – analyse factors that can affect the cloud transformation. This includes assessment of resources and capabilities required for Cloud Transformation.
  • Analyse factors and their impact on the target architecture and Cloud Transformation implementation plan
  • Identify any business constraint. Business strategic goals will impact the cloud transformation implementation. e.g. financial/budgetary constraint, merger/acquisition
  • Consolidate gaps from architecture phases. This will help identifying the cloud solution building blocks for target architecture
  • Reconcile interoperability and migration requirement-
    • Plan migration of on-premises data to storage options available in cloud – block, object storage, RDBMS to No-SQL
    • Hybrid cloud model need some building block to translate/transform application/data for interoperability e.g. file gateway for syncing on-premises and cloud storage, DNS resolution between on-premises and cloud resources.
    • Address applications, services and data interoperability between SaaS, public clouds, private and on-premises
  • Identify the dependencies between business processes, services, applications, infrastructure, and locations. These interdependencies will help planning and sequencing Cloud Transformation implementation and migration projects.
  • By now team will be equipped with more information, reconfirm the Business Readiness assessment, done during Phase A – Architecture Vision
  • Identify the Cloud Transformation implementation strategy
  • Group Cloud Transformation changes into work packages based on architecture gaps and applications/services interdependencies.
  • These work packages will be the basis for Cloud Architecture Transformation implementation and migration projects
  • Identify the Cloud Transformation transition architectures. Each transition architecture should add some business value. Examples of transition architectures
  • Draft architecture road map based on work packages and transition architectures, with timeline

Output

  • Consolidated architecture gaps between baseline and cloud target architecture
  • Cloud Transformation transition architectures
  • Cloud Transformation transition architectures

Phase F: Migration Planning

Cloud Transformation implementation and migration will be planned in this phase. With finalized architecture road map, Cloud Transformation implementation and migration plan is aligned with enterprise program/project portfolio. All stakeholders should understand the plan and Cloud Transformation transition/target architectures business values.

Input

  • Besides architecture repository and outputs from previous phases, this phase also needs
    • Organization governance model
    • Business planning tool
    • Program/project management tool and SDLC methodology

Activities

  • Confirm program/project management framework interactions. Implementation and migration plan is expanded to have detailed project plans. Define how tools for program/project portfolio management, enterprise architecture, IT operation and support service (i.e. ITIL) will be used for Cloud Transformation implementation and migration planning
  • Assign business value to each work packages and transition architectures identified in Phase E. This is used to prioritize the Cloud Transformation projects and measure value e.g. SLA improvement because of higher availability (less downtime) etc.
  • Identify cloud transformation business value matrices.
  • Identify resources, timelines and TCO estimates for Cloud Transformation implementation
  • Assess Cloud Transformation implementation projects cost/benefits

Output

  • Cloud Transformation implementation and migration plan/road map with projects
  • Finalized Architecture documents

Phase G: Implementation Governance

Work in this phase for cloud transformation will be similar to any other enterprise architectural endeavour. After Implementation and Migration planning is done, the architecture work will be handed to cloud solution implementation team. Cloud solution implementation team will start implementing the transition architectures. In case of Cloud Transformation, implementation team will include cloud solution architects, application developers, application owners, cloud administration, and cloud DevOps team. Solution implementation team will design, build and deploy the Cloud Solution Building blocks.

Input

  • Architecture repository
  • Enterprise architecture organization and governance model

Activities

  • Review the Cloud Solution Architecture building blocks. Analyse the gaps between cloud architecture and cloud solution building blocks. Cloud solution architect identifies solution building blocks available in target cloud model to fill these gaps.
  • Ensure the cloud solution building blocks are aligned to architecture building blocks.
  • Provide guidance to the Cloud Transformation implementation team
  • Implement IT operation for cloud model. Ensure IT operation team has the skills to manage and operate cloud. Get required training to build skills for cloud operations. “Infrastructure as a Software” – all the infrastructure and configurations should be programmed and treated as code, no more manual provision and configuration.

Output

  • Cloud Transformation implementation projects compliance assessment result. Based on cloud model, have
    • SaaS, PaaS and IaaS assessment checklist.
    • Cloud security controls checklist
  • Change request – document any change required to achieve target architecture. Change request will trigger another iteration of architecture development phases B, C, D. Example
    • Cloud service provider doesn’t have technology to support required security level for an application. Create change request to re-architect application or explore other cloud model or vendor.
    • Cloud provider may not have support for particular OS or database version. This may require to upgrade application runtime environment stack.
  • Cloud governance and operation mode

Phase H: Change Management

For large organization Cloud Transformation can run for many months or year. It is very unlikely that nothing change during transformation. Some example of changes that can affect the Cloud Transformation implementation are –

  • Change in scope, based on business drivers, objectives and goals e.g. Business expansion, contraction, change in business partners/customers will affect the sizing, and capacity planned for cloud resources
  • Business need to enforce new business regulation. Example – because of change in Safe Harbor law, organization that have been storing European consumer data in US, now will have to store data in Europe. This will require change to cloud architecture model to have cloud resource/service in the Euro region
  • Business need to enforce new business regulation. Example – because of change in Safe Harbor law, organization that have been storing European consumer data in US, now will have to store data in Europe. This will require change to cloud architecture model to have cloud resource/service in the Euro region
  • Some new building blocks are available or discontinued by cloud service provider. Cloud vendors have been continuously expanding their service portfolio.Architecture Change management process navigates cloud transformation through ever changing environment. Change management process can initiate new architecture development cycle or architecture development phase to accommodate the change, based on its size and impact. Change management process is used to manage changes during and post cloud transformation.

Input

  • Architecture repository
  • Business and technology change requests

Activities

  • Monitor business and technology changes
  • Monitor cloud value realization metrics indicating any change required to cloud architecture model
  • Manage risk – asses cloud service provider post transformation. Use multiple providers to mitigate service continuity risk
  • Assess size and scope change and its impact
  • Establish cloud maturity target. Create policies and practice for cloud usage, automation and optimization, cloud-first policy
  • Implement change, initiating full architecture development cycle or architecture phase to handle the change request
  • Document any change to cloud architecture.

Output

  • Document any change to cloud architecture.

Requirements Management

It manages the architecture requirements and any change to requirements throughout ADM. Requirements are recorded in Requirement repository. As shown in ADM model, it is in the center of ADM, which means all ADM phases require Requirements Management. Requirements can change during any architecture development and implementation phase. Requirement management records the requirement which is addressed in other phases of ADM. Architecture Vision phase will start with Cloud Transformation requirement. Requirements will be validated in each ADM phase and if required, changed and recorded. For Cloud Transformation project, requirements will come from business, IT, security, cloud service provider and implementation partner.

TOGAF provides systematic approach, helping business and IT to manage and go through the changes required for successful Cloud Transformation. Cloud Transformation also provides opportunity to revamp the technology stack for applications and services.
Let’s engage
SEND US A MESSAGE