Practice Enterprise Architecture with BSS Transformation project using TOGAF ADM

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. 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. 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. - Develop Statement of Architecture Work.
PHASE B
- Define Organisation and Roles Catalog
- Define Business Use-Case diagram.

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. - 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. - Define Data/Business Matrix
- Define System/Data Matrix
- Define Data Lifecycle Diagram

8. - Define Data Security Diagram
- Define Data Security Matrix
- Define Data Migration Diagram

9. - System Use-Case Diagram
- Target Application Architecture and Gap Analysis with Target and Gap Application Co-
Operation view.

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. - Define Process Diagram

12. - Network Computing Hardware
- Communication Engineering Diagram
- Target Technology Architecture and Gap Analysis with Target and Gap Infrastructure
View.

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

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

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