Accelerating your Success
With Model Driven Delivery
With more than a decade of experience of delivering EA-based solutions, we use an approach we call ‘Model Driven Delivery’, which is a systematic way to explain all the ways we might help you. Talk to us to find out working together we can accelerate the success of your team.
Model Driven Delivery - where it all started
At a conference a few years ago, we got into a conversation with an IT Architect from a large, well-known European multi-national company. He’d already decided that his new team needed a better way to capture and manage business knowledge, and had concluded that they needed a ‘single version of the truth’ model where all that important knowledge would live. His question to us was simple: “OK – where do I start?”. Should it be to buy a tool, or pick a method(ology) or choose a modelling language?
Another attendee at the conference overheard this conversation, and said “No, none of those. First you need to decide on your meta-model”. The IT Architect looked puzzled. Meta-what?
Finally, a passing Project Manager set us all straight.
First, tell me how all this modelling and single-version-of-the-truth stuff will help the project go faster, or cheaper, or better, or all of the above.
This conversation got us thinking about all the customers we’d helped over the last 15 years. We’ve helped them to use and exploit models in all kinds of ways, and we decided that all of these ideas had a place in a possible “where to start” solution. But how to explain all these alternatives to a new modeller? As we looked back at our previous projects, we identified the critical factors for teams who had been successful in their use of models. What worked, what didn’t work.
And we summarised all that experience in this thing we’ve called “Model Driven Delivery” (MDD) Because giving a name to an idea makes that idea easier to talk about.
Since we first wrote down the idea, we’ve shared it with other clients, and we have found that MDD is a useful way of
- Finding out how knowledge in a model can help a business
- Thinking about how that knowledge can get into, and live in a model,
- Setting an agenda of ‘what to do first’ and what to do next
- Figuring out what tools and techniques are useful to make this happen
We have tried to keep away from as much of current IT-consultant-speak as possible. This is essentially a simple idea and so should have a simple explanation.
So it has just four parts:
Harvest – Pull together knowledge which already exists and add it into your model. Once your model contains known useful stuff, then new model users can see things they recognise and start to trust it.
Model – Use the power of shared, rich models to spot the gaps, overlaps and inconsistencies in what’s happening. Look at possible futures and evaluate them.
Engage – Models can create the opportunity to engage with stakeholders in new ways, to get them to contribute their knowledge, and participate in the solution. But there’s more to it than ‘let them see the model’ or ‘send them a document’.
Deliver – Models help you drive a project or business forward, by producing higher quality deliverables faster. Because this is the objective of all of the items above, this is where we will start.
Deliver
As the process is called Model Driven Delivery, then it makes sense to think about the deliverables first, before we think about anything to do with modelling.
The deliverables which your stakeholders are expecting to see will clearly differ massively between projects.
Harvest
Creating models is hard work, made even harder if you have to start with an empty model. But your team, your organisation and your industry already have lots of knowledge, saved in lots of places, which can be a great starting point.
Harvesting that knowledge seems to be a common factor in successful modelling efforts, whether that’s modelling the requirements for a new system, the technical design of a component, or a whole enterprise architecture.
Model
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?
Engage
So you have agreed what your deliverables are, harvested lots of great stuff, and done some wonderful modelling, and generated lots of excellent documents. Job done ?
Not quite.
You may have the best model ever made, and the finest specification document ever created, but if it’s the first thing your stakeholders have seen from you, they might not be impressed.