Why do you
need an architecture repository?
This page is published under the terms of the licence summarized in the footnote.
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).
Contents
Why do you
need an architecture repository?
Three thing
to bear in mind about repository maintenance
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.
First, if the repository is not internally cohesive and coherent, people will distrust it.
Second, you’ll need to understand the relationships in the repository meta model.
And practice, you won’t manage to capture all the architecturally significant entities and relationships in one repository.
Solution architects often
document architecture descriptions in diagrams and documents, and that can be
enough for small and/or short-term projects.
They can use Power Point or
Visio to draw the diagrams.
And use spreadsheets or MS
Access to maintain the repository of system elements.
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;
the architecture is in the repository
The 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.
Ideally, you can identify one CASE tool repository as being your central architecture repository.
But in practice, what is documented about enterprise systems usually spans several physical repositories.
Where does your enterprise record its business goals, its balanced score card, and financial data relating to assets or projects?
For example, a US federal government department has to answer queries regarding its investments.
Some do this using templates and functions available in specialized project/investment management tools such as Clarity and Prosight.
“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.
Each division stores 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.
In short, people use:
· CASE tools to maintain diagrams and system element definitions used in architecture descriptions.
· Knowledge management/portal tools to store architecture deliverable documents
· Other tools to maintain more management-oriented information.
Linking between repositories presents configuration management challenges.
It is important that your central repository supports every kind of change at every level of change management.
See the related paper for discussion of this.
Copyright conditions
Creative Commons Attribution-No Derivative Works Licence
2.0 10/06/2015 19:26
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