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.
