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. Xpdian’s UML modelling tool of choice is Enterprise Architect.

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.

 

For more information please contact us.