Interview with Andy Barnett (UML expert)

In this article I interviewed Andy Barnett who is a UML mentor and asked him questions about his background, the benefits of UML, when to use it along with BPMN and user stories, challenges with implementing UML and what is involved with being trained in UML.

I know Andy from him being my mentor for around 12 months at a previous company I worked at that implemented UML. I was really pleased that he agreed to a virtual chat for this article to share with you about a global industry recognised standard analysis technique and his career experiences.

So tell us a little about your background and career path?

When I wanted to get into IT I found it incredibly difficult. I wrote about 100 letters to companies expressing my interest. Eventually I struck lucky with British Gas who gave me a trainee COBOL programming position which started off my career in IT. Gained as much experience as I could about programming and then later on analysis. I also went on as many training courses as I could. SSADM was the main methodology at the time. I was at British Gas for 8-9 years. When I left I then became a freelance contractor. To ensure I kept my skills up to date I read lots of books, watched lots of you tube videos and tried them out on projects to look for better ways of doing things. Then in 1999 one of my friends asked whether I had heard about UML. I hadn’t heard of it at the time and asked him what it was. He said it was to do with drawing diagrams. I looked into it but then didn’t use it for a couple of years. Then I took up a contract where the role more heavily involved analysis and I researched what the best tools were out there on the internet. UML was mentioned so I brought some books and studied them. I then gained experience using the UML in early 2000 at the company and ended up becoming the unofficial UML mentor. As soon as I started reading about UML I realised it was a very well thought out process. For me it delivered everything that SSADM didn’t. SSADM gave projects structure but you would then get to the point of what do I do next as it didn’t seem to tie in very well with development and coding whereas UML is end to end. I’ve always been interested in Methods and how they deliver a better product and put me in control of my work, less stress.

What is UML?

It stands for Unified Modelling Language. It’s a notation that is a global international standard in modelling software systems. There is around about 16 different diagrams. Each one has its own particular benefit and reason for doing it. Typically as an analyst you would only use about 6-7 of these diagrams. There are others but they are more geared towards development.

What are the benefits of using it?

Building software is too complex and too costly to wing it, some organisations do and that’s why there are such a high number of failed and over budget projects. BPMN and UML have been specifically designed to address the needs of process mapping, analysis and design. If they are used correctly they will deliver projects on time, deliver what the business needs and leave you with a maintainable documented system.

Over the years I’ve seen the good , bad and ugly in the traditional functional specifications. Some of the common poor traits are repeated requirements, irrelevant requirements, inconsistent requirements, verbose writing, and solution before requirement. All this makes it incredibly difficult for the reader and gives documentation that is often ignored and almost always never maintained, our role as an analyst is to clearly and concisely communicate. Analysts don’t do this on purpose this added complexity is accidental in the absence of a strong standard like BPMN and UML

A traditional functional specification is heavily word based whereas UML is heavily model / diagram based. It’s commonly known that pictures are far better and easier to digest than words.Â Other complex industries involving Architects and electricians all use diagrams to describe things they don’t use words.

So the benefits are :

Great communication because pictures are used instead of words.
As an analyst our job is to capture everything and capture it in a way that the audience can understand what is being captured and to realise the gaps. If gaps are left it can be very costly.

I was given a specification which was about 65 000 words once and I was challenged to turn it into UML. In turning it into UML it went down to 4500 words. It went down from 150 pages to 20 pages. And that is just a typical example and shows the power of diagramming over words.

You offer mentoring in both BPMN and UML. I often get asked about when to use BPMN process modelling, when to use UML and when to use user stories. In your experience could you explain what you believe the differences to be?

There is a place for all 3 on a project.

BPMN which stands for Business process modelling notation is used to define the end to end business process. For one of those activities identified in the business process you may say that you want a computer solution related to that activity and that is where you would drop into UML. UML will enable you to use different diagrams to design a different software design solution for it. They go hand in hand. There is a UML diagram which is similar to the BPMN notation called an activity diagram but BPMN is so much richer in its notation.

User stories are typically used with an agile project. I’m not a great fan of user stories on their own but they can have a place if you use some other documentation as well. User stories are good for capturing a high level view of what the stakeholders are asking for AS A, I Want, So That, When , Then.

So for a project I would draw a BPMN diagram to understand the business process end to end, then I would capture some high level requirements from the business about what they wanted to turn into software solutions which could be user stories and then I could use those user stories to drive down into UML. I could also use the user stories to monitor and prioritise what I did on the project. You aren’t going to be able to use user stories for detailed design. In the type of industries you and I work in such as big corporations, banks, insurance companies etc. tend to involve big complex systems which you couldn’t start building by breaking down into small chunks at a time because the functionality has to fit together. You need up front architectural work to fit the requirements into. That can’t be done with user stories alone.

What are the main challenges with implementing UML?

Number 1 is communicating it to everybody. If you are implementing UML it is not just the analyst that has to be brought up to speed, itâ€™s also who going to consume this information. It is a language so it’s not something you can just walk into and understand without some sort of training. So you have the analysts, the developers, the testers, the project managers, the business. You have to convince people as it is a significant investment to move to UML. Even in a medium size company you are already talking about 100 people. One on one or a small group of people is easier to convince on UML, as the benefits are clear. But when you have to convince that many people it becomes difficult. Change in any organisation is a difficult thing to do.

When you have persuaded people to do it, you have to skill up. The challenges then are training people and then giving them support on the job to actually use UML because it is not one of those things where you can say here is the template go fill it out and be a UML designer or writer. It takes training and experience. It will take 3 months to a year depending upon their back ground to perform well with UML.

Once you have UML in place you need to make it stick. I go into organisations I do UML and I mentor by skilling people up. When I walk out of the door it needs to be kept up after I’ve gone as there is a lot of investment by the organisation. To make it stick you have to put lots of things in place.Â The best way to make it stick is to make it the right choice for people and the easiest path. It’s not an easy job to implement UML.

Which bits of the business would you involve in UML?

I would involve them in use cases but not the more technical side such as sequence diagrams. Because of the way UML is structured there are lots of levels of abstraction. Once you have a use case that is right you have a high level of confidence that ,will filter down into the detailed UML and can keep track of the more detailed requirements but you have to be careful to show the right people the right UML.

Are there any other diagrams that would interest the business?

There are class diagrams which can be used as a high level conceptual diagram that can illustrate the key entities of a company and can be used to get stakeholders to call the same thing the same thing. It’s surprising how many companies have so many different terms with the same meaning.Â This creates confusion. Class diagrams can be used to create clarity. It makes a big difference.

What analysis tools are available for writing UML?

I’ve used IBM products, Microsoft products and Sparx systems. The most important thing is the UML and that the tool supports the UML, it should really lead it. The IBM tools can be expensive. With Microsoft many employees probably already have it on their machines. The drawback is that it is easy to outgrow Visio as it wasn’t built specifically for doing UML. It hasn’t got anything like traceability and structure in there. Then you have Sparx systems which I prefer to use. It’s not too expensive and it’s very functionally rich.

How do you go about mentoring employees and what will employees be able to do after being mentored by you and how will it benefit them and the organisation?

In terms of mentoring I always start off with the training. What I like to do is keep things practical. I do a bit on notation but primarily it is all about practice. Then once, as you know, the way I did at Admin Re was to embed myself in the projects. I work with the people on the project so itâ€™s not just about class rooms itâ€™s more about the real world and using UML in the real world. Then I can face the same challenges as the people I’m mentoring. Over the years there is now very little that surprises me. Everyone seems to face the same sort of challenges. To someone that is new to learning UML, it can feel impossible to solve some of these problems but there are ways for all of this. Once you understand how to solve that problem with UML then it just becomes easy and obvious.Â Other things to keep the momentum going is that I do a weekly tip of the week where I feed in UML or tool tips. One of the things I did after Admin Re when I was working at Christies is realise that once you have started to learn UML is that you might do a use case model once every 3 months, which if you are doing something that infrequent, then each time you start again you most likely have to learn it again. To combat this I introduced a weekly puzzle where I would set a problem with UML, for example draw a use case model for a business that has XYZ. After about 5 weeks I noticed people were drawing use case models to the same standard as I would expect people to be able to produce after a year of doing it. By continually trying puzzles out developed the skills. I started on use case models and moved through to class diagrams and then other types of diagrams.