Harvest
Why harvest? Benefits & methods
Harvesting 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.
Harvesting has two important benefits:
- Other people can see that their knowledge is being used in the model. So they can see things in the model which they recognise, and know to be true. This gives them more confidence that they can trust the new modelling work.
- The modelling team have less to invent. So if, for example, you already have some useful-looking security requirements from a previous project, harvest them, and just modify them for the next project.
So harvesting is a great way to start modelling.
When you know what the deliverables from the model are going to be (see Deliver), it should be easy to identify what kinds of knowledge already exist which can help you deliver them. Don’t be tempted to harvest information which ‘might come in useful’. It might, but it might not. Wait until there is a project which really needs the information, then let them harvest it.
Hard and Soft knowledge
When we talk about harvesting, we’re talking about harvesting ‘hard’ knowledge: information which already exists in some importable format. We’re not talking about soft, still-in-the-head knowledge. Both are useful, but the ‘harvest’ part of Model Driven Delivery is looking for quick wins with minimal effort. So leave the soft knowledge where it is.
For the moment.
People
All kinds of people might know where harvestable knowledge can be found. Ask previous and current project teams, analysts and architects, project managers and stakeholders. Ask everyone.
And don’t just look inside your organisation. There may be industry standards, or government regulations & laws which can be really useful for your project to reference: find out who knows where these are, and whether they might be useful.
Benefits / Outcomes
The main benefits of harvesting are obvious – less work re-inventing existing knowledge. But remember that harvesting isn’t a 1-time process: to be a reliable source of knowledge, you need to have a plan to keep it up-to-date.
Activities
- Look at the project/model deliverables, and see what might be harvestable
- Investigate possible sources: how hard are they going to be to harvest, set against the benefits they might bring? How volatile is the knowledge? Are you going to have to spend lots of time updating the harvested knowledge, due to someone else changing it?
- Look also for “Opportunistic sources”. This is knowledge which might not be really clearly useful, but is so easy to harvest that its intangible value – a model full of useful-looking stuff – outweighs the cost of harvesting
- Update your initial meta-model, showing where the harvested knowledge fits in to the meta-model you already created in the ‘Deliver’ stage.
It seems more useful to keep the harvested knowledge separate from the stuff you’re going to invent, and reference the one from the other. That way, you can update the harvested knowledge without messing-up the rest of your modelling. - Setup a process for updating the harvested knowledge, if required. Highly volatile knowledge is going to cost you more to maintain than static knowledge, so make sure to factor this in before you rush off and harvest it. Some teams have a rule which says that if there is no process to keep harvested knowledge up-to-date, then it shouldn’t be harvested in the first place. Probably a good practice.
- Test it. The mechanics of harvesting are usually straightforward, where the data is 100% consistent. It’s the exceptions which take the time, so decide whether you need 100% accuracy of the imported knowledge before spending days and weeks pulling-in every last byte.
If you need help harvesting multiple sources of existing data, just ask. Our experts have plenty of experience and some time saving tools to populate your model with useful information, fast.
