Table of Contents (TOC) to define Enterprise Architecture roadmaps. This includes overview of Architecture Roadmaps, Table of Content (TOC) and context setting. Information technology strategy realization

1. Review and update Architecture Processes:
Table of Contents (TOC) to define Enterprise Architecture
roadmaps
Mohan K
http://www.mohanbabuk.com/
https://www.linkedin.com/in/mohanbabuk

2. 2
Agenda
● Architecture Roadmap context setting
● Overview of Architecture Roadmaps
- Business Architecture (Functional) Roadmaps
- Landscape and Portfolio Roadmaps
- Application Roadmaps
- Technology Roadmaps
● Table of Content (TOC) for Roadmaps

3. 3
Architecture Roadmaps
Why: “The Architecture Roadmap lists individual work packages that will realize the Target Architecture
and lays them out on a timeline to show progression from the Baseline Architecture to the Target
Architecture.” – TOGAF
Roadmaps should guide project and program investments. They should be defined by domain teams at
appropriate points in Architecture life cycle.
What Roadmaps do we define? Architecture Roadmaps will address key aspects of the value chain
Business Architecture
•Business Strategy
•Organisation Structure
•People and Processes
•Business Architecture:
Functional Roadmaps
Information
Architecture
•Information Policy
•Enterprise Data
Standards
•Landscape and Portfolio
Roadmaps
Applications
Architecture
•Applications and
Domains
•Integration Services
•Application Roadmaps • Infrastructure and Cloud
• IT Architecture
Roadmaps
Technical Architecture

4. 4
When: Business roadmap definition use-cases include:
• Roadmaps defined for transformational programs
• Functional roadmaps may also be defined as business strategy and requirements
evolve
• Roadmaps developed for CIO and executive review
• Roadmaps from Technology Foresight used to define business-case
Who needs the roadmaps?
• Business roadmaps will be used to guide technology investment decisions and
ensure alignment of project with business strategy.
• Business Partners and Business Architects will also use the roadmap for
technology alignment across business functions
Accountable: Domain Architect (with Business stakeholders - Business Partners and
functional leaders)
Business Architecture: Functional Roadmaps
• Functional roadmaps will be used to align with business capabilities, processes and
people
• Business roadmaps may highlight Architecturally significant use cases and capabilities
for local, regional and global business function
• Roadmap for business domains will help projects align with global business strategy
and technology direction

5. 5
Functional Roadmap Templates

6. 6
When: Portfolio roadmaps are typically defined/updated for transformation programs and
executive review sessions, and updated periodically during the program
Who needs the roadmaps?
• Business Architects and Project Architects will need Landscape and Portfolio
Roadmaps to ensure business case for project proposals are aligned with
technology strategy.
• Landscape Roadmaps will also be used during Architecture governance (ARB
review) sessions to ensure alignment of application roadmaps with enterprise
technology strategy, processes and policies
Accountable : Program Architects (with Program manager and other project stakeholders)
Landscape and Portfolio Roadmaps
• Landscape and Portfolio Roadmaps typically highlight the big picture of the technology
and systems. (similar to ‘City Plans’).
• This include inputs from technology vendors, emerging technologies, business
roadmaps and identified risks
• Portfolio roadmaps will consider system constraints, data flow and other dependencies
while highlighting solution building blocks (SBBs)

7. 7
Landscape and Portfolio Roadmaps (Examples)

8. 8
Application Roadmaps
When: The application roadmap should be defined/updated during Solution Design
phase of projects and included for Architecture governance (ARB review) sessions
Who needs the roadmaps?
• Project Architects need application roadmaps to ensure solutions being designed
and updated are aligned with portfolio roadmaps and guidelines
• Application Roadmaps are useful to communicate the value, alignment and context
of project during program reviews
Accountable: Domain/ Application Architect (with Enterprise Architects)
• Application roadmap will highlight the progression of applications in context of the
landscape
• For large programs, updates to application roadmap may have to be done with
updates to corresponding landscape roadmap.

9. 9
• When: IT Architecture roadmap should be defined/updated during Solution Design
phase of projects and included for Architecture governance (ARB review) sessions
• Who needs the roadmaps? Business Architects, Project Architects and Vendor
Architects
• Accountable: Technology Platform Architect (consulted by Vendor Architects)
Technology Architecture Roadmaps
• The Technology Architecture (a.k.a infrastructure / platform) roadmaps will document
the as-is and target IT architecture for the specified and agreed technical domains
• IT Architecture roadmaps will be created and maintained during vendor technical
reviews
• IT Roadmaps will also be created for major COTS product investments (e.g ERP
upgrade roadmap)
• The roadmaps will provide a visual timeline covering a specified period (e.g 3-5 years)
showing the evolution of the technologies in their respective domains

10. 10
IT Architecture Roadmaps (Examples)

11. 11
Architecture Roadmaps: Process Alignment
Process Alignment Proposed Architecture
Governance
• Transformational programs
• Value Realization
• Portfolio Investment decisioning
• Business Process Modeling (BPM)
Baseline roadmap major program
Review
• Business Case definition - Ensure
business case is aligned with technology
roadmaps
• Major Vendor releases (e.g ERP rollout)
ARB reviews: Update Roadmap/s if
there for project/program exceptions
• Define/update roadmaps during Solution
Design process
Review and baseline roadmap
during ARB reviews
• Vendor engagement process for major
technical upgrades (e.g TOP program)
• Engage with Design Authority for
platform upgrades
Review and baseline roadmap
during ARB reviews
Application Roadmaps
Business Architecture
Roadmaps
Landscape and
Portfolio Roadmaps
Technology
Roadmaps

12. 12
Roadmap Structure and Table of Content (TOC)
1. Info. – Rivision Control
2. Principles
3. Assumptions
4. Requirements
5. Building Blocks
6. AS-IS and/or TO-BE
7. Roadmap Timeline
8. Risk and Mitigation
Building blocks (Architecture
Summary, Background)
Short / mid term timeline in
Gantt Chart and
Long term (> 3 years) in a T-Map
Define domain guiding principles
Highlight key assumptions and
requirements