The key for managed change is actability How to master application landscape transformation
Fighting a complex application landscape and meeting with changing business requirements
requires recurring transformation processes. Within the field of Enterprise Architecture (EA),
several frameworks have been developed apparently addressing issues of a managed evolution of
the application landscape. In this white paper, however, we challenge selected frameworks from an
application landscape transformation point of view. Referring to t-eam – our toolbox for enterprise
architecture management - we chart the territory for an extended view on application landscape
transformation.
Introduction
Driven by the increasing need for a strong alignment of business and IT, Enterprise Architecture
Management (EAM) has come to the forefront of practitioners’ and researchers’ attention during
the past years. Being an approach that not only captures the current situation but also shapes the
future enterprise, EAM is concerned with both the as-is and the to-be enterprise architecture (EA).
Thus, EAM is seen as a significant facilitator of systematic change.
At the same time, many organizations today face the difficulties that come with a higher
complexity of the application landscape and the constant need for change. Reducing this
complexity and accounting for the required changes demands a recurring transformation of the asis towards a to-be landscape. Yet, determining the composition of the future landscape and then
achieving this state may turn into a huge challenge using methodological support in form of a
black-box approach. This is due to the fact that such an approach would mean that a development
of the future landscape that is particularly based on a thorough assessment of the status quo is not
detailed and that steps of a successful transformation path to walk are not depicted in a
transparent way. Instead, a managed landscape evolution requires an actable approach that
provides systematic guidance in relation to issues like collecting and analyzing application
information, evaluating transformation options, detailing solutions, executing change and, ideally,
deriving and establishing references for future transformation projects.
Within the field of EAM, methodological support is provided by dedicated EA frameworks. Since
application landscape management is a focal point of EAM, EA frameworks seem to be a promising
instrument for systematically transforming the application landscape. Thus, it appears to be of
great interest which guidance for application landscape transformation - a specific concern with
growing significance for today’s organizations - selected EA frameworks actually provide. Referring
to our toolbox t-eam, this white paper addresses this question and eventually demonstrates how to
attain greater transformation transparency and actability than provided by common frameworks.
Criteria of methodological support for application landscape transformation
From a temporal application landscape management perspective, EAM pursues the following goals,
embodied in corresponding transformation steps:
1. Representation of the current application landscape in form of an as-is picture
2. Design of the to-be picture of the application landscape
3. Realization of the to-be picture of the application landscape
Achieving the goals stated above requires a systematic transformation approach that (in particular)
satisfies the following criteria:
1. It offers a defined procedure model (what?) for transformation.
2.
Furthermore, it details guidelines and techniques (how?) as a vehicle for realization of the

act! | John-F.-Kennedy-Platz 9 | 38100 Braunschweig
T: + 49 (0) 531 123 37 0 | F: +49 (0) 531 123 37 20
Email: [email protected] | www.act-consulting.de | www.unternehmensarchitektur.de
October 2009
1
procedure model.
In specific, for the evolution of the application landscape to be actable and manageable, the
defined transformation steps should be supported by guidelines and techniques of the following
kind, spanning both strategic and operational architecture management issues:
•
Data collection and documentation
•
Analysis and visualization
•
Decision making/ planning (e.g., transformation options and their priority)
•
Implementation
Given the increasing relevance of standardization in today’s enterprises, one factor that should play
an important role within both analysis and decision making/ planning is the conformance with
relevant standards. Since projects are the executors of a managed evolution of the application
landscape, guidelines of decision making/ planning and implementation should further specifically
address the integration of application landscape transformation with Project Portfolio Management.
Eventually, transformation methodology related to implementation should also deal with the final
development of defined software solutions. At best, this may build upon prior experiences and
proven patterns in order to accelerate the completion of corresponding projects.
Application landscape transformation and the role of EA frameworks
To appreciate the role of EA frameworks within application landscape transformation, we review
three selected frameworks and test them against the set criteria: the Zachman Framework, the
Open Group Architecture Framework (TOGAF), and the MOD Architecture Framework (MODAF).
The Zachman Framework has been designed as a response to the necessity of an architectural
approach to “keep the business from disintegrating.” EA is described along six perspectives
(planner, owner, designer, builder, sub-contractor, working system) and six dimensions (data,
function, network, people, time, motivation). With its unique flexibility and independence from
specific methodologies, however, the Zachman Framework does not provide any procedural model.
In fact, there is no guidance on the implementation of the framework.
The Open Group Architecture Framework (TOGAF) is developed and maintained by the Open
Group Architecture Forum and is supposed to assist “in the acceptance, production, use, and
maintenance of architectures.” In contrast to the Zachman Framework, TOGAF (Version 9) places
first-order attention on a method for architecture development (ADM), consisting of the following
phases: preliminary phase, architecture vision, business architecture, information systems
architecture (data architecture, application architecture), technology architecture, opportunities
and solutions, migration planning, implementation governance, architecture change management
and, as a cross-lifecycle phase, requirements management. The application architecture is dealt
with through a dedicated series of steps, in particular those of depicting the baseline architecture,
developing the target architecture, performing gap analysis, defining roadmap components and
resolving impacts across the architecture landscape. TOGAF features several viewpoints,
techniques, models and artifacts which are promising for application landscape transformation
purposes, e.g.,
•
Documentation: Application Portfolio Catalog, Interface Catalog
•
Analysis: System/ Organization Matrix, System/ Function Matrix, Application Interaction
Matrix, Application Communication Diagram, Process/ System Realization Diagram
•
Decision Making/ Planning: Gap analysis technique, Application Migration diagram,
Migration planning techniques (esp. Business Value Assessment)
•
Implementation: Architecture Contracts, Reference Models (TRM, III-RM)

act! | John-F.-Kennedy-Platz 9 | 38100 Braunschweig
T: + 49 (0) 531 123 37 0 | F: +49 (0) 531 123 37 20
Email: [email protected] | www.act-consulting.de | www.unternehmensarchitektur.de
October 2009
2
TOGAF also raises awareness of a necessary integration with PPM. For one, this is reflected by the
following aspects:
•
Consideration of PPM within the initial evaluation of the organizational context for EA
•
Recommendation to take project portfolio managers into close consideration in stakeholder
management, since “an understanding of project content and technical dependencies
between projects adds a further dimension of richness to portfolio management decisionmaking”
•
Suggestion to examine potential impacts of transformations on any other projects, and vice
versa
The MOD Architecture Framework (MODAF) is the “UK mechanism for describing, analysing
and actively managing defence enterprises.” It offers a high-level architecting process consisting of
six steps: establish intended use, define architecture scope, develop data requirements, capture
architecture, conduct analyses and document results (i.e., identify necessary architectural
changes). Most importantly, MODAF features a rich set of EA views that may facilitate the
representation of the as-is application landscape (in MODAF terms this comprises the steps
“capture architecture,” and “conduct analyses”). These views are categorized under different
viewpoints: the strategic, the operational, the service, the system, the acquisition, and the
technical standards viewpoint (plus the “All Viewpoint” that offers an overarching description of the
architecture). For application landscape transformation, the system viewpoint is of greatest
relevance. The corresponding views center on the description of resources and their interactions.
Doing this, the system viewpoint does not solely focus on applications and infrastructure
components, but also considers human factors, and their development. Essentially, the system
viewpoint suggests a specific view (SV-5) for mapping applications to operational activities. Further
viewpoints of relevance for application landscape transformation are the acquisition and technical
standards viewpoint. The acquisition views, on the one hand, show transformation projects and
their dependencies, thus addressing issues of PPM. The technical standards views, on the other
hand, deal with the definition of technical and non-technical standards and policies.
All in all, however, our review results in the identification of the following shortcomings:
•
•
In general, transformation guidelines and techniques are limited in scope and depth and
remain on a rather generic level. The execution of featured transformation steps may
require further clarification and detail.
o
Although the need of building an accurate application inventory is acknowledged,
techniques of data collection are barely detailed.
o
Techniques applicable to issues beyond documentation are limited.
o
Analysis techniques address only selected stakeholder concerns related to the
application landscape, and scenario-based decision making receives only minor
attention.
o
Advice for a standards-driven landscape analysis and planning does not come into
the focus of attention.
o
The procedural interplay with PPM remains on a moderate level of detail.
o
In particular, the step of implementation is not adequately made executable. The
solution development lacks sufficient detail in terms of determining factors for
solution design and the re-use of existing standards.
The development of the to-be landscape is not closely related to a preceding evaluation of
the as-is landscape, leaving impacts of weaknesses of the current on the design of the
target landscape underexplored.

act! | John-F.-Kennedy-Platz 9 | 38100 Braunschweig
T: + 49 (0) 531 123 37 0 | F: +49 (0) 531 123 37 20
Email: [email protected] | www.act-consulting.de | www.unternehmensarchitektur.de
October 2009
3
Using t-eam for application landscape transformation
Overcoming the presented shortcomings requires greater transformation actability – a focus of our
„toolbox for enterprise architecture management“ (t-eam).
t-eam consists of several independently usable components. Together, they make up a
comprehensive EA process (with a particular dive (dedicated steps) into the application landscape)
that is complemented by an architecture meta model and proven organizational patterns:
•
Design enterprise architecture: Methodical planning of the enterprise architecture,
embedded into strategic IT planning.
•
Design business architecture: Design and development of the business architecture.
•
Design application landscape: Landscaping of the application portfolio.
•
Design application architecture: Business-oriented design and development of software
architecture artefacts.
•
Design systems architecture: Efficient and demand oriented development of the IT
infrastructure.
•
Design reference architecture: Making gained experiences re-usable through structured
descriptions of reference architectures.
•
Meta model: Structured architecture model to be able to document and evaluate results in
a meaningful way.
•
Organization model: Best practices for project organization, guidelines for
communication and marketing and practically tested role definitions for a successful
introduction and operation of architecture management.
t-eam provides guidelines and techniques in the form of EA services. An EA service is the
description of a deliverable type that is generated by the Enterprise Architecture Management in
order to meet the needs of one or more stakeholders with respect to particular information or
output. EA services can be structured along the EA lifecycle: documentation (document!), analysis
(analyze!), planning (plan!), implementation (act!) (and governance - check!). Application
landscape-related examples from our catalog of EA services are the following:

act! | John-F.-Kennedy-Platz 9 | 38100 Braunschweig
T: + 49 (0) 531 123 37 0 | F: +49 (0) 531 123 37 20
Email: [email protected] | www.act-consulting.de | www.unternehmensarchitektur.de
October 2009
4
document!
Application Map
Interface Map
Unternehmen Kunden
Produkte
Neugeschäft Bestand
steuern
betreuen / entwickeln akquirieren / verwalten
(Strategie/
Markt
Risiken prüfen
Governance) analysieren
Bewertung der Anwendungssysteme (Wertschöpfung, Strategiebeitrag, Kosten)
0,30
0,32
CRM
0,20
wirtschaftliche Wirkung
Finanzen
kontrollieren
und steuern
Leben
0,25
analyze!
Risiken
steuern
0,22
0,09
SAP -FI
0,15
Kranken
PoS
0,03
0,04
Vertragsverwaltung
0,25
Leistung
Komposit
Provision
SAP CO
0,10
0,02
Rückversicherung
PEAP
DWS
0,05
0,20
Stat.Vertrieb
0,60
Bauspar
Internet
0,10
0,00
0,00
Finanzierung
0,05
0,10
0,15
0,20
0,25
0,30
0,35
0,40
0,45
0,50
-0,05
Industrie
strategische Wirkung
Business Support Matrix
Portfolio Matrix
Compliance Check
plan!
To-Be Landscape Scenario
Road Map
act!
Architecture Scenario Check
Standards Portfolio
Further t-eam features worthy of mention since facilitating transformation are as follows:
•
t-eam offers a systematic approach to data collection that takes into consideration a
variety of potential sources, e.g., humans, IT management systems, or (business)
applications themselves. That is why data collection may be done using several options, in
particular automatic, semi-automatic and manual ones.
•
For the future landscape to be adequately built, there are numerous transformation options
considered by t-eam. Being aware of the rationales behind these options, they can be
weighed against each other in a straightforward way, e.g.,
•
o
If applications are no longer used, are managed specifically for a business unit no
longer considered financially viable, or support business processes that are
outsourced to third parties, the adequate transformation option is likely to be a
disposal.
o
If the application landscape is subject to high development and maintenance efforts
and there is a lacking quality of business process support, the application landscape
may need to be significantly modified through greater or optimized integration.
t-eam puts special emphasis on the integration of EAM with other management processes,
in particular on that with PPM. On the one hand, this is reflected in t-eam’s organization
model, giving advice on how the interaction with PPM may take place on an organizational
level. On the other hand, t-eam points out procedural aspects such as the following:
o
Prior to the approval of proposed transformation options, the project portfolio

act! | John-F.-Kennedy-Platz 9 | 38100 Braunschweig
T: + 49 (0) 531 123 37 0 | F: +49 (0) 531 123 37 20
Email: [email protected] | www.act-consulting.de | www.unternehmensarchitektur.de
October 2009
5
should be carefully reviewed in terms of applications which are already planned or
being implemented in order to avoid duplicate efforts.
•
o
The construction of a transformation roadmap should be done in consideration of
any project dependencies.
o
During implementation of the approved projects, the progress is monitored on an
ongoing basis, i.e., each chosen action is carefully managed throughout the
implementation and kept aligned with its specific business case.
o
Moreover, regular compliance assessments may be conducted, i.e., assuring that
the implementation is proceeding in line with the architectural principles, standards
and objectives.
Unlike many other approaches, t-eam provides dedicated support for the implementation of
the target landscape. This is due to t-eam’s comprehensive approach to operational
architecture management. Facilitated by sophisticated standards management practices,
t-eam’s operational architecture management processes are closely linked to the strategic
ones and allow projects to be completed in an accelerated way.
Strategic Architecture Management
Design
Enterprise
Architecture
Operational Architecture Management
Design
Application
Landscape
Design
Application
Architecture
Design
Business
Architecture
Design
Systems
Architecture
Design
Reference
Architecture
For information please contact:
Daniel Simon
phone: +49 (0) 531 / 12337 13
email: [email protected]
While we have made every attempt to ensure that the information contained in this document has been obtained from reliable sources, act!
is not responsible for any errors or omissions contained herein or for the results obtained from the use of this information.

act! | John-F.-Kennedy-Platz 9 | 38100 Braunschweig
T: + 49 (0) 531 123 37 0 | F: +49 (0) 531 123 37 20
Email: [email protected] | www.act-consulting.de | www.unternehmensarchitektur.de
October 2009
6