Managing IT Transformation with Enterprise Architecture ...

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

[email protected]

+49 (0) 0173/7279409



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.



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.



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



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.

http://pubs.opengroup.org/architecture/togaf9-doc/arch/



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



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



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)



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.



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


Strong support by top man-agement and key stakehold-ers. Communication / evan-gelism.

“Ivory Tower” Enterprise Architecture


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.



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





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



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.



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



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.



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


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

http://www.opitz-consulting.com

http://www.linkconsulting.com

Managing IT Transformation with Enterprise Architecture ...

Documents

Transcript of Managing IT Transformation with Enterprise Architecture ...