Developing UML standards is an important first
step in achieving consistency and efficiency in an enterprise.
Consistent modelling means consistent understanding between the
modellers and their audience. Consistent modelling practices also
make for easy movement of resources between teams without extended
learning curves. Some of the lessons Xpdian has learned in
developing standards are:
Lesson 1. Decide what standards must be
developed.
Different groups within the organization will use
different parts of the UML to model a part of the enterprise
architecture. The following standards need to be explored (as a
minimum) for use in enterprise architecture:
-
-
Meta
models - The meta-models are probably the most important models,
and yet the least documented. They describe the structures and
rules around the standards and constructs in the models. It
prescribes certain rules about how modelling should take place and
identifies reusable patterns in both the business and systems
environments. Modelling standards developed for the organization
should be modelled and tested against a meta-model first before it
is deployed as a standard.
-
Business
models - These are models that are created by business analysts and
focuses on the business operation. They are often on a higher level
of abstraction and focus more on what is accomplished in the
business. This includes both business and systems activities
although systems activities are only modelled as far as it impacts
on the business environment. The functioning of the systems are
normally described in the analysis models and then mapped to the
business models in order to establish trace
ability.
-
Analysis
models - The analysis models contain systems descriptions as
perceived and defined by the primary users of the system. They are
normally closely linked to the business models and are modelled
using business concepts and terminology.
-
Design
models - the design models includes systems models that are
specific to the physical implementation of the system. They are
described using systems and technology specific terminology and
would specify technical components and rules to be
implemented.
Depending on the different types of software
engineered in the enterprise, different standards may need to be
defined for each type. For example: embedded software systems
standards will be different to run of the mill transaction
processing systems; standards for a COTS based environment will be
different from a pure software engineering
environment.
The approach for all types of software engineering
and system implementation could follow a similar approach to the
one described in this case study.
Lesson 2. Involve the right people.
The development of your standards can be given a
head start by involving people that are passionate about and
committed to learning. Adoption of new knowledge in an enterprise
depends on people seeking it out, experimenting with it, learning
through use, and then expanding that learning trough further
research into the UML.
Another consideration is to include into the team
people that are well respected in the enterprise and who may act as
active change agents. Typically you would be looking for energetic
enthusiastic people that are self driven and can grasp concepts
quickly. They should typically be influencers, who can convince
others of the benefits of the UML standards and the necessity of
adopting it.
Lesson 3. Develop UML champions.
Successful and widespread adoption of the UML in
the enterprise is dependent on having enough champions and mentors
to assist the modelling community when they are introduced to the
concepts. As with almost anything else, people tend to adopt new
technologies more readily when the adoption cycle is relatively
painless.
The team of UML champions should be developed from
the first day of the UML project, or very soon after. They do not
have to have 100% mastery of the UML by the time the modelling
community is taught the UML, but they need to know enough to give
first line support. Their major role should be to assist the
modelling community with simple UML problems, modelling tool
problems and generally be a shoulder to cry on.
The UML champions will be, by being the first line
support, a good feedback mechanism. Their feedback will enable the
project team to understand, what problems are experienced, what
skills gaps need to be addressed, how the UML standards may be
refined and what pockets of modellers need closer support and
assistance.
Second line support may initially be provided by
external consultants and over time as their skills develop by the
UML champions themselves.
Lesson 4. Develop formal standards
documents
When implementing the UML, nothing is more
important than presenting all modellers with a formal standards
document. The purpose of the standards document is
twofold:
Firstly, it should serve as a training manual.
This means that all of the diagrams and notation should be
described well enough as to be self explanatory. It should contain
good examples applicable to the industry of the enterprise so that
modellers can relate to the examples when being taught the
concepts.
Secondly, it must be the guideline according to
which modellers can create their own models. It must be
comprehensive enough to guide without being too
prescriptive.
Note. Sometimes you may wish to enforce certain
ways of modelling. When designing standards, or parts of standards,
designed to constrain, or restrict, it should be because of good
business or modelling reasons. Restrictive standards almost always
lead to artificial models that restrict
implementation.
Lesson 5. Develop formal standards
training.
Key to the success of an UML implementation is
good standards. Good standards are implemented by exhaustive
training. Over the shoulder training of the standards are not good
enough. Modellers need to be trained formally in a classroom
environment, where the quality of education can be consistent and
measurable.
Formal training is almost always better received
and depending on the level of personal measurement may be worked
into the formal resource evaluation metrics.
By having formal courses, new modellers or staff
transferred from elsewhere in the enterprise, may be assimilated
quickly into the modelling community. Formal courses also form the
basis of a solid and predictable education
path.
Over and above the initial standards training,
refresher courses are necessary to reinforce the UML standards and
to update the concepts as it evolves over time. Refresher courses
should be run after major reviews of the standards, or at least
annually should major revisions not occur.
Lesson 6. Develop lots of examples.
Good UML standards form the foundation of UML
understanding in the enterprise. To reinforce this foundation the
UML forum and the UML champions need to develop plenty of examples
outside of the standards as references for more elaborate
models.
Examples may include full project modelling life
cycles, trace ability between different levels, or dimensions, of
models and examples of atypical models that move outside of the UML
standards. Atypical models need to be accompanied by descriptions
of why it was necessary to deviate from the
standards.
Lesson 7. Review the standards
constantly
To ensure that the UML standards stay current and
appropriate it is imperative that a process of review, assessment
and continuous improvement are implemented. A typical UML standards
life will begin with a basis that is constantly reviewed and
updated. As it matures and start to fit into the needs of the
enterprise these review cycles may become less
frequent.
The lower frequency of review does not mean that
review should stop completely. It is important to keep the UML
forum alive and have formal review meetings at least quarterly.
Over time as business and its practices change there will be leaps
and bounds of evolution. If the forum is removed these changes may
not be dealt with in a pro-active manner when they
occur.
