Model driven analysis – a way to work smarter

Imagine you are the CEO of a major organisation and you are faced with trying to understand the impact of imminent new legislation on your processes, people and technology.

You need to understand the cost and time of implementing these necessary (albeit forced) changes throughout your entire enterprise. To accommodate the new legislation you cannot afford mere thumb-suck estimates. Having a complete understanding of how all processes, business rules requirements and systems relate to each other would be of immense value in helping make these decisions. If only you had a tool to help you with this…

What if a mechanism does in fact exist to help us understand the impact of changes like these in a more quantifiable way?

Read on!

One of the reasons why spiders are such prolific hunters, are that they utilise an incredibly effective hunting framework…
a web. This amazingly strong structure, allows them to know immediately when potential prey touches any part of it and if the prey becomes entangled enough…well, then dinner is served. The interconnectedness of the web, is what makes for the effectivity of alerting the spider to any possible action. The spider web acts as a kind of alarm system.

I can’t help to wonder if the early creators of the use of models to describe businesses, systems and architecture, did not have spider webs at the back of their minds when they started out.

The Unified Modeling Language (UML) was started in the late 1990s to provide a standard way to visualize the design of a system .

Prior to UML, object oriented system pioneers used the Object Modeling Technique (OMT) as part of their approach for software development. They used this for :

• testing physical entities before building them (simulation),
• communication with customers,
• visualization (alternative presentation of information) and
• reducing complexity.

We all know that ‘a picture is worth a thousand words’ and most of us have experienced the power of using pictures to clarify and to communicate. (Read: https://www.batimes.com/articles/picture-it-get-to-mutual-understanding-and-agreement-faster.html )

If we expand on the premise of using pictures (diagrams) to ‘model’ our business environments, we can potentially benefit in the following ways:

• Re-use:
  You model a process once and you keep it maintained. This way, whenever anyone wants to know how a certain process works, which roles (people) are involved in it, which business rules are linked to it or what system realises the process, it is readily available. No starting from scratch to figure out how it works. It is a living, breathing model – not a document at the bottom of a dusty filing cabinet.
• Central, single version of the truth
  Every single future project that touches an area of the business that has already been modelled, needs not be re-modelled again, since the most up-to-date version of the truth, is available to anyone (whether required for training, generating operating procedures or even for generation of job descriptions).
• Traceability
  How often has your organisation made changes to a business process or to a system where this caused some unintended consequences or even breakages in other areas or systems? How much pain, time and money did these unfortunate changes cost your organisation, in repairs and remediation?
  If you model all the various elements of your enterprise and you link them all up properly, you will know exactly what affects what else. This traceability throughout all elements of the various components of the landscape provides an invaluable tool to understand in advance how changes will impact other areas. If you were to use a proper modeling tool, you will be able to easily generate traceability matrices from your model.
• No loss of IP
  Ever had to run all over your organisation to find the right people who know how a certain process works? Ever had to figure out which of your colleagues’ version of the truth is the correct one? Ever squirmed when you heard that ‘the go-to guy’ has suddenly resigned and is leaving to go to your competitor and you know that there is no way to download all the knowledge to his successor before he departs?
  If you were to model your landscape, you are effectively transferring the Intellectual Property out of the heads of people and into the modeling repository. 
• Applying best practice modeling patterns
  Ever wonder if you could not apply best practice patterns to your business environment? What if you could compare and replace elements very quickly and simply, by applying a best practice patters into your models? With a modeling environment you can. First in the model (for testing and impact analysis) and then in reality.
• Improved decision making 
  Coming back to the first paragraph of this article, what if you could know (certainly a lot more accurately than by mere questimates) how much a potential change will cost and which elements of your business will be affected?
  With a model-driven business analysis environment, you can achieve this. This will provide you with a much more educated decision making framework. This model-driven environment, will provide you with a mechanism to architecturally design and monitor your entire business enterprise, from a requirements perspective.

---

---

So besides all of these seemingly wonderful benefits of using models, most organisations generally fail to use models in adequate and consistent ways as an integral part of our daily analysis and product development routines.

Why is this?

Possible barriers to entry for adopting model driven analysis, are:

• Lack of enterprise wide managerial buy-in. To build an enterprise model driven analysis environment, requires tools, training, maintenance and resources with a certain skillset to make it all work. All of these cost money and takes time. So without the appropriate senior managerial buy-in, the concept will never fly.
• The need for all modellers to learn and use the same modeling language . This is actually more of a benefit than anything else. Sure organisations will need to get all modellers to learn and apply the same skill, but this is no different from getting them to understand their organisational culture, products and services, operating procedures, etc. So no real, substantial excuse there. Personally I would recommend the use of a modeling language that allows you to model all elements of your business landscape (I.e. process, information (flow, relationships, states), people, rules and requirements). One such a language is UML. Once all your modellers follow the basic rules and principles of the UML, using a modeling tool that governs then syntax, you are set. And NO, it really is not too complicated to learn! Any business analyst worth their salt, should model. Decide and settle on a set of modeling artefacts to be used in your modeling approach and once they meet your needs, stick to them.
• Maturity and constant maintenance of business models. Once you embark on this road, your model becomes your single source of truth. It therefore requires constant maintenance. As & when the business rules, requirements, processes, etc. change, so must the models. Organisations often lack the commitment to keep these models updated, most noticeably because they do not assign competent and dedicated staff members to these tasks. In pure Human Resources lingo, the Key performance indicators and balanced scorecards, would ideally need to represent these tasks as key to such resources’’ deliverables.
• Software costs. Let’s be frank, if you’re going to do it, do it right. To do it right, you’ll require the right tools and this will cost you money. Buying the right modeling tools and using them effectively will save you much more money (many times over) than the cost of the licenses. That does not mean organisations have to go with the most expensive options.
  Increasingly more and more affordable modeling tools, with centralised access- & version controlled repositories and semantic modeling language validation functionality are becoming available at very affordable rates. Go and find a modeling tool that fits your budget.
• Establishing a comprehensive meta-model
  Imagine everyone just performs modeling based on their own ‘pictures’ in their minds. This would cause a nice lot of chaos. So before everyone runs off in their own direction, it is imperative that your organisation decides on a meta-model, that will govern how all your modellers will model. This meta-model will serve as a map to guide all your modellers. If all modellers model according to the meta-model, approaches will be similar and consistent and any subsequent reporting will be extractable in a uniform manner.
• Enforcing quality assurance. If all your analysis are going to play in the same ‘sandpit’ there will need to be some rules…
  Obviously these rules should not be so prohibitive that they impede on your ability to deliver or make progress, but once you’ve agreed to what the rules (for instance the modeling rules, structure, ownership of objects, etc.) is going to be, it might be worth your while to invest in a dedicated QA person to vet the models as they get delivered. This QA person could also be responsible for managing ownership of various models or entities within the repository, back-ups, version history of models and adherence to modeling standards. The last thing you want is people inadvertently deleting or messing with another person’s model, without valid reason. 

In conclusion then, maybe you should relook the notion of implementing a model-driven analysis environment inside your organisation. Done correctly, it could save you lots & lots of money and significantly reduce your risk during decision time!
It would be great to hear your thoughts on this topic! Please feel free to participate in this conversation by adding your comments below.

References
https://en.wikipedia.org/wiki/Unified_Modeling_Language
https://en.wikipedia.org/wiki/Object-modeling_technique
https://www.infoq.com/articles/8-reasons-why-MDE-fails