Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Practising EA with BSS transformations


Published on

Practice Enterprise Architecture with BSS Transformation project using TOGAF ADM

Published in: Software
  • Be the first to comment

  • Be the first to like this

Practising EA with BSS transformations

  1. 1. How to start practising EA: Enterprise Architecture aims to align business strategy with the IT implementation and it does this according to Reference Architectures with a given transition plan iteratively. The idea is to develop re-usable building blocks and implement the strategy change in methodical way. (Architecture Vision, Business Architecture, Information Architecture, Technology Architecture, Implementation, Migration, Governance, Change Management) Solution Architecture: Solution Architect understands the AS-IS business context, goals, business KPIs, constraints, assumptions and systems and designs an E2E TO-BE solution in line with Enterprise Architecture plans and guidelines.
  2. 2. First Iteration for the AS-IS PRELIMINARY: - Select Tools (Enteprise Architect, Archi-mate vs UML) PHASE B: - Define existing Business Functions/Capabilities (Marketing, Finance, Sales, Customer Service with their functions) with information flows - Define the most important existing E2E business processes. PHASE C: - Define Baseline Information System Architecture to show application landscape, their connections and main data flows. - Define Baseline Data Architecture as part of Information Architecture. PHASE D: - Define Baseline Technology Architecture
  3. 3. Second Iteration for the TO-BE (Transition Architecture) PRELIMINARY: - Select Reference Models (ETOM, TAM, Telecom Reference Model) - Define Architecture Principles (defines what good business/architecture solution is) PHASE A: - Define initial TO-BE requirements. - Define the Driver, Goals and Objective Catalog - Define Stakeholders and the related Stakeholder Map - Define Business Functions/Capabilities Catalog (Marketing, Finance, Sales, Customer Service with their functions) with information flows - Define Goal Viewpoints - Define Architecture Vision. It initiates the iteration by setting its scope, constraints and goals. Architecture Vision represents the baseline and target architecture to explain the added value. - Identify and Mitigate Risks - Solution Concept Diagram (TO-BE)
  4. 4. - Develop Statement of Architecture Work. PHASE B - Define Organisation and Roles Catalog - Define Business Use-Case diagram.
  5. 5. - Define Functional Decomposition Diagram. - Define Event Diagram. - Define the most important E2E business processes. - Define the matrix between Application/Business Functions and Application/ Organisation Roles. The Application Usage viewpoint describes how applications are used to support one or more business processes.
  6. 6. - Target Business Architecture and Gap Analysis. The business architecture remains as is but also it is required to show how target architecture realises the business requirements. PHASE C: - Define Baseline Information System Architecture to show application landscape, their connections and main data flows. - Define Baseline Data Architecture as part of Information Architecture. - Define Data Mapping to Business Services.
  7. 7. - Define Data/Business Matrix - Define System/Data Matrix - Define Data Lifecycle Diagram
  8. 8. - Define Data Security Diagram - Define Data Security Matrix - Define Data Migration Diagram
  9. 9. - System Use-Case Diagram - Target Application Architecture and Gap Analysis with Target and Gap Application Co- Operation view.
  10. 10. - Application Migration Diagram PHASE D: - Define Target Technology Architecture - Define Technology Portfolio Catalog: The purpose of this catalog is to identify and maintain a list of all the technology in use across the enterprise, including hardware, infrastructure software, and application software. An agreed technology portfolio supports lifecycle management of technology products and versions and also forms the basis for definition of technology standards. It contains the following metamodel entities: Platform Service, Logical Technology Component, Physical Technology Component - System/Technology Matrix
  11. 11. - Define Process Diagram
  12. 12. - Network Computing Hardware - Communication Engineering Diagram - Target Technology Architecture and Gap Analysis with Target and Gap Infrastructure View.
  13. 13. PHASE E: - Define Change Scenarios considering business continuity. - Define Benefit Diagram - Define/Update “Architecture Definition Increment Table” - Define Transition Architecture representing the possible intermediate situation “plateau”. This is shown in Migration Viewpoint. Depending on the transition architecture selected, Project Context diagram is presented to show the scope of a work package. Project Context diagram links a work package to organisations, business function, services, processes, applications, data, technology that will be impacted by the project.
  14. 14. - Depending on Transition Architecture, define Deliverables and Work Packages. PHASE F: - Update the Draft Implementation Migration Plan with project cost, risks, values, priorities and implement the transition projects. - Coordinate the implementation projects with Consolidated Gaps, Solutions, Dependencies, Implementation Factor Assessment.
  15. 15. PHASE G: - Conduct manual Architecture Governance process on the deliverables by the Architecture Board. REQUIREMENTS: - Define Requirements Catalog: The Requirements catalog captures things that the enterprise needs to do to meet its objectives. Requirements generated from architecture engagements are typically implemented through change initiatives identified and scoped during Phase E (Opportunities & Solutions). Requirements can also be used as a quality assurance tool to ensure that a particular architecture is fit-for-purpose (i.e., can the architecture meet all identified requirements). The Requirements catalog contains the following meta-model entities: * Requirement * Assumption * Constraints * Gap