Upload
donga
View
226
Download
0
Embed Size (px)
Citation preview
Managing IT Transformation with Enterprise Architecture
Developing the roadmap of a digital transformation leveraging a lightweight EAM
Whitepaper
■■■ Überraschend mehr Möglichkeiten
© OPITZ CONSULTING Deutschland GmbH
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 2
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.
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
Authors
Markus Grünewald, OPITZ CONSULTING
Rolf Scheuch, OPITZ CONSULTING
Pedro Sousa, Link Consulting
Contact
Markus Grünewald
Solution Architect
+49 (0) 0173/7279409
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 3
Preface
Almost every company of today’s world struggles with a multi-
tude of external influences, which have a profound impact on
the company’s business. E. g. globalization, start-ups with new
business models and digitalization are only a few, which force
companies to adjust or even reinvent their own business.
What are the first steps? How can you achieve a profound
transformation?
This white paper contains valuable information how to handle
these questions. Using an Enterprise Architecture Manage-
ment, as outlined in this paper, a company will be able to
■ identify those areas which must be transformed first to
achieve a competitive advantage
■ identify routine work which can be automated to increase
efficiency and reduce costs
■ facilitate make or buy decisions
■ build a sustainable IT architecture
If you have any questions, please do not hesitate to contact us
in this case. We would be pleased to discuss these important
topics with you and find specific solutions for your company.
With kind regards
Markus Grünewald Principal Enterprise Architect,
OPITZ CONSULTING
Rolf Scheuch Chief Strategy Officer,
OPITZ CONSULTING
Pedro Sousa Enterprise Architecture Leader,
Link Consulting
1. Introduction
This white paper was created based on a cooperation of OPITZ
CONSULITNG and its partner LINK CONSULTING. The paper
will propose a lightweight Enterprise Architecture (EA)
approach to design, plan and govern a business transformati-
on relying heavily on IT or digitalization.
Different client objectives will imply different flavors of the EA
implementation to reach these goals and support the transfor-
mation. Governing a transformation of infrastructure, maybe
to a hybrid infrastructure, harmonizing business processes for
an efficient operating model or consolidating the existing ap-
plication landscape are typical objectives, where EA helps to
design, plan and govern the change.
In our case, we will focus on the strategic aspect of transfor-
ming the application landscape to meet the requirements of
the target-operating model. The approach is top-down and will
rely on the evaluation of the business capabilities and deducts
architectural requirements of the landscape application. To
achieve this, our approach needs a common
architectural vision for the target application landscape.
We will rely our approach on the following standards:
■ Prince2 for Program Management
(https://www.prince2.com/uk)
■ TOGAF9 for an EA framework
(http://www.opengroup.org/subjectareas/enterprise/togaf)
This white paper will start with a management summary,
a short overview of the approach. Further on we will describe
the approach and the methodology in details and follow up
with a description of the deliverables of the EA related tasks.
In addition, we have added an architectural vision of an
application landscape supporting a digital business models
and references as well as a description of our “favorite”
EA tooling.
2. Management Summary
OPITZ CONSULTING supports companies in the endeavor to
support the current and future business strategy including a
digital strategy. The approach to transform the often distribu-
ted silos landscape into an agile IT landscape as follow:
2.1 Clarify the business and operating model(s)
In conjunction with the top management we will first clarify
which business and operating model(s) should be executed in
the future and which strategic objectives must be taken into
account. After we have identified the core capabilities together,
we will build a core diagram of the company to secure the
same understanding of the overall business, core capabilities-
data and customer outcome.
2.2 Identify and assess business capabilities
Concentrating on the business capabilities needed to
perform the business and operating models, we will first identi-
fy and assess all capabilities. Afterwards we will depict the
result in a business capability model and a capability
heat map.
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 4
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
questions above we can concentrate to align the capabilities
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
necessary roadmap.
With this transformation roadmap in place, we are now able to
answer the following questions:
■ What will be the organization’s systems and technology
evolution over time and how does it affect the organization
capabilities?
■ What are the impacts/dependencies between the different
transformation initiatives in the transformation roadmap?
The overall goal is to build a strong foundation for execution
and an environment for continuous improvement. Figure 1
shows how the capabilities are classified and how the
company capabilities can change over time from
differentiating capabilities over competitive to commodity or
non-core capabilities.
If the non-core and commodity capabilities are automated
(in-house or outsourced) then your company can concentrate
on the capabilities with a high business impact to gain a
competitive advantage.
Figure 1: Competencies and continuous improvement
[Adapted from Business Process Change, Paul Harman]
3. EAM Approach and Scope
3.1 Preamble
It is crucial, in order to be successful with an Enterprise
Architecture Management initiative to adhere to some princip-
les. EAM is not only another tool – it is paradigm shift – if it
was not used in your company before. Thus it involves the
alignment of business capabilities and processes with the
company strategy and will also have an impact on the orga-
nizational structure the support of the top management is
mandatory. EAM is an ongoing task for each company. There-
fore, it is necessary to make an organizational change within
the company and introduce a fully dedicated EA team. OPITZ
CONSULTING will facilitate and coach the EA team. In this way
the team will be able to
■ perform and constantly improve the company specific
Enterprise Architecture Management approach
■ govern the Enterprise Architecture
■ support the organization during transformation
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.
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 5
3.2 Clarify the business and operating model
In order to determine how to build the future foundation for
execution it is necessary to specify the current and future
operating model. To achieve this, we will collect the current
and future business model as well as the related core
capabilities in discussions.
The capabilities will be categorized using the specific charac-
teristics of the different operating models (figure 2). The evalu-
ation of this categorization will help to determine which model
best describes the current and future operating model.
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.
3.3 Identify and assess business capabilities
After a common high-level view of your company‘s business is
established we will start to drill-down on the details. In order
to select the right transformation strategy and to be able to
build a corresponding roadmap it is essential to be aware of
all business capabilities and to assess them accordingly.
3.3.1 Create the capability model
In the capability model, we will outline all business capabilities.
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 3: Capability model
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 6
3.3.2 Create a capability heat map
After the capability model was created in the former step,
each capability will now be assessed using different properties
(e. g. business impact, maturity, potential...). This assessment
determines on which capabilities the company has to
concentrate first.
Capabilities, which have a high business impact and a low ma-
turity level, should be implemented and optimized as soon as
possible. Capabilities with a low business impact are candi-
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
In order to build a high-level transformation roadmap
(see figure 5) we have to inspect each capability assessed in
the heat map. For each capability we have to
■ align the capability with the company strategy/
operational goals,
■ align the capability with business processes
(high-level => value chain),
■ execute a gap analysis,
■ decide if the capability can be outsourced, supported by
off-the-shelf product or should be developed in-house.
Figure 5: Iterative approach to transform from current to
future state
A key requirement while building the roadmap is the
necessity of the organizational readiness of the your company
to deliver the roadmap. If the readiness assessment reveals
areas for improvement we will outline which adjustments will
be necessary to enable your company to execute this
roadmap and to operate the target state.
In order to execute the transformation from the current state
to the future state, an iterative process on a very detailed level
is required. In Figure 6, we have depicted how this
iterative approach has to look like.
Figure 6: Iterative approach to transform from current to
future state
So far, we have outlined the approach without any direct rela-
tionship to an enterprise architecture framework. The next
section will describe how a tailored TOGAF framework will be
used to produce the necessary artefacts.
4. Tailoring TOGAF
To establish and implement a lightweight EAM we will tailor
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,
but start with a lightweight EA approach and develop their
EAM as needed in later stages of the transformation.
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 7
Figure 7: Tailoring TOGAF 4, a basic EA framework
This lightweight approach has two immediate implications:
■ We advise to use EAM from Link Consulting
(http://www.linkconsulting.com/eams/) as a cloud-based
SaaS. With EAMS the information documented in Microsoft
office tools as a simple repository can be shown in a clear
and concise way (see chapter 5).
■ We advise to tailor TOGAF to the actual project context.
Doing so, we have developed the unique EAM, as shown in
figure 7, based on the TOGAF framework. This allows for a
later ramp up on models and EA process should this
deem necessary.
We need an architecture vision of core robust, business-
needs-driven technology architecture. This will be ensured by
implementing „I. Architectural Principle and a target Business
Operating Model“. Both the target model and the target
architecture will undergo a constant review, but from the
beginning of the EAM project, we need a clear understanding
of the target business and operating model as well as
establish an architecture vision.
Based on the „III. Baseline“ and the „IV. Target“ we will perform
an initial gap analysis and define, together with your com-
pany‘s EA team, the necessary II. Initiatives (or well-defined
projects). These initiatives that will be the subject of the
„V. Roadmap“ of the transformation program and thus the
needed business capabilities will correspond with the
initiatives of the transformation roadmap.
Each initiative we discover will describe the necessary
arrangements to execute the initiative within the roadmap
execution. Execution of measures to enable the operational
change is subject of a change management process.
A lightweight „VI. Architectural Change Management“
established and performed by the client to govern the road-
map and thus the transformation program. This will align with
the goal to establish a lightweight approach to
Enterprise Architecture Management.
In the following, we will describe the EA methodology for each
area of work specified above.
Table 1: I. Architectural Principle/Target Business Operating Model
Table 2: II. Initiatives
Area of work I. Architectural Principle and Target
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
Input Workshops with senior management
■ Workshops with senior IT-management
Output ■ Documented architecture vision & principles
■ Documented target business model and operating model
■ High-Level baseline (Business capabilities, applications, technology)
■ High-Level target (Business capabilities, applications, technology)
TOGAF ■ Preliminary
■ A. Architecture Vision
■ B. Business Architecture (high-level)
Remarks ■ A Possible reference architecture for the application landscape could be the Context Aware Frontend Architecture (CAFA) described in section 9.
■ Starting point for the capability map can be the business view of an industry specific Microsoft Industry Reference Architecture (MIRA) or another reference model
Area of work II. Initiatives
Objective ■ Generate a comprehensive, but initial version, of the transformation roadmap including all necessary high-level initiatives of the transformation program to reach the de-sired target
■ Determine and elaborate an iterative, incremental approach of the transition
Tasks ■ Perform gap analysis and define candidates for initiatives
■ Create an architecture roadmap and transformation roadmap (program plan)
■ Perform risk/benefits management on the roadmap
■ Document and communicate measuresfor an organizational change management
Input ■ Gap analysis and candidates (initiatives) for roadmap
■ Architectural vision
■ Business capability heat map
Output ■ Gap analysis and initiatives
■ Updated architecture vision
■ Roadmap as a transformation plan
■ High-level defined initiatives for work
■ Risk/benefits management
■ Change management incl. stakeholder management
TOGAF E. Opportunities and Solutions
Remarks ■ Since the clients must govern the roadmap, the EA team is heavily involved and must perform stakeholder manage-ment as well the risk/benefits management within the organization.
■ The roadmap is basically a plan for the transformation plan and we will use the reference framework of PRINCE2 or PMI for program management
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 8
Table 3: III. Baseline
Table 4: IV. Target
Table 5: V. Roadmap
Table 6: VI. Architectural Change Management
Remark: Please refer to the references in chapter 7 since this
procedure was successfully implemented in existing EA pro-
jects.
5. Core Deliverables
Each initiative, we discover, will describe the necessary
arrangements to execute the initiative within the roadmap
execution.
With reference to figure 5 which illustrates the central steps of
our approach, we introduce key maps to be used as a first
step of a project, from the capability map (1), the capability
heat map (2), the capability context map (3), to the project
context map (4) the project portfolio roadmap (5) and finally
the capability realization map (6).
Figure 8: Overview of project deliverables
Area of work III. Baseline
Objective Develop a clear understanding of the actual status and have a baseline for transformation
Tasks Document the baseline business architecture, information system architecture and underlying technology architecture
Input ■ Workshops
■ Refer to I. Architectural Principle and Target Business Operating Model
■ Existing documentation of value chains and IT systems
Output Documented Baseline of ■ Business capabilities ( Heat Map)
■ High-Level Value chains ■ Applications
■ IT-infrastructure and possible constraints
TOGAF Baseline in B. Business Architecture, C. Information System Architecture, D. Technology Architecture
Area of work IV. Target
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 architecture
Input ■ Workshops ■ Refer to I. Architectural Principle and a target Business
Operating Model ■ Refer to III. Baseline
■ Workshops with subject matter experts (SMEs) and Senior Management
Output Documented target architecture of ■ Business capabilities (Heat Map)
■ High-Level Value chains
■ Applications infrastructure
TOGAF Target in B. Business Architecture C. Information System Architecture D. Technology Architecture
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) ■ Implement EA-Governance for the transformation
lifecycle
TOGAF E. Opportunities F. Migration Planning
Area of work VI. Architectural Change Management
Objective Ensure conformance with the target architecture and vision and perform EA-Governance for change request
Tasks Define an EA-Governance organization and processes (lightweight!!) and implement the EA-Governance
Input Change requests
Output Compliance assessments and possible changes to roadmap or architecture
TOGAF G. Implementation Governance, H. Architecture Change Management
Remarks WARNING: Often the program management is responsi-ble for the transformation and the EA-Governance built around the EA team in the same organization. We advise to split this into an own organization for the transfor-mation program and a “stand-alone” EA-Governance for architectural change
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 9
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.
The following figure shows an example of the Capability Map
generated according to the mapping of business capabilities
to specific business areas. Simple configurations used to
adjust the final look and feel of the generated map.
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 10: Capability Heat Map (2)
To sustain the analysis of each capability, the following figure
shows the key dependencies in the so-called Context Map.
The figure contains examples of the operational goals related
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 11: Capability Context Map (3)
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 10
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 12: Capability Context – Detailed Map (3)
As the result of the analysis of previous dependencies and
gaps, a list of projects “to make” or “to buy” are proposed. The
Project Context Map below summarizes the information
regarding the selected project.
Figure 13: Project Context Map (4)
The overall Project Portfolio Roadmap is depicted in a
Gantt Dashboard on the right above.
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
capabilities, or more precisely, means that all necessary
resources to sustain that capability are in production. Yellow
capabilities show that at least some of the necessary res-
sources are still being brought into production by on-going
projects. Red capabilities are that at least one necessary
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
red capabilities, one can see the missing
resources.
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 11
Figure 16: Capability Context – Detailed Map (3) with realization
filter, according to project portfolio scheduling
6. Organization and Issues
We advise a lightweight governance structure with a minimal
sized steering committee. The steering committee may invite
subject matter experts (SME) or other stakeholder to a
meeting, but the enlargement only planned on invitation
only. The steering committee will meet once at the beginning,
once approx. 3 weeks’ prior the end of the project and other-
wise only by appointment. Figure 17 describes a possible org-
chart of the project organization for an initial EA project:
Figure 17: Project Organization
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:
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.
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.
Risk Impact Counteraction/Mitigation
Lack of support from senior management
Project failure Senior management of client must support the engage-ment.
Time allocated from stake-holders for EA project insufficient
Delay in time line
Project Management (PM) discuss more efficient ways to gain result
Stakeholders do not invest allocated time in project
Delay in time line
PM must insist on invest of stakeholders
Contribution of the EA team is not as high as expected
Delay in time line
Verify skills of EA team mem-bers, PM: Verify training
Enterprise Architecture and IT results are not well accepted throughout the company
Impediment of change process
Strong support by top man-agement and key stakehold-ers. Communication / evan-gelism.
Preserver of the current state influence others in a negative way
Impediment of change process
Strong support by top man-agement and key stakehold-ers. Communication / evan-gelism.
“Ivory Tower” Enterprise Architecture
Impediment of change process
Establish an Architecture Board, with the right key stakeholders, to govern the implementation of EA
The lack of effective gov-ernance from the start
Delay in time line
Consider Governance from the beginning.
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 12
Table 8: Value created by long term engagement with
OPITZ CONSULTING
Remark: We believe that Enterprise Architecture is a discipline
and management process to perform by the client. OPITZ
CONSULTING sees its role as consultant for methodology,
facilitator and coach. The client must lay emphasis on change
management to engage all stakeholders on the
transformation journey and OPITZ CONSULTING can only
help.
Table 9: Value created by long term engagement
with Link Consulting
Company
Network
Maintenance
(Tele-
communication)
Travel insurance
(Insurance)
International
medical
technology
(Industry)
Reference Yes Yes Possible
Duration (PD)
Strategy
■ 6 months
■ 60 PD
Transformation
■ 4-6 years (has ended)
■ 60 PD
Strategy
■ 4 Months
■ 80 PD
Transformation
■ 3-5 years (ongoing)
■ 40 PD
Strategy
■ 6 Months
■ 40 PD
Transformation
■ not yet started
Year started
2010 2012 2015
Objective Modernize appli-cation architec-ture to gain flexi-bility and lower maintenance costs
Harmonize local systems to gain process efficiency
Modernize appli-cation architec-ture to support the digital trans-formation
Goal Implement a SOA based application landscape
Implement a SOA based application landscape for BPM
Implement a flexible applica-tion landscape based on COTS
Method EAM with focus on application archi-tecture ■ SOA
business services
■ Roadmap for application transfor-mation
■ SOA governance
EAM with focus on Business Capabilities and BPM ■ Business
capability maps
■ Value chain analysis
■ SOA business services
■ Roadmap for application transfor-mation
EAM with focus an application archi-tecture ■ Value chain
analysis ■ SOA business
services ■ Roadmap for
application transfor-mation
Sourcing Make (80%) and buy (20%)
Make (50%) and buy (50%)
Make (20%) and buy (80%)
Role OPITZ CON-SULTING
Facilitating and coaching
EA consulting and coaching
Facilitating and coaching
Company Petrobras (Oil)
AMA (Public Administration)
German Credit Bureau Company
Reference Yes (Eugénio Ped-rosa)
Yes (André Vascon-celos)
Possible (Please have Link Consulting make contact)
Duration (PD) Strategy
■ 6 months
■ 60 PD
Transformation
■ 3 years
■ 30 PD
Strategy
■ 6 Months
■ 80 PD
Transformation
■ 3-5 years (ongoing)
■ 180 PD
Strategy
■ 3 Months
■ 20 PD
Transformation
■ On going
■ 75 PD
Year started
2011 2012 2015
Objective Reduce redun-dancy/costs from the busi-ness demand up systems delivery result-ing from having several tens of industrial sites (oil extraction & refineries) in different lines of business (bio-gas, oil, petrol, ...)
Reduce IT redun-dancy (dupli-cated applica-tions) and waste (ex free pro-cessing capabil-ity) between over 650 public or-ganizations of the 10 Portu-guese ministries
Establish an Enterprise Archi-tecture practice, from strategic, requirements to DevOps and tick-eting tools, ensur-ing a better IT planning and management.
Goal Implement a multi-site EA practice to support IT government to ensure provid-ed a common language be-tween Business and IT and thus a better align-ment between business and IT initiatives.
Implement and deploy a Feder-ated Enterprise Architecture capability be-tween the ministries, being AMA the top central site.
EA Roadmap to support the IT Strategic goals properly, the IT Solution Develop-ment Process (from demand management to DevOps) and the IT tooling ecosys-tem. Replace Mega tool with EAMS tool.
Method EAM with focus on process, information, application architecture and project portfolio.
■ Architec-ture of each site ( Process, Infor-mation and Applica-tions)
■ Site gap regarding reference architecture (per line of business)
■ Site transfor-mation roadmap
EAM with focus on application and infrastruc-ture architecture
■ Application catalogue and dependencies
■ Integrate architecture roadmap scenarios with services, SW and HW ac-quisition public process.
■ Optimizations analysis intra and inter organization
EAM with focus on SOA, applications, and infrastructure architecture
■ Define EA meta-model
■ Define norma-tive architec-ture that in-cludes coher-ence rules and model nota-tions (Archimate, BPMN, UML) mapping into repository concepts
■ Migrate data from Mega
Tooling EAMS from Link Consulting
EAMS from Link Consulting
EAMS from Link Consulting
Role Link Consulting
EA consulting and deploy
EA consulting and deploy
EA consulting and deploy
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 13
8. Extended Deliverables
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 18: Simple Goals Dashboard showing
initiative overall progress
After selecting a goal, one can see the contributing initiatives.
Drilling down, one gets a more detailed view (C-2).
Figure 19: Initiatives/projects to achieve the goal
Drilling down on an initiative/project (e.g. CRM System
Consolidation), one gets the project context.
Figure 20: Initiative/Project Context
From here, one can navigate to all domains.
Figure 21: High-Level Transformation Initiatives Roadmap
8.2 Detailed-level samples: applications and technology
Figure 22: Application Context
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 14
By selecting an application (“Account Management
Application“ in these examples), EAMS generates a high-level
view of business context of this application. It shows the
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 23: Application Layered
In this example, arrows indicate the relationships between
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.
In the example depicted in figure 24, components are
classified according to a given layer (Presentation, Business,
Data and Integration).
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
TOGAF, and its evolution according to a list of projects loaded.
In this case, colors in the application indicate before
migration, in migration and after migration.
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 15
Figure 26: Technical Reference Model
Figure 27: Service Performance Dashboard
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
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”.
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 16
This leads to the need of flexible application architecture with
a decoupling of front-end omni-channel interaction
applications (or Apps) from a robust and compliant central
back-end platform:
■ a single common platform
■ a multi-tenanted platform, which will heavily influence the
choice of component parts
■ a platform for back- and front-ends with the need to be
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-
print is used by OPITZ CONSULITNG as a pattern for
application transformation with digitalization and will help
your company to customize and build a client specific
reference architecture as the top-down business capabilities
are defined and evaluated in a “Business Capability Heat Map”.
As stated, each business capability must be analyzed and
evaluated as to have a clear picture of the possible solutions
(as COTS) to be taken into account.
As to address the need for change by decoupling front-end
and back-end, the business capability tagged according to the
possible customer interaction scenarios. In the case of an
omni-channel interaction with customers, even as a self-
service app, the front-end must decouple from the back-end
as to ensure innovation, implementation of cultural
differences and a rigid customer experience (CX) approach.
From OPITZ CONSULTING perspective, this can be the key
differentiator in your specific market segment.
9.1 Context aware front-end architecture (CAFA)
OPITZ CONSULTING has developed the CAFA blueprint in
different client projects as to have an architectural vision and
application architecture to address the needs of a digital
transformation and a “Designed for change” approach.
Starting point was the blueprint of a four tier architecture by
Forrester with an emphasis on a specific delivery tier for mobi-
le services. As this was only sufficient to address security and
scalability, we enhanced the delivery tier with aspects of de-
coupling of the front-end application from the back-end
systems, the usage of microservices architectures, the
possibility to follow a “Make and Buy” application strategy,
integrate legacy systems and have context-aware application
(here Netflix was the blueprint for omni-channel interaction).
Figure 29: Context aware front-end architecture (CAFA)
9.1.1 Front-end diversification and CX
As stated, the CX will be a key differentiator for your company.
The CAFA is able to support different programming
techniques and frameworks.
The key is the usage of reliable back-end services of the
Service Tier, but with a CX-centric designed approach for the
front-ends. During the EA consulting, the business capabilities
must be analyzed in regard to the needed user experience
and the possible devices used to interact. Context awareness
will help switching the devices without losing the “transaction
context”.
As CAFA was designed for incorporating the Internet of Things,
front-end apps can span out and addresses the business logic
of desperate applications systems, thus building new infor-
mation and interaction models based on existing
business services.
Decoupling of front-end and back-end will a bimodal-IT
approach with robust, slow changing back-ends and fast
moving, CX-centric front-ends.
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016 PAGE 17
9.1.2 Use as a platform
The CAFA blueprint considers the possibility, that third
parties may use the architecture and the business services as
a platform for their services. This opens the possibility for the
client to engage third party products to leverage the
investment in the new platform or add value for the client by
offering innovative third party solution.
9.1.3 Use as an evolutionary platform
Within certain non-functional requirements, the CAFA blue-
print will allow a “Make and Buy” strategy as well as evolving
the architecture during the transformation. This feature of
CAFA is necessary, since existing application platforms must
evolve during time.
Figure 30: Make and Buy decisions within the Context Aware
Frontend Architecture (CAFA)
As the figure 30 with the #1 implies, that the client will be able
to buy COTS applications or user legacy-systems a self-
contained application coupled by an integration layer in the
service tier. Since these self-contained applications do not
furnish an API for the front-end usage, they are not incorpo-
rated in the heart of CAFA and be subject of replacement over
time. The #2 and #3 describe the preferred approach for
COTS. The COTS may or may not have its own front-end,
mostly used by the clients staff, but will deliver business ser-
vices as objects of the service tier and to use by the front-end
applications.
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.
To the point:
■ COTS with interaction by back-office staff, may have its
own front-end
■ COTS with services invoked by end user should have a
business service façade
■ SaaS solutions are specific COTS
■ Own staff should focus development on a best-in-class CX
with unique, custom-build front-ends
■ Front-end technology need not be contained to specific
vendor offerings, but will focus on the best CX
■ CAFA does not imply any restrictions on the infrastructure
and is open for cloud models as IaaS, PaaS or even SaaS
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/
The EAMS system can be licensed as an on premise or a SAAS
solution. If your company does not want to acquire EAMS we
will deliver the resulting diagrams (see section 3) at the end of
the engagement to document the AS-IS and the to-be
state. However, we strongly recommend the usage of EAMS to
facilitate the daily work in the EA context.
10.1 Demo system
In order to get familiar with EAMS, Link Consulting
will provide soon a demo system on
http://www.linkconsulting.com/eams/. Please check regularly
for the demo system.
© OPITZ CONSULTING DEUTSCHLAND GMBH 2016
WHITE PAPER „MANAGING IT TRANSFORMATION WITH EA“
11. Conclusion
Meanwhile it is widely accepted that IT is no longer only an
instrument to support the operational work of a company but
IT is a core capability for most companies. Nevertheless, many
companies struggle to use their IT budget and resources
effectively. The limited budget and resources are very often
used to operate and maintain highly customized applications
and heterogeneous IT landscapes as to secure the business
continuity.
Thus, the IT is often not aligned with the company’s strategy
and is not focusing on supporting the right business capabili-
ties. Typically, the IT is more solution and project orientated
and as a result focuses on such solutions which at low cost
also only provide a low business impact. Many companies are
missing the opportunity to use IT as an enabler for competiti-
ve advantages.
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
to the company. The application landscape and roadmap will
help the IT of your company to react faster on market changes
and to use the budget and resources effectively.
Further on, the presented approach is a starting point for a
lightweight Enterprise Architecture Management to govern the
IT-architecture and the change always aligning the technical
capabilities with the necessary business capabilities.
OPITZ CONSULTING and LINK CONSULTING have developed
this lightweight Enterprise Architecture Management ap-
proach to address the needs of flexibility, digitalization and
cost efficiency in building and maintaining IT-architectures.
Don’t hesitate to contact us, so we ca discuss the value of the
presented approach with you and your organization.
About OPITZ CONSULTING
OPITZ CONSULTING is a leading German specialist for
custom-build applications and digital transformation. We
focus on an End2End Application Lifecycle Management for
your BPM, SOA, Java and Big Data solutions.
Since 1990 over 600 customers have a long lasting and
successful business relationship with us. Over 2/3 of the Ger-
man stock index (DAX) companies rely on services from the
400+ OPITZ CONSULTING consultants. In 2008 our company
has established a near-shoring capability in Poland.
OPITZ CONSULTING is a Platinum Partner of Oracle and
our emphasis is on the digitalization of business models using
the converging technologies from Oracle for Big Data,
Internet of Things, Cloud Services and Engineered Systems.
Further Information: http://www.opitz-consulting.com
About Link CONSULTING
Link’s key mission is to generate value to its customers
offering technology innovation in the areas of information and
communication technologies.
Internationally Link Consulting is present in Brazil, Spain and
Angola with own offices and develop different activities in
countries such as Belgium, Brazil, Cape Verde, Canada,
England, France, Ireland, Israel, Luxembourg, Morocco, Mo-
zambique, Malta, Portugal, Spain, S. Tomé and Principe and
Switzerland.
Some of Link’s main customers are most of the national large
companies, mainly in Telecommunications, Bank and
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