■■■ Überraschend mehr Möglichkeiten

Managing IT Transformation with Enterprise Architecture

Developing the roadmap of a digital transformation leveraging a lightweight EAM

Whitepaper © OPITZ CONSULTING Deutschland GmbH

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

Authors Contact

Markus Grünewald, OPITZ CONSULTING Markus Grünewald

Rolf Scheuch, OPITZ CONSULTING Solution Architect
Pedro Sousa, Link Consulting [email protected]
+49 (0) 0173/7279409

Table of Contents

Preface

1. Introduction

2. Management Summary

3. EAM Approach and Scope

4. Tailoring TOGAF

5. Core Deliverables

6. Organization and Issues

7. References

8. Extended Deliverables

9. Design4Change Architectural Vision

10. Enterprise Architecture Management System

11. Conclusion

About OPITZ CONSULTING

About Link Consulting

Text and figures has been designed carefully. OPITZ CONSULTING is not
juristic responsible nor assume liability for possible errors in content
and consequences occurred. OPITZ CONSULTING only has the right to
show the mentioned processes, showcases, examples of implementati-
on and source code.

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 2

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

Preface In our case, we will focus on the strategic aspect of transfor-

ming the application landscape to meet the requirements of
Almost every company of today’s world struggles with a multi- the target-operating model. The approach is top-down and will
tude of external influences, which have a profound impact on rely on the evaluation of the business capabilities and deducts
the company’s business. E. g. globalization, start-ups with new architectural requirements of the landscape application. To
business models and digitalization are only a few, which force achieve this, our approach needs a common
companies to adjust or even reinvent their own business. architectural vision for the target application landscape.
What are the first steps? How can you achieve a profound
transformation? We will rely our approach on the following standards:

This white paper contains valuable information how to handle ■ Prince2 for Program Management
these questions. Using an Enterprise Architecture Manage- (https://www.prince2.com/uk)
ment, as outlined in this paper, a company will be able to ■ TOGAF9 for an EA framework
(http://www.opengroup.org/subjectareas/enterprise/togaf)
■ identify those areas which must be transformed first to
achieve a competitive advantage This white paper will start with a management summary,
■ identify routine work which can be automated to increase a short overview of the approach. Further on we will describe
efficiency and reduce costs the approach and the methodology in details and follow up
■ facilitate make or buy decisions with a description of the deliverables of the EA related tasks.
■ build a sustainable IT architecture In addition, we have added an architectural vision of an
application landscape supporting a digital business models
If you have any questions, please do not hesitate to contact us and references as well as a description of our “favorite”
in this case. We would be pleased to discuss these important EA tooling.
topics with you and find specific solutions for your company.

With kind regards 2. Management Summary

Markus Grünewald Principal Enterprise Architect, OPITZ CONSULTING supports companies in the endeavor to
OPITZ CONSULTING support the current and future business strategy including a
Rolf Scheuch Chief Strategy Officer, digital strategy. The approach to transform the often distribu-
OPITZ CONSULTING ted silos landscape into an agile IT landscape as follow:
Pedro Sousa Enterprise Architecture Leader,
Link Consulting 2.1 Clarify the business and operating model(s)

In conjunction with the top management we will first clarify

1. Introduction which business and operating model(s) should be executed in
the future and which strategic objectives must be taken into
This white paper was created based on a cooperation of OPITZ account. After we have identified the core capabilities together,
CONSULITNG and its partner LINK CONSULTING. The paper we will build a core diagram of the company to secure the
will propose a lightweight Enterprise Architecture (EA) same understanding of the overall business, core capabilities-
approach to design, plan and govern a business transformati- data and customer outcome.
on relying heavily on IT or digitalization.
2.2 Identify and assess business capabilities
Different client objectives will imply different flavors of the EA
implementation to reach these goals and support the transfor- Concentrating on the business capabilities needed to
mation. Governing a transformation of infrastructure, maybe perform the business and operating models, we will first identi-
to a hybrid infrastructure, harmonizing business processes for fy and assess all capabilities. Afterwards we will depict the
an efficient operating model or consolidating the existing ap- result in a business capability model and a capability
plication landscape are typical objectives, where EA helps to heat map.
design, plan and govern the change.

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 3

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

The assessment will help us to select those

capabilities that have a high business impact but are
currently underdeveloped.

With a capability model and a capability heat map in place, you

will be able to answer the following questions

■ Which are our strongest and weakest capabilities?

■ Which capabilities provide strategic differentiation?
■ Which capabilities can be leveraged in new markets?
■ Where should we invest our resources?
■ Where can technology add more strategic value?
■ Where can technology be used to lower cost?

2.3 Iteratively build the transformation roadmap

Equipped with this solid foundation and the answers of the Figure 1: Competencies and continuous improvement
questions above we can concentrate to align the capabilities [Adapted from Business Process Change, Paul Harman]
to business processes to build a first blueprint of the future
application and infrastructure landscape. To transform the
current state to this future state we will iteratively build the 3. EAM Approach and Scope
necessary roadmap.

With this transformation roadmap in place, we are now able to 3.1 Preamble
answer the following questions:
It is crucial, in order to be successful with an Enterprise
■ What will be the organization’s systems and technology Architecture Management initiative to adhere to some princip-
evolution over time and how does it affect the organization les. EAM is not only another tool – it is paradigm shift – if it
capabilities? was not used in your company before. Thus it involves the
■ What are the impacts/dependencies between the different alignment of business capabilities and processes with the
transformation initiatives in the transformation roadmap? company strategy and will also have an impact on the orga-
nizational structure the support of the top management is
The overall goal is to build a strong foundation for execution mandatory. EAM is an ongoing task for each company. There-
and an environment for continuous improvement. Figure 1 fore, it is necessary to make an organizational change within
shows how the capabilities are classified and how the the company and introduce a fully dedicated EA team. OPITZ
company capabilities can change over time from CONSULTING will facilitate and coach the EA team. In this way
differentiating capabilities over competitive to commodity or the team will be able to
non-core capabilities.
■ perform and constantly improve the company specific
If the non-core and commodity capabilities are automated Enterprise Architecture Management approach
(in-house or outsourced) then your company can concentrate ■ govern the Enterprise Architecture
on the capabilities with a high business impact to gain a ■ support the organization during transformation
competitive advantage.
Based on our earlier description, how a distributed silo lands-
cape can be transformed in an IT landscape supporting the
business strategy, our next section will explain the necessary
course of action in detail.

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 4

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

3.2 Clarify the business and operating model 3.3 Identify and assess business capabilities

In order to determine how to build the future foundation for After a common high-level view of your company‘s business is
execution it is necessary to specify the current and future established we will start to drill-down on the details. In order
operating model. To achieve this, we will collect the current to select the right transformation strategy and to be able to
and future business model as well as the related core build a corresponding roadmap it is essential to be aware of
capabilities in discussions. all business capabilities and to assess them accordingly.

The capabilities will be categorized using the specific charac- 3.3.1 Create the capability model
teristics of the different operating models (figure 2). The evalu-
ation of this categorization will help to determine which model In the capability model, we will outline all business capabilities.
best describes the current and future operating model. The capabilities will be grouped in specific business areas. To
facilitate this task we recommend using an industry specific
reference model, for instance the Business View of MIRA
(Microsoft Industry Reference Architecture) (see Figure 3) and
then discussing and customizing the model. An industry refe-
rence model is a good starting point for discussion and will
help to consider additional potential capabilities.

Figure 2: Operating model

The above example of figure 2 is based on the assumption the

current operating model is a replication operating model. The
objective in this example is the transformation process to dri-
ve proactively standardization and centralization across the
network to deliver cost savings by reducing redundant capabi-
lities and functions and by increasing the velocity of business
solution implementations. In this example, the current opera-
ting model will be transformed from a replication to unificati-
on model (as depicted in figure 2).

With the operating model identified, we can start to build the

core diagrams (current and future) to communicate the
high-level business processes and IT requirements of the
operating model. The core diagram helps us to verify that all
involved stakeholders have the same common
high-level understanding, on how the current and future
business will look like. Figure 3: Capability model

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 5

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

3.3.2 Create a capability heat map A key requirement while building the roadmap is the
necessity of the organizational readiness of the your company
After the capability model was created in the former step, to deliver the roadmap. If the readiness assessment reveals
each capability will now be assessed using different properties areas for improvement we will outline which adjustments will
(e. g. business impact, maturity, potential...). This assessment be necessary to enable your company to execute this
determines on which capabilities the company has to roadmap and to operate the target state.
concentrate first.
In order to execute the transformation from the current state
Capabilities, which have a high business impact and a low ma- to the future state, an iterative process on a very detailed level
turity level, should be implemented and optimized as soon as is required. In Figure 6, we have depicted how this
possible. Capabilities with a low business impact are candi- iterative approach has to look like.
dates for outsourcing or can be supported using standard
software application (on Premise or Cloud).

Figure 4: Capability heat map

3.4 Iteratively build the transformation roadmap Figure 6: Iterative approach to transform from current to
future state
In order to build a high-level transformation roadmap
(see figure 5) we have to inspect each capability assessed in So far, we have outlined the approach without any direct rela-
the heat map. For each capability we have to tionship to an enterprise architecture framework. The next
section will describe how a tailored TOGAF framework will be
■ align the capability with the company strategy/ used to produce the necessary artefacts.
operational goals,
■ align the capability with business processes
(high-level => value chain), 4. Tailoring TOGAF
■ execute a gap analysis,
■ decide if the capability can be outsourced, supported by To establish and implement a lightweight EAM we will tailor
off-the-shelf product or should be developed in-house. the heavyweight TOGAF9 framework (see
http://pubs.opengroup.org/architecture/togaf9-doc/arch/) to
your specific needs. How this tailoring can look like to
consider the basic aspects of TOGAF will be outlined in this
section. As described in figure 7, the TOGAF framework is built
on roughly nine segments of work with a common process for
requirements management of architectural change.

We advise our clients not to implement a complex Enterprise

Architecture Management (EAM) on a superior maturity level,
Figure 5: Iterative approach to transform from current to but start with a lightweight EA approach and develop their
future state EAM as needed in later stages of the transformation.

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 6

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

In the following, we will describe the EA methodology for each

area of work specified above.

I. Architectural Principle and Target

Area of work
Business Operating Model

Objective Establish an architectural vision and a common under-

standing of the target business model and operating model
Tasks ■ Identify stakeholders & detail planning
■ Confirm and elaborate business goals
■ Establish and document the high-level target
business model
■ Access readiness for the transformation
■ Establish an architectural vision and document
principles
Figure 7: Tailoring TOGAF 4, a basic EA framework Input Workshops with senior management
■ Workshops with senior IT-management

This lightweight approach has two immediate implications: Output ■ Documented architecture vision & principles
■ Documented target business model and operating
model
■ We advise to use EAM from Link Consulting ■ High-Level baseline (Business capabilities, applications,
technology)
(http://www.linkconsulting.com/eams/) as a cloud-based ■ High-Level target (Business capabilities, applications,
SaaS. With EAMS the information documented in Microsoft technology)
TOGAF ■ Preliminary
office tools as a simple repository can be shown in a clear
■ A. Architecture Vision
and concise way (see chapter 5). ■ B. Business Architecture (high-level)
■ We advise to tailor TOGAF to the actual project context.
Remarks ■ A Possible reference architecture for the application
Doing so, we have developed the unique EAM, as shown in landscape could be the Context Aware Frontend
figure 7, based on the TOGAF framework. This allows for a Architecture (CAFA) described in section 9.
■ Starting point for the capability map can be the
later ramp up on models and EA process should this business view of an industry specific Microsoft Industry
deem necessary. Reference Architecture (MIRA) or another reference
model

We need an architecture vision of core robust, business- Table 1: I. Architectural Principle/Target Business Operating Model
needs-driven technology architecture. This will be ensured by
implementing „I. Architectural Principle and a target Business Area of work II. Initiatives
Operating Model“. Both the target model and the target Objective ■ Generate a comprehensive, but initial version, of the
architecture will undergo a constant review, but from the transformation roadmap including all necessary high-level
initiatives of the transformation program to reach the de-
beginning of the EAM project, we need a clear understanding sired target
of the target business and operating model as well as ■ Determine and elaborate an iterative, incremental
approach of the transition
establish an architecture vision.
Tasks ■ Perform gap analysis and define candidates for
initiatives
Based on the „III. Baseline“ and the „IV. Target“ we will perform ■ Create an architecture roadmap and transformation
roadmap (program plan)
an initial gap analysis and define, together with your com- ■ Perform risk/benefits management on the roadmap
pany‘s EA team, the necessary II. Initiatives (or well-defined ■ Document and communicate measuresfor an
organizational change management
projects). These initiatives that will be the subject of the
Input ■ Gap analysis and candidates (initiatives) for roadmap
„V. Roadmap“ of the transformation program and thus the ■ Architectural vision
needed business capabilities will correspond with the ■ Business capability heat map
initiatives of the transformation roadmap. Output ■ Gap analysis and initiatives
■ Updated architecture vision
Each initiative we discover will describe the necessary ■ Roadmap as a transformation plan
■ High-level defined initiatives for work
arrangements to execute the initiative within the roadmap
■ Risk/benefits management
execution. Execution of measures to enable the operational ■ Change management incl. stakeholder management
change is subject of a change management process. TOGAF E. Opportunities and Solutions
Remarks ■ Since the clients must govern the roadmap, the EA team is
A lightweight „VI. Architectural Change Management“ heavily involved and must perform stakeholder manage-
ment as well the risk/benefits management within the
established and performed by the client to govern the road- organization.
map and thus the transformation program. This will align with ■ The roadmap is basically a plan for the transformation
plan and we will use the reference framework of PRINCE2
the goal to establish a lightweight approach to or PMI for program management
Enterprise Architecture Management.
Table 2: II. Initiatives

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 7

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

Area of work III. Baseline Area of work VI. Architectural Change Management

Objective Develop a clear understanding of the actual status and have Objective Ensure conformance with the target architecture and
a baseline for transformation vision and perform EA-Governance for change request
Tasks Document the baseline business architecture, information Tasks Define an EA-Governance organization and processes
system architecture and underlying technology architecture (lightweight!!) and implement the EA-Governance
Input ■ Workshops Input Change requests
■ Refer to I. Architectural Principle and Target
Business Operating Model
Output Compliance assessments and possible changes to
■ Existing documentation of value chains and roadmap or architecture
IT systems

Output Documented Baseline of TOGAF G. Implementation Governance,

■ Business capabilities ( Heat Map) H. Architecture Change Management
■ High-Level Value chains Remarks WARNING: Often the program management is responsi-
■ Applications ble for the transformation and the EA-Governance built
■ IT-infrastructure and possible constraints around the EA team in the same organization. We advise
to split this into an own organization for the transfor-
TOGAF Baseline in mation program and a “stand-alone” EA-Governance for
B. Business Architecture, architectural change
C. Information System Architecture,
D. Technology Architecture Table 6: VI. Architectural Change Management

Table 3: III. Baseline Remark: Please refer to the references in chapter 7 since this
procedure was successfully implemented in existing EA pro-
Area of work IV. Target jects.
Objective Develop a clear understanding of the target architecture and
the area of work (= candidates, initiatives) for transformation

Tasks Document the target business architecture, information

system architecture and underlying technology
5. Core Deliverables
architecture

Input ■ Workshops Each initiative, we discover, will describe the necessary

■ Refer to I. Architectural Principle and a target Business arrangements to execute the initiative within the roadmap
Operating Model
■ Refer to III. Baseline execution.
■ Workshops with subject matter experts (SMEs) and
Senior Management
Output Documented target architecture of With reference to figure 5 which illustrates the central steps of
■ Business capabilities (Heat Map)
■ High-Level Value chains our approach, we introduce key maps to be used as a first
■ Applications infrastructure step of a project, from the capability map (1), the capability
TOGAF Target in heat map (2), the capability context map (3), to the project
B. Business Architecture
C. Information System Architecture
context map (4) the project portfolio roadmap (5) and finally
D. Technology Architecture the capability realization map (6).

Table 4: IV. Target

Area of work V. Roadmap

Objective ■ Finalize the roadmap incl. a high-level implementation

and migration plan
■ Ensure the transformation roadmap is understood and
approved by relevant stakeholders
Tasks ■ Make a high-level project plan for each initiative
(project charter)
■ Prioritize the initiatives based on estimation concerning
business value, time line, budget and complexity
■ Discuss, finalize and approve roadmap
Input ■ Refer to II. Initiatives
■ Workshops with senior management and IT-leaders

Output ■ High-level roadmap as program plan (PRINCE2)

■ Implementation & migration strategy
■ Portfolio breakdown
■ Finalize architecture vision and transition architecture
(if necessary) Figure 8: Overview of project deliverables
■ Implement EA-Governance for the transformation
lifecycle

TOGAF E. Opportunities
F. Migration Planning

Table 5: V. Roadmap

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 8

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

With the EAM tool of Link Consulting (EAMS), all maps are ge-
nerated automatically based on information in the repository,
either loaded from common formats, e.g. Excel, or introduced
directly. All maps have a time bar that shows how the content
of the map will evolve along the time. Capability Realization
Map (6) shows the realization completeness of each
capability at any time, according to projects scheduled in the
map (5). Any changes in scheduled dates of the project
will be propagated to the other maps.

Additional maps regarding TOGAF architecture representati-

ons of processes, information, applications and technology
can be delivered in cases where more detailed information
are available. Some of these maps are presented in chapter 8
„Extended Deliverables“.

Remark: All maps shown next are only examples from a retail-
banking domain, and should be tailored to final maps
according to the specific needs of your company. Figure 10: Capability Heat Map (2)

The following figure shows an example of the Capability Map To sustain the analysis of each capability, the following figure
generated according to the mapping of business capabilities shows the key dependencies in the so-called Context Map.
to specific business areas. Simple configurations used to The figure contains examples of the operational goals related
adjust the final look and feel of the generated map. to the selected capability, the macro processes supporting it
and the core resources implied in each macro process. The
map can be generated according to the dependencies existing
in the repository.

Figure 9: Capability Map (1)

The overall business relevance of each capability is presented

in a color scale on the Capability Heat Map (2), presented next,
identifying most relevant capabilities (in red). Figure 11: Capability Context Map (3)

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 9

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

Whenever information that is more detailed is available,

a more detailed map can be generated, including applications
and technologies, as presented in the next figure.

Figure 14: Project Portfolio Roadmap (5)

Based on scheduled dates of the project portfolio and the

architectural elements that each project promises to bring
into production and to decommission, one can compute the
impact of each project and, more important, the combined
effect of all projects in the portfolio.

For example, a capacity that depends on applications or

technologies resulting from different projects will only be
fulfilled after the successful completion of all those projects.

The next figure shows the capability realization at two

different times (01/07/2017 and 01/01/2018), as indicated by
the time bar below. Green Capabilities are defined as available
Figure 12: Capability Context – Detailed Map (3) capabilities, or more precisely, means that all necessary
resources to sustain that capability are in production. Yellow
As the result of the analysis of previous dependencies and capabilities show that at least some of the necessary res-
gaps, a list of projects “to make” or “to buy” are proposed. The sources are still being brought into production by on-going
Project Context Map below summarizes the information projects. Red capabilities are that at least one necessary
regarding the selected project. resource is neither productive nor in the delivery list of
on-going projects.

Figure 15: Capability Realization Map (6)

Drilling down in the Capability Realization Map into one of the

Figure 13: Project Context Map (4) red capabilities, one can see the missing
resources.
The overall Project Portfolio Roadmap is depicted in a
Gantt Dashboard on the right above.

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 10

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

The project team will grow and decline with the need of the
expertise of the SMEs. As topics might need a more detailed
view from the client’s side, the project lead may increase the
number of SMEs at any given time. As outlined in chapter 2,
the intention is to enable the EA team to do more and more
all necessary tasks on their own by training them on the job.
This includes an early productive participation of the
members of the clients EA team.

Remark: We strongly advise that at least one EA team

member should have an IT background as a senior architect
and at least one member should be an experienced business
architect.

Based on our experiences, the following potential risks in EAM

projects often occur:

Risk Impact Counteraction/Mitigation

Lack of support from Project failure Senior management of client

senior management must support the engage-
ment.
Time allocated from stake- Delay in Project Management (PM)
holders for EA project time line discuss more efficient ways
Figure 16: Capability Context – Detailed Map (3) with realization insufficient to gain result

filter, according to project portfolio scheduling Stakeholders do not invest Delay in PM must insist on invest of
allocated time in project time line stakeholders

Contribution of the EA Delay in Verify skills of EA team mem-

6. Organization and Issues team is not as high as
expected
time line bers, PM: Verify
training
Enterprise Architecture Impediment Strong support by top man-
We advise a lightweight governance structure with a minimal and IT results are not well of change agement and key stakehold-
accepted throughout the process ers. Communication / evan-
sized steering committee. The steering committee may invite company gelism.
subject matter experts (SME) or other stakeholder to a Preserver of the current Impediment Strong support by top man-
state influence others in a of change agement and key stakehold-
meeting, but the enlargement only planned on invitation negative way process ers. Communication / evan-
gelism.
only. The steering committee will meet once at the beginning,
once approx. 3 weeks’ prior the end of the project and other- “Ivory Tower” Enterprise Impediment Establish an Architecture
Architecture of change Board, with the right key
wise only by appointment. Figure 17 describes a possible org- process stakeholders, to govern the
implementation of EA
chart of the project organization for an initial EA project:
The lack of effective gov- Delay in Consider Governance from
ernance from the start time line the beginning.

Table 7: Risks

7. References

In this section, we will present three related EA projects

focusing on coaching engagement to accompany a 3-5 year IT
transformation program. All references start with a
strategy phase using a customized TOGAF methodology
followed by a long term coaching engagement to review and
govern the transformation.

Figure 17: Project Organization In this listing, we focused on long term engagements
showing the value crated by starting with a strategy phase
based on a customized Enterprise Architecture methodology
and then followed a long-term roadmap.

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 11

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

Network International
AMA
Maintenance Travel insurance medical Petrobras German Credit
Company (Public
Company (Oil) Bureau Company
(Tele- (Insurance) technology Administration)
communication) (Industry)
Reference Yes Yes Possible
Reference Yes Yes Possible (Eugénio Ped- (André Vascon- (Please have
rosa) celos) Link Consulting
Duration Strategy Strategy Strategy make contact)
(PD) ■ 6 months ■ 4 Months ■ 6 Months
Duration (PD) Strategy Strategy Strategy
■ 60 PD ■ 80 PD ■ 40 PD
■ 6 months ■ 6 Months ■ 3 Months
Transformation Transformation Transformation ■ 60 PD ■ 80 PD ■ 20 PD
■ 4-6 years (has ■ 3-5 years ■ not yet Transformation Transformation Transformation
ended) (ongoing) started
■ 3 years ■ 3-5 years ■ On going
■ 60 PD ■ 40 PD (ongoing)
■ 30 PD ■ 75 PD
Year 2010 2012 2015 ■ 180 PD
started
Year 2011 2012 2015
Objective Modernize appli- Harmonize local Modernize appli- started
cation architec- systems to gain cation architec-
ture to gain flexi- process ture to support Objective Reduce redun- Reduce IT redun- Establish an
bility and lower efficiency the digital trans- dancy/costs dancy (dupli- Enterprise Archi-
maintenance formation from the busi- cated applica- tecture practice,
costs ness demand tions) and waste from strategic,
up systems (ex free pro- requirements to
Goal Implement a SOA Implement a Implement a delivery result- cessing capabil- DevOps and tick-
based application SOA based flexible applica- ing from having ity) between over eting tools, ensur-
landscape application tion landscape several tens of 650 public or- ing a better IT
landscape for based on COTS industrial sites ganizations of planning and
BPM (oil extraction & the 10 Portu- management.
refineries) in guese
Method EAM with focus on EAM with focus EAM with focus an different lines ministries
application archi- on Business application archi- of business (bio
tecture Capabilities and tecture -gas, oil, petrol,
■ SOA BPM ■ Value chain ...)
business ■ Business analysis
services capability ■ SOA business
■ Roadmap for maps services Goal Implement a Implement and EA Roadmap to
application ■ Value chain ■ Roadmap for multi-site EA deploy a Feder- support the IT
transfor- analysis application
mation transfor- practice to ated Enterprise Strategic goals
■ SOA ■ SOA mation support IT Architecture properly, the IT
business
governance services government to capability be- Solution Develop-
■ Roadmap for ensure provid- tween the ment Process
application ed a common ministries, being (from demand
transfor- language be- AMA the top management to
mation
tween Business central site. DevOps) and the
Sourcing Make (80%) and Make (50%) and Make (20%) and and IT and thus IT tooling ecosys-
buy (20%) buy (50%) buy (80%) a better align- tem. Replace
ment between Mega tool with
Role Facilitating and EA consulting Facilitating and business and IT EAMS tool.
OPITZ CON- coaching and coaching coaching initiatives.
SULTING
Method EAM with focus EAM with focus EAM with focus on
on process, on application SOA, applications,
Table 8: Value created by long term engagement with information, and infrastruc- and infrastructure
application ture architecture architecture
OPITZ CONSULTING architecture
and project ■ Application ■ Define EA meta-
portfolio. catalogue and model
dependencies ■ Define norma-
Remark: We believe that Enterprise Architecture is a discipline ■ Architec- tive architec-
ture of ■ Integrate
and management process to perform by the client. OPITZ each site architecture ture that in-
roadmap cludes coher-
CONSULTING sees its role as consultant for methodology, ( Process,
scenarios with ence rules and
Infor- model nota-
facilitator and coach. The client must lay emphasis on change mation and services, SW
tions
Applica- and HW ac-
management to engage all stakeholders on the quisition (Archimate,
tions) BPMN, UML)
public
transformation journey and OPITZ CONSULTING can only ■ Site gap process. mapping into
regarding repository
help. reference
■ Optimizations concepts
analysis intra
architecture and inter ■ Migrate data
(per line of organization from Mega
business)
■ Site transfor-
mation
roadmap
Tooling EAMS from Link EAMS from Link EAMS from Link
Consulting Consulting Consulting

Role EA consulting EA consulting EA consulting and

Link and deploy and deploy deploy
Consulting

Table 9: Value created by long term engagement

with Link Consulting

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 12

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

8. Extended Deliverables Drilling down on an initiative/project (e.g. CRM System

Consolidation), one gets the project context.
In addition to the information, provided in chapter 3 „Core
Deliverables“, we will show now some samples, which
demonstrate the power of EAMS.

8.1 High-level samples: goals and initiatives/projects

Figure 20: Initiative/Project Context

Figure 18: Simple Goals Dashboard showing From here, one can navigate to all domains.
initiative overall progress

After selecting a goal, one can see the contributing initiatives.

Drilling down, one gets a more detailed view (C-2).

Figure 21: High-Level Transformation Initiatives Roadmap

8.2 Detailed-level samples: applications and technology

Figure 19: Initiatives/projects to achieve the goal

Figure 22: Application Context

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 13

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

By selecting an application (“Account Management In the example depicted in figure 24, components are
Application“ in these examples), EAMS generates a high-level classified according to a given layer (Presentation, Business,
view of business context of this application. It shows the Data and Integration).
dependencies that Account Management Application (in the
center) has with selected classes.

By clicking on the Account Management Application symbol,

EAMS generates a layered view of Account Management
Application, where dependencies are traced upwards up to
the business Actors, and downwards down to the
infrastructure.

Figure 24: Application Structure

Another example is the integration blueprint, below, where

one can see the integrations between Account Management
Application and producing and consuming applications,
including the services and data involved.

Figure 25: Application Integration

The blueprints presented above are just examples, since

users can configure a wide range of different blueprints. The
navigation between the blueprints is also configurable per
profile.

Next, an example of a TRM (Tencical Reference Map) from

Figure 23: Application Layered TOGAF, and its evolution according to a list of projects loaded.
In this case, colors in the application indicate before
In this example, arrows indicate the relationships between migration, in migration and after migration.
objects in the repository.

By clicking on the Account Management Application box,

EAMS generates the structure view blueprint for this account
management application, where one can see the actual
components and required platforms.

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 14

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

Figure 26: Technical Reference Model

Figure 28: Infrastructure impact analysis, from selected

technology (below green element) up to business processes and
business roles (yellow top elements), on a given date
(not shown)

9. Design4Change Architectural Vision

Figure 27: Service Performance Dashboard Although the proposed methodology has a clear focus on a
top-down and business capabilities oriented approach for the
Architecture Management, it is necessary to align the business
capabilities with a clear architectural vision of the future appli-
cation architecture. This deems necessary, since developing
the roadmap with possible alternatives for
different commercial-of-the-shelf components (COTS) and a
subsequent “make and/or buy” discussion, the client needs
architectural principles to support the decision-making.

Nevertheless, in the fast moving markets each client is addres-

sing his own difficult and disparate market-segment deeming
an Omni-channel approach to interact with customers and
new possibilities of digitalization as a necessity. Shifts in com-
munication technology and interaction channels in the seg-
ment will be permanent, thus addressing for
application architecture as “designed for change”.

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 15

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

This leads to the need of flexible application architecture with Starting point was the blueprint of a four tier architecture by
a decoupling of front-end omni-channel interaction Forrester with an emphasis on a specific delivery tier for mobi-
applications (or Apps) from a robust and compliant central le services. As this was only sufficient to address security and
back-end platform: scalability, we enhanced the delivery tier with aspects of de-
coupling of the front-end application from the back-end
■ a single common platform systems, the usage of microservices architectures, the
■ a multi-tenanted platform, which will heavily influence the possibility to follow a “Make and Buy” application strategy,
choice of component parts integrate legacy systems and have context-aware application
■ a platform for back- and front-ends with the need to be (here Netflix was the blueprint for omni-channel interaction).
decoupled
■ a back-end to provide the reliability and stability
■ a front-end to be flexible and quickly adaptable to
changing user and customer needs
■ to utilize commercial-off-the-shelf components (COTS) and
business service
■ integration
■ to rely on their own development capacities only where
they create a competitive advantage

Considering these requirements, OPITZ CONSULTING will

introduce the reference architecture of a “Context Aware
Frontend Architecture” (CAFA), as laid out in figure 29, as a
blueprint for flexible application architectures. The CAFA blue- Figure 29: Context aware front-end architecture (CAFA)
print is used by OPITZ CONSULITNG as a pattern for
application transformation with digitalization and will help 9.1.1 Front-end diversification and CX
your company to customize and build a client specific
reference architecture as the top-down business capabilities As stated, the CX will be a key differentiator for your company.
are defined and evaluated in a “Business Capability Heat Map”. The CAFA is able to support different programming
techniques and frameworks.
As stated, each business capability must be analyzed and
evaluated as to have a clear picture of the possible solutions The key is the usage of reliable back-end services of the
(as COTS) to be taken into account. Service Tier, but with a CX-centric designed approach for the
front-ends. During the EA consulting, the business capabilities
As to address the need for change by decoupling front-end must be analyzed in regard to the needed user experience
and back-end, the business capability tagged according to the and the possible devices used to interact. Context awareness
possible customer interaction scenarios. In the case of an will help switching the devices without losing the “transaction
omni-channel interaction with customers, even as a self- context”.
service app, the front-end must decouple from the back-end
as to ensure innovation, implementation of cultural As CAFA was designed for incorporating the Internet of Things,
differences and a rigid customer experience (CX) approach. front-end apps can span out and addresses the business logic
From OPITZ CONSULTING perspective, this can be the key of desperate applications systems, thus building new infor-
differentiator in your specific market segment. mation and interaction models based on existing
business services.
9.1 Context aware front-end architecture (CAFA)
Decoupling of front-end and back-end will a bimodal-IT
OPITZ CONSULTING has developed the CAFA blueprint in approach with robust, slow changing back-ends and fast
different client projects as to have an architectural vision and moving, CX-centric front-ends.
application architecture to address the needs of a digital
transformation and a “Designed for change” approach.

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 16

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

9.1.2 Use as a platform To the point:

The CAFA blueprint considers the possibility, that third ■ COTS with interaction by back-office staff, may have its
parties may use the architecture and the business services as own front-end
a platform for their services. This opens the possibility for the ■ COTS with services invoked by end user should have a
client to engage third party products to leverage the business service façade
investment in the new platform or add value for the client by ■ SaaS solutions are specific COTS
offering innovative third party solution. ■ Own staff should focus development on a best-in-class CX
with unique, custom-build front-ends
9.1.3 Use as an evolutionary platform ■ Front-end technology need not be contained to specific
vendor offerings, but will focus on the best CX
Within certain non-functional requirements, the CAFA blue- ■ CAFA does not imply any restrictions on the infrastructure
print will allow a “Make and Buy” strategy as well as evolving and is open for cloud models as IaaS, PaaS or even SaaS
the architecture during the transformation. This feature of
CAFA is necessary, since existing application platforms must
evolve during time. 10. EAM System

Our partner Link Consulting has developed a system to

visualize EA information in a smart way. The information can
be read from different source systems even from Excel
Spread Sheets. This will enable the EA team to follow the
proposed light-way approach to collect and document neces-
sary information in Excel sheets and then visualize them with
EAMS. Sample visualization formats outlined in appendix C.
One of the key feature of EAMS is that you cannot just have a
look at an AS-IS or TO-BE state of your architecture, but you
can have a live view on all aspects using the time perspective.
For further information, please visit the following website:
http://www.linkconsulting.com/eams/
Figure 30: Make and Buy decisions within the Context Aware
Frontend Architecture (CAFA) The EAMS system can be licensed as an on premise or a SAAS
solution. If your company does not want to acquire EAMS we
As the figure 30 with the #1 implies, that the client will be able will deliver the resulting diagrams (see section 3) at the end of
to buy COTS applications or user legacy-systems a self- the engagement to document the AS-IS and the to-be
contained application coupled by an integration layer in the state. However, we strongly recommend the usage of EAMS to
service tier. Since these self-contained applications do not facilitate the daily work in the EA context.
furnish an API for the front-end usage, they are not incorpo-
rated in the heart of CAFA and be subject of replacement over 10.1 Demo system
time. The #2 and #3 describe the preferred approach for
COTS. The COTS may or may not have its own front-end, In order to get familiar with EAMS, Link Consulting
mostly used by the clients staff, but will deliver business ser- will provide soon a demo system on
vices as objects of the service tier and to use by the front-end http://www.linkconsulting.com/eams/. Please check regularly
applications. for the demo system.

A further advantage is the build-in pattern for the use of SaaS

solutions. Again, the SaaS solution with an API is the better
approach, as the functionality and CX may be addressed by
the clients making the solution unique.

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 17

 WHITE PAPER
„MANAGING IT TRANSFORMATION WITH EA“

11. Conclusion About OPITZ CONSULTING

Meanwhile it is widely accepted that IT is no longer only an OPITZ CONSULTING is a leading German specialist for
instrument to support the operational work of a company but custom-build applications and digital transformation. We
IT is a core capability for most companies. Nevertheless, many focus on an End2End Application Lifecycle Management for
companies struggle to use their IT budget and resources your BPM, SOA, Java and Big Data solutions.
effectively. The limited budget and resources are very often
used to operate and maintain highly customized applications Since 1990 over 600 customers have a long lasting and
and heterogeneous IT landscapes as to secure the business successful business relationship with us. Over 2/3 of the Ger-
continuity. man stock index (DAX) companies rely on services from the
400+ OPITZ CONSULTING consultants. In 2008 our company
Thus, the IT is often not aligned with the company’s strategy has established a near-shoring capability in Poland.
and is not focusing on supporting the right business capabili-
ties. Typically, the IT is more solution and project orientated OPITZ CONSULTING is a Platinum Partner of Oracle and
and as a result focuses on such solutions which at low cost our emphasis is on the digitalization of business models using
also only provide a low business impact. Many companies are the converging technologies from Oracle for Big Data,
missing the opportunity to use IT as an enabler for competiti- Internet of Things, Cloud Services and Engineered Systems.
ve advantages.
Further Information: http://www.opitz-consulting.com
In using the holistic, business capability centered approach
outlined in this paper your company can build a solid founda-
tion for operation addressing the right initiatives to bring value About Link CONSULTING
to the company. The application landscape and roadmap will
help the IT of your company to react faster on market changes Link’s key mission is to generate value to its customers
and to use the budget and resources effectively. offering technology innovation in the areas of information and
communication technologies.
Further on, the presented approach is a starting point for a
lightweight Enterprise Architecture Management to govern the Internationally Link Consulting is present in Brazil, Spain and
IT-architecture and the change always aligning the technical Angola with own offices and develop different activities in
capabilities with the necessary business capabilities. countries such as Belgium, Brazil, Cape Verde, Canada,
England, France, Ireland, Israel, Luxembourg, Morocco, Mo-
OPITZ CONSULTING and LINK CONSULTING have developed zambique, Malta, Portugal, Spain, S. Tomé and Principe and
this lightweight Enterprise Architecture Management ap- Switzerland.
proach to address the needs of flexibility, digitalization and
cost efficiency in building and maintaining IT-architectures. Some of Link’s main customers are most of the national large
Don’t hesitate to contact us, so we ca discuss the value of the companies, mainly in Telecommunications, Bank and
presented approach with you and your organization. Insurance, Logistics and Distribution, Passengers Transportati-
on, as well as important entities in the Central Government
Administration and Municipalities.

Further Information: http://www.linkconsulting.com

© OPITZ CONSULTING DEUTSCHLAND GMBH 2016