The successful rollout of the UML and a UML
modelling tool is not simple. It depends heavily on the skills,
attitudes and experience of the practitioners in the
enterprise. The UML is a visual language that allows for many
different interpretations of usage.
Several projects targeted at rolling out the UML
using Enterprise Architect have taught us valuable
lessons:
Lesson 1. Understand that the tool does not equal the
UML.
Tools are valuable in the expression and use of
the UML. Bad experiences with a tool may cause the failure of the
UML as a technique. Before planning training, make sure that you
understand your UML tool and what it can and cannot
do.
If you do not have a UML tool, pick a UML
modelling tool that will suit your requirements and that of your
modellers and their audiences. Often professional consultants may
be able to assist you in selecting the appropriate UML modelling
tool.
Lesson 2. Ensure that practitioners have a similar
understanding of the UML.
When training your employees initially, make use
of the same external, or internal, trainer. Different trainers have
different approaches and interpretations of the UML and how to
apply it.
By using the same trainer, a consistent message is
transferred to the future UML practitioners. Using different
trainers may cause conflicting interpretations which may cause the
UML project to self- destruct.
Lesson 3. Allow for individual learning.
We believe that true learning takes place, not on
the courses, but in the use of that knowledge after the courses.
People should be allowed to experiment with the UML in order to
test their understanding and to match their own skills to the
modelling environment.
Lesson 4. Once skills start to develop in a meaningful way,
put mechanisms in place to ensure that the growth is controlled
towards the enterprise modelling objective.
This may be done by identifying key role players
that have mastered the UML skills to some extent. They should form
the members of a forum to establish and maintain UML
standards.
It is important to note that more than one
standard may have to be defined. Often business modelling will be
approached differently from analysis and design modelling.
Different disciplines may also need different standards. For
example, embedded systems may need different standards to
transaction based application systems and/or data warehouse
systems.
It is a good idea to start off with a single
standard that accommodates adaptation and over time as the UML
fluency develops to split the different disciplines and techniques
into specific standards definitions.
The purpose of standards is to guide UML modelling
and to provide a consistent approach to modelling. In the long term
it provides flexibility regarding the support of systems
consistently defined and modelled. It provides a framework within
which skills transfer may be done efficiently and within which
resources can move around with a minimum of
disruption.
Once defined, the standard has to be maintained
and grown to match the changing needs of the enterprise. The UML
forum is the custodian of the standards.
It is to be expected that the UML forum may
initially have a high level of activity in defining the standard,
but this will taper off as the standard becomes mature. External
consultants may accelerate the process with the introduction of
best practice frameworks that may be used as a basis for a
standard.
Lesson 5. Once defined, the UML standard has to be
promoted and all modellers trained in it.
To promote adoption of a standard some change
management practices may be implemented in order to gauge the
success of adoption and to provide feedback and problem resolution
mechanisms.
Lesson 6. Once modellers are comfortable with the UML
standard and the modelling techniques, the stakeholders, for who
they will model, have to be trained.
The stakeholders do not have to have an in-depth
understanding of how to model, but only have to understand how to
read the diagrams. A good approach to disseminating knowledge among
these stakeholders is to target a small group of stakeholders,
train them, and then monitor the ease of adoption of the new skills
and techniques. This information may then be used to improve the
approach and training of subsequent groups.
Lesson 7. For every UML modelling project a UML mentor must
be appointed to assist the team in modelling system
problems.
The role of the mentor would be to guide the team
and ensure adherence to the standards. It is also beneficial to
establish a QA role to verify model integrity and compliance to
standards. The QA role and Mentor role should not be allocated to
the same person.
Lesson 8. Over time most modellers – if left to
their own devices - will acquire bad habits and tend to deviate
from standards and guidelines.
With this in mind, it is important to have
frequent refresher training to revisit the standards and to update
modellers on changes in the standard.
Lesson 9. The UML is a modelling
technique.
In order to apply it successfully, it needs to be
used in the context of a proper business or software engineering
method. Several methods are available in the market. Most notable
is the Unified Process and its derivatives. These methods are best
practices that allow systems engineers to apply the UML to the
advantage of the enterprise. This topic will be discussed in
more detail in upcoming Lessons from the Field
articles.
