Home / Model Driven Delivery – Model

Model

It's just modelling, right ?

This might be the part where you feel most comfortable. Or, if you’re new to modelling, where you need to think really hard.

Lots of teams start by creating their own modelling style, sometimes even writing down their own meta-model. But there are LOTS of modelling languages, each of which each have their own Meta-model already defined. So why invent what doesn’t need inventing?

Simplify, don't invent

Much easier to take an existing language, like BPMN for processes, or CMML for case management, and modify that.

Those modifications are almost always to simplify the language.  Remember, these languages have been thought about by smart people over many years to cover a huge range of potential applications. And you just have one application, so you should expect to simplify things to suit what you’re doing. But do this from a position of knowledge – don’t ignore a part of the language because you don’t understand it. Understand it, then decide not to use it.

But PLEASE don’t invent your own process modelling, or case modelling, or anything-modelling language and notation. You’ll never match the job which the experts have already done.

What you MAY need to invent are links between the existing languages. We’ve helped several customers to, for example, link BPMN process ideas with UML ideas of Use Cases and Actors. So don’t feel you’re the first to do this – get some outside help and save your project some time.

People

Modellers. What else to say?

Well, not all modellers are equal. Some are comfortable and experienced in putting their knowledge into a model. Others may have lots of experience, but may find modelling too constraining. They’ll prefer Visio. So plan to train and support your modelling team to get everyone modelling in a simple, efficient style. This is one of the hidden costs of doing modelling.

If you’re planning on modelling with more than around 10-15 people, it’s cost effective to have someone (even a team) who are dedicated to maintaining the model. Keeping it consistent, high-quality, and training up new users. Another hidden cost. (P.S. Ask us about tools to simplify and speed this up)

Benefits / Outcomes

This probably isn’t the place to go over the benefits of using models to store complex business knowledge. So we won’t. But that’s what you’re aiming at: a knowledge store which lots of people can use, over a long time, for purposes which you can probably not yet imagine.

So you’ll need to focus a lot on getting your model consistent: or at least, consistently inconsistent (known areas of difference). A huge, complex model with no consistency is not going to be a Single Version of the Truth: just a single version of confusion.

So not hard then…

Activities

The key to successful modelling, of which we’ve seen both good and bad examples, is to keep it simple. Learn a bit, model a bit, share a bit, create an early deliverable, stop and think, repeat. Any set of activities in this area will, of course, be simplified, but here are a few highlights gathered from bitter experience:

  1. Learn the language. As we said above, don’t think you’re so smart you can invent your own modelling language. Learn about what’s already out there, and take just the bits you need.
  2. Take the meta-model (the recipe of what your model is allowed to contain) and populate it with some useful knowledge. This might be new Requirements, new User Stories, new bits of the enterprise architecture. But keep it small
  3. Share what you’ve done with as many of your stakeholders as possible, before you create too much. Each group will have its own views of what you’re done, so listen to them all.
  4. Try to create your final deliverables. Even if that means a document which is mostly empty, or a web page which is mostly white space. Make sure you’re producing really useful outputs which will help the project. Don’t wait until the end to do this. See the section on Engage before you do this.
  5. Now think about the feedback you’ve received. Are you collecting too much detail, or not enough? Should you discover a bit more information, so that a particular stakeholder group gets more of what they need?
  6. This probably means you’ll have to update your modelling standards and practices, which are summarised in your meta-model. So create a lightweight, collaborative approach to doing this. It’s called Model Governance, and don’t expect anyone outside your modelling team to care about it. But if you don’t start doing a little bit of it early in the project, it gets harder and harder to do later.
  7. Go back to (1) and do the next bit, using your modified approach.

The other elements of Model Driven Delivery:

Deliver  |  Harvest  |  Engage