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.
