Ten
architecture repository challenges
This page is
published under the terms of the licence summarized in the footnote.
How
to manage the structure and behaviour of business systems if you don’t know
that structure or behaviour?
How
to plan changes that are optimal for the enterprise (rather than suboptimal and
localized) if you have no enterprise-wide repository of the system estate?
On
the other hand, why is building and maintaining an enterprise-wide architecture
repository more challenging than CASE tool vendors tell you?
(CASE
= Computer-Aided System Engineering).
The value of an architecture repository is discussed in other papers, along with some advice.
It is one thing to populate an architecture repository for a discrete solution architecture or migration planning exercise.
It is a very different thing to maintain an EA-wide repository of the kind envisaged by so many gurus since the 1980s.
I
have added some experiences and some comments from Roy Roebuck, Director, One
World Information System, http://www.one-world-is.com
Contents
Challenge 1:
long-term purpose/use
Challenge 2:
meta model and maintenance of it
Challenge 3:
choice of repository technology
Challenge 4:
sizing the repository
Challenge 6:
integration with other repositories
Challenge 9:
getting the level of abstraction right
Challenge
10: change management
Solution
architects may create a solution architecture repository for the purpose of
supporting one solution, perhaps
presented only once to win some
business.
Management
consultants may build a repository to help them understand the current business
and technical environment.
Or
to present plans to rationalize the business structure or application
portfolio, or technology portfolio.
Or
to present plans for a major migration from on structure to another.
Which
is all 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.
Enterprise
architects may create an architecture repository that spans many distinct solutions and is
maintained forever.
This
is an enormous challenge, not to be underestimated.
There
is considerable anecdotal evidence of enterprise architecture repositories that
have come to be regarded as academic.
This
paper presents the challenges that must be overcome if an architecture
repository is to be persistent and enterprise-wide.
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.
Related
papers contains notes on what a CASE tool should do for you.
Roy
says: I recommend those that are designed for ontology and knowledge-base
modeling and management, not the MOF or CASE-based EA tools.
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 data 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.
The
"axle", the metaschema for this integration exists in my enterprise
management and included enterprise architecture (EM/EA) approach.
The "hub" technology exists in the
form of a variety of ontology and knowledge-base products, and to a lesser
degree in extended metadata repository (XMDR.org) and OMG-MOF compliant
repository products.
The "integration band" technology
exists in the the form of ETL tools, ESB tools, Data Integration tools,
Semantic Analysis and Transformation tools (i.e., intelligent ETL).
The
"spokes" mostly now have XML, SQL,CSV, or API-based I/O interfaces.
The
"wheel segments" at the end of each "spoke" exist as the
collection of information systems supporting the organization's enterprise.
The "wheel" as a whole represents
the production and security boundaries of the organization's enterprise.
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.
It is far from
clear that different users want your repository to be at the same level of
abstraction, or that data from different spoke repositories can be abstracted
to the same level.
Too abstract by omission of detail?
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 US.
The
enterprise data model I was supposed to work with was a handful of base generic
entities like Party, Partnership, Place, Product, Process, connected by generic
many-to-many relationships.
Every
other entity type was plugged into the structure as a subtype in a class
hierarchy under one or other of the generic supertypes.
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.
A
repository must support every kind of change at every level of change
management.
This
is a complex matter. See the paper “Little discussed CASE tool selection
criteria” for discussion.
Copyright conditions
Creative Commons Attribution-No Derivative Works Licence
2.0 10/06/2015 22:02
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.website” 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