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