This page is
published under the terms of the licence summarized in the footnote.
How can you plan changes to a structure if you don’t know what the
structure is? How can your IS/IT department plan solutions that are optimal for
the enterprise (rather than suboptimal and localized) without an
enterprise-wide repository of its data processing assets? Every enterprise
should record its assets – at least at an overview level.
This paper is divided into five sections,
on:
In practice, a complete
enterprise architecture repository is "virtual”, comprising several
physical repositories. People use not only:
They use also various other
tools to maintain specific management information. Where does your enterprise
record its business goals, its balanced score card, and financial data relating
to assets or projects? For example, a
“One government department I
have worked with stores its architecture models in a CASE tool repository, and
publishes its architecture documents (pdf and Word) in a Knowledge Management
portal. Its divisions (LoBs if you like) store mandatory model information in
the enterprise-wide CASE tool repository, but each has its own portal for
architecture documents. Some documents are linked to models; some are not. Another
tool is used to record fine-grained investment reports (although the CASE tool meta
model was modified to record high level investment information).” Steve Else
PhD.
One purpose of an architecture repository
is to support impact analysis in change management. Linking between physical
repositories presents configuration management challenges. You can reasonably
copy entities
and model diagrams from a CASE tool into a deliverable document when you
publish it. But if you try to link from that documents to entities and models
stored separately in a CASE tool (which is continually updated) then you have
to wrestle with the version control issues that arise. E.g. Your CASE tool must
store past versions of entities and model diagrams, to support any published
deliverables that refer to them.
It is best to think of an architecture deliverable document as view of an architecture at a state. It might be archived in a repository, but it is a historical record, it cannot be updated and it is outside the scope of this paper. The rest of this paper is about the elementary entities and model diagrams that are kept up to date in the core architecture repository. It is important that this core repository supports every kind of change at every level of change management. We’ll return to this later.
Some enterprises employ an enterprise architect when managers realize things are out of control – the enterprise is not governing its assets as well as it should. Managers don’t know what the enterprise owns, what it is today. So their main interest is the current or baseline state. You, the newly-appointed enterprise architect, have a mission simply to know and understand the scale and complexity of the current estate.
Other enterprises employ an enterprise architect to help them plan ahead – to define their business, IS or IT strategy – to define what they aim to become. They are interested not only in the current baseline state, but also a future target state and the migration from the former to the latter.
Both kinds of enterprise need some kind of architecture repository to store/view descriptions of the enterprise and its systems. An architecture description is a model of a system – it is a restricted view of reality - it does not tell you everything, but it should tell you what you need to know to make well-informed judgements about where change is needed and the impact of change.
You can be sure that things will change. The business will be reorganised. Enterprises are driven to change by various pressures. They are increasingly driven to make big changes, fast changes, and look for dramatic cost reductions. Enterprises frequently divide and merge. Giving old assets away is easy. Integrating new assets is hard. Mergers can and do founder on the difficulty of consolidating the various information systems used by the formerly distinct enterprises. You can draw some inspiration from the fact that successful change will require the knowledge of the enterprise that you (enterprise architect) manage.
You will want to:
·
Record and show the current estate
·
Record and show strategic business and technology goals and directions.
·
Demonstrate that planned IT changes relate those goals
·
Demonstrate that planned IT changes result in simplifications and cost
reductions
· Enable IT assets to be evaluated, managed, and changed.
·
Enable enterprise transformations to be made with minimal costs and
risks to business operations.
You are employed to manage the structure of an enterprise’s assets, and to plot transformations from a current state to a future state. You expect to get involved in:
·
Understanding the structure of the baseline and target architecture
states.
·
Planning the transformation: plotting the most effective transformation
path from the current state to the future state.
·
Helping programme/project managers to govern the transformation: manage
the transition.
·
Developing and maintaining the enterprise architecture and providing
technical/design assurance for all enterprise initiatives/projects against it.
A repository should help you:
·
Understand the system described. Building and displaying a model of complex
structures helps people to understand them.
·
Relate IT to business. You can do traceability analysis,
to show which assets relate to which goals, requirements and constraints.
·
Identify potential changes. You can do gap analysis and cluster
analysis, to spot areas where changes are desirable.
·
Plan changes. You can define a target or vision architecture by
manipulating elements of the baseline architecture,
·
Manage changes. You can do impact analysis following any
change proposal.
Solution
architects often document architecture descriptions in diagrams and documents,
and that can be enough for small and/or short-term projects. Larger and
longer-term projects and programmes require a more flexible form of documentation
- that can be manipulated by several architects and presented in a variety of
ways. They need a repository from which up-to-date views can be generated.
Views help you manage a complex repository. It is hard to understand a complex structure all at once. You can better understand a partial view that suppresses details shown in other views. Dividing a complex model into loosely-coupled parallel structures makes it easier to understand and change each on its own. You should select the views and models to suit your target audiences.
Graphical representation helps you understand a view. It usually assists understanding and manipulation of a view, and hence of the underlying repository.
But views are superficial. An architecture repository should help you to add or remove views at will. Given a migration with 10 stages and an architecture repository with 10 view points, there are at least 100 potential views, but you do not have to maintain and present all those views if the underlying data is stored for when you need it.
The repository matters more than the pictures. To manage a complex transformation you need a coherent architecture repository more than pretty pictures.
The repository must be coherent across all views. An architecture repository relates elements in different views to each other. An enterprise architecture repository must be maintained in a repository that underpins any and all views.
The repository must be coherent across all stages. Planning a transformation means plotting how structures change over time. Migration can involve transition through several intermediate states. The architecture repository must remain coherent and consistent over time, as well as over views.
In the philosopher’s “eternal golden
braid” there are things, descriptions of things, and descriptions of descriptions. An
architecture description contains a collection of artifacts that are related to
each other directly or indirectly. You simply cannot manage a large and complex
architecture description without describing the description itself.
The
description of description, or model of a model, is known here as a meta model. A meta model can help you manage
documentation in Word and Excel. But if you store your description in a CASE
tool, then the meta model is not just helpful, it is essential.
You must understand the meta model - must understand the model of the architecture repository, even if the readers of any given view do not.
This section outlines a step-by-step process you may find helpful when
starting up an architecture repository.
You don’t want to
end up with enterprise architecture descriptions that meet the abstract goal of
fully populating the Zachman Framework, but have more authors than readers. Be clear who
will use your repository and for what.
A common purpose is to support impact analysis in change management. But
different people look after different kinds of asset and manage different kinds
of change. Are you building
an
If your goal is the first, then how does this relate to the other two?
We’ll return to this later.
Bear in mind that
elements of architecture description that are not used, do not have consumers,
will decay - as any unused data does. So don’t set out to store what you cannot
use. Be realistic about how much detail can be maintained.
You have to choose
the scope and level of detail that you are able to maintain. Consider the four
dimensions on which the scope of architecture work may be measured.
Nobody has yet
built one architecture repository that defines a complete enterprise from top
to bottom on every scale of abstraction. It is wise to start with the simplest
repository structure you can maintain and gain value from.
You can meet some narrow short term purposes without thinking hard about
the meta model of your architecture description, but eventually you need to
design this meta model with care to ensure it contains the entities, attributes
relationships you need to answer questions and do change impact analysis.
Your entities may include any or all of the deliverable artifacts
mentioned in our other guides. The attributes and relationships of these
entities may include any or all of the fields listed in our deliverable
templates. Our templates probably include more attributes than you can maintain
in a general enterprise architecture repository, but perhaps less than you need
to fully define a specific solution.
You might start with spreadsheets. It won’t be long before you need
something better. If you are more concerned to have a repository than a drawing
tool, then you might build an MS Access database. You might build your
architecture repository on top of an existing configuration management
database. For a large or long-term effort, you’ll need to purchase a CASE tool.
The final section below contains notes on what a CASE tool should do for you.
It is to be expected that your enterprise already records architecture
artifacts in many place. E.g. you may find various partial repositories:
It is not to be
expected that your repository will replace all these, so you have to regard
some or all of them as data sources or targets, to be integrated with your
repository.
Identify what data from the various repositories can and should be
aligned. Put mutual update processes into place.
If your architecture repository supports a one-time solution
architecture, then the data may be migrated from your repository into these
other maintained repositories.
If your architecture repository supports a long-term enterprise
architecture, then the data may be migrated to your repository from these other
maintained repositories.
For long-term maintenance you need governance processes that ensure a
solution architect
Solution architects may create a solution architecture repository for
the purpose of supporting a specific deliverable that is presented once only –
perhaps to win some business. They use the repository as a tool to manage a
large body of complex and interrelated information.
I have added some
experiences and some comments from Roy Roebuck, Director, One World Information
System, An Educational Non-Profit Organization http://www.one-world-is.com
Management consultants and solution architects often build a repository
to help them understand the current business and technical environment, and
present plans to rationalize the business structure or application portfolio,
or technology portfolio, or present plans for a major migration from on
structure to another.
Fine. But often, no long term repository usage is defined. There is no
long term sponsor, budget and resources. So once the consultancy assignment is
complete, the repository falls into disuse. The next-employed consultants are
quite likely to start again.
You need to ensure it contains the entities, attributes relationships
you need to answer questions and do change impact analysis. You also need to be
able to change the meta model to meet new needs.
See our implicit TOGAF meta model for an example. But
there is no one universal meta model. You need different meta models at
different levels of abstraction and at different times in the development and
maturity of solutions. We offer other papers and guides on meta models.
The final section below contains notes on what a CASE tool should do for
you.
A reader writes: I work with several ontology tools -
open source and commercial as well, but they are still immature.
You may want your repository to answer questions like - What
applications and components are affected by a change to this logical entity
definition? So, you want to record which applications and components access
which database tables - and which tables contain data from which logical
entities.
That is an enormous amount of detail. Your enterprise may have hundreds
of applications and scores of thousands of coded components. It may have 20,000
logical entities about which some persistent data needs to be stored. And the
data recording instances of these entities can be spread across about 500
current physical databases. Obviously, some entities appear in several
databases.
Failing to estimate the size of the repository is a problem that underlies most
of the remaining challenges. You might respond to challenge of large data volumes
by abstraction, by omitting details, but this leads to its own difficulties,
also discussed below.
Your repository can lose sponsors when users spot mistakes and
inaccuracies in the repository, even if these are just out of date information.
Roy says: Credibility/trust
is gained by resolving the spoke data inconsistencies and inaccuracies through
coming to a common, controlled vocabulary, by semantic analysis of the spokes'
varied data values and metadata, which is to be aggregated in the hub
data/metadaa store, and integrated/federated/unified using a common
"reference" dictionary taxonomy, thesaurus, and ontology - aka EA
meta model.
In practice, the information you want to store once and once-only in
your architecture repository will be duplicated and perhaps maintained in other
places. You enterprise has hundreds of operational applications and many
projects under way. Now consider the many repositories that may be in use to
manage them.
In practice, different people need different views - at different levels
of granularity - of the same things. E.g. The IT operations view of
applications and components is different from the IS development
view. You want your repository to be
credible to the people who use these various narrow-purpose repositories. Your
repository must be a hub that integrates the many related "spoke"
repositories. To build the required level of integration needed is a systems
integration project in its own right.
A
reader writes: XMI could be used as an interchange format.
Given the size and complexity indicated above, maintenance of data by
hand is out of the question. The first challenge is to ensure the repository
data is mostly self-sustaining through the operation of automated integration
interfaces.
Then, ongoing maintenance of the repository will need permanent
resources to.
The resources above could cost US$1M or US$2M over a year.
Roy says Much of the
technology to support this is probably already in the organization, but you
would probably need to purchase a US$50K to US$200K EA modeling and repository
suite, and a US$10K to US$100K semantic analysis capability along with its
interface to (to populate) and from (to refine) the EA repository.
Is your architecture repository to answer the question - What
applications can be discarded or consolidated? e.g. I worked with a French
company. They built an enterprise architecture repository which was based on
six lists (I think business functions, organisation units, locations,
databases, applications, technologies). Items in one list were mapped to items
in other lists.
Problem? It was lacking the detail need to make good decisions. Suppose
we have 15 employee time-recording applications. Do we consolidate them? It
turned out that the time recording systems captured very different detail for
very different kinds of business, in countries governed by different employment
laws.
Is your architecture repository to provide the high-level structure for
solution designs? e.g. I worked with a solution team in a national transport
organisation on a large five year application development project. An
enterprise architect consultant had built (by top-down decomposition) a model
of the business functions and processes.
Problem? The solution architects and analysts found these functions and
processes to be defined at such a high level of composition as to be
irrelevant. They spent some time worrying about how to transport the model from
an upper CASE tool into their development CASE tool, and eventually agreed it
was simply not helpful.
Is your architecture repository to validate the details developed in specific
solution designs. e.g. I worked with utility company in the
Problem? This model was an ivory tower generalisation that turned out to
be no use to people developing specific solutions to specific business problems
and requirements.
A purpose of architecture repositories is to support impact analysis in
change management. Your repository must support every kind of change at every
level of change management. The next section explores this in more detail.
What’s wrong with CASE tools is that the market is (still) not mature.
Buyers don’t really know what they are looking for. There are many tool
evaluation schemes in the public domain. TOGAF’s evaluation criteria are all
reasonable. Yet buyers don’t really gets to grips with something that matters
above most other things, that is, usability. This section draws attention to
some features that really do matter when you are using a tool.
The two major functions are drawing and recording. And
there are two broad classes of CASE tool.
Some drawing-first tools make life difficult for repository maintainers.
Some repository-first tools make life difficult for diagram/view
drawers.
You need a CASE tool that combines Power-Point-like
drawing with intuitive repository maintenance.
You want to sketch diagrams without saving changes to the
repository as you go.
You want the drawings to provide a user-friendly data capture mechanism
for repository maintenance.
You want the tool to automatically generate drawings and matrices -
filled with objects you have selected from the repository.
You want to re-use objects by selecting objects in one
diagram, then copying & pasting them into any other diagram that can
legitimately contains objects of that type.
You want to lassoo objects and/or fast click on a selection of objects,
and copy and paste the set selected
You want to copy and paste a whole structure of objects from one diagram
to another, preserving the physical structure of the copied-from diagram in the
copied-to one.
(Power Point has these and scores of usability features missing
from some CASE tools.)
And when you paste objects into a diagram, you want to see any
relationships it has to objects already in that diagram
Again, a purpose of architecture repositories is to support impact
analysis in change management. Your repository must support every kind of
change at every level of change management. It should help you address the
issues raised in ref. 2.
In particular, your tool must help you turn any work you do into a
local-only change, or a global change, or a change that affects a selected
subset of whole configuration. “Global” here means throughout a named
configuration, at a named version. “Local” means only the object or diagram you
are working on.
You want to change an object by opening the repository and editing its
details in that local context. The question is – what happens to drawings that
contain the object you have changed?
Similarly, you want to edit the names of objects in a diagram (not
in a separate window). The question is – what happens to the underlying
repository? And any other drawings that contain those objects?
Don’t treat what follows as a specification of features your tool should
implement as suggested here. The aim of this section is to help you understand
the issues a user-friendly CASE tool has to addresses.
You may want the choice of local or global change to offered as you edit
a diagram.
So when you edit an object name to a new name, a pop-up
asks which option you want.
And when you edit an object name to match an existing object's
name, a pop-up asks which option you want.
If you select a global change or merge, then a pop up might ask you -
save now or later?
You want to change repository entries and diagrams locally, without
worrying about the wider effects of your change until you explicitly choose to
save your changes.
You want the CASE tool to cache all changes you make until the
moment you choose to save those changes.
At which point, you want the CASE tool to offer you the choice of global
change or local-only change.
You must accept the tool may reject some global changes – for various
reasons – leaving you to decide what to do about that.
You should be prevented from changing diagrams you have no authority to
change - by updating objects they contain.
Before saving a change, you want to see the list of diagrams that will
be affected by that change.
You might want to select those diagrams that you do NOT want to be
changed – meaning that the prior version of your changed object persists in
those.
Again, your
repository must support every kind of change at every level of change
management. A migration path from baseline to target is a sequence successive versions
of a single configuration. Most of the objects and structures are preserved
from one architecture state to the next. You don’t want to have to populate and
maintain each state separately. You want to maintain the coherence of an
architecture description through successive states, stages or versions.
Does your CASE
tool support migration planning? Can you define a migration path – meaning that
each object and relationship has a life time from stage/version x to
stage/version y - and appears only in drawings of those
stages and the stages between? Can you give a relationship a life time
from version X to version Y of an architecture? So, a change to that
relationship (or the object at either end of it) automatically appears in views
drawn from any of version X, version Y and all the versions in between? I know
only one tool that does this.
You want a flexible repository, you want a readily user-modifiable meta
model.
In short: building and maintaining an enterprise-wide architecture
repository is a lot more challenging than the tool vendors tell you.
Ref.1. “Abstraction in all its variety”
Ref.2. “Change management challenges”
These
and other papers at http://avancier.co.uk
Footnote:
Creative Commons Attribution-No Derivative Works Licence 2.0
Attribution:
You may copy, distribute and display this copyrighted work only if you clearly
credit “Avancier Limited: http://avancier.co.uk”
before the start and include this footnote at the end.
No
Derivative Works: You may copy, distribute, display only complete and verbatim
copies of this page, not derivative works based upon it.
For
more information about the licence, see http://creativecommons.org