View source for BestPractices:Reality and the theoretical best model

<message>Write the content here to display this box</message>
== Reality ==
First, you have the reality – then you have the theoretical best model of that reality (TBM). It is the best approximation of that reality.

It may be impossible or undesirable to reach TBM if the subject reality changes over time or has complexities for which we do not want to prioritize a solution.

TBM is what you aim for when implementing business support systems for a specific reality or domain.

== Business Competition ==
The reality a business domain perceives is seldom the same amongst competing business domains. Even if they are almost similar, the competing domains will likely try to find ways to specialize to gain a competitive advantage. This is what ultimately drives change in competing businesses. It drives evolution and progress, as well, in those businesses.

== Standard Systems ==
It is common to implement a business support system based on a standard model. In that event, the development work is to translate that standard model to TBM. This translation will define the requirements needed by the people twho tune the standard system – implementing the standard model – converting the subject reality into a TBM.

This approach gives three artifacts to maintain: (1) TBM, (2) the chosen standard model, and (3) the translation between the two. Two of these artifacts are unique to the customer and domain at hand – TBM and the translation. The third artifact is owned by the supplier of the standard system.

== Things Change ==
As reality changes, we must update TBM to minimize the introduced deviance between the two. As we adjust TBM, the deviation between reality and TBM is minimized – but the deviation between TBM and the standard model increases and likely invalidates the translation done for the previous version of the TBM and the standard model. The invalidated translation layer must thus be updated as a consequence. Hopefully, the translation layer can absorb the differences but if it cannot, the model of the standard system must be updated. This is however most likely a bigger task since it involves changing a third party’s artifact – the model of the standard system.

== Standard System Updates ==
It is also common that the standard model – that defines the standard system chosen – is updated as part of the normal maintenance process of such a system. When this happens, the translation between the TBM and standard model must be updated – this time not due to a changing reality of the domain, but rather a change in the standard system supporting the domain. Nevertheless, the effect is that the translation layer is invalidated and some action must be taken to align the three artifacts.

== Standard System Implementation Considerations ==
Implementations of information support systems that do not find and maintain the TBM first – but instead try to make the model of the standard system the new reality for the organization are much cheaper to deliver. But if the reality of the domain is central to the earning abilities of the domain – or in other words, if it constitutes the domain's core business – the chances are that the forced shift of reality impedes the domain work rather than supports it. Forcing a business domain into a generic reality will not promote execution above any competing business that has chosen the same approach. This will limit the domain's ability to compete and evolve.

Since the reality is now controlled by the supplier of the standard system, it is effectively an abdication by the domain's leadership. Even if it is a quick and low-cost implementation, the ability to control and mold the reality is lost; since that must be considered one of the main tasks for the leadership, it cannot be considered a best practice alternative.

When the processes supported by the system are not the core processes of the business, this may however be desirable since it would save resources on noncore processes, leaving a choice to invest this overage in more important core processes and thus enabling strife for more excellence in these areas.

== Theoretical Best Model ==
TBM will constitute all functional demands on the desired support system and as such TBM must be in place before finding candidates for implementation of the new business support system.

The tools used to manage and evolve TBM are an important choice on their own. The description of TBM should ideally be based on open standards and keep the resulting definition clear to avoid the need for guesswork and interpretation from the readers.

TBM is often constructed by an architect function within the company.

It is also desirable that TBM can be verified and reviewed by the high-level business functions that ultimately will use the business support system.

== Accepting and Dealing With Imperfections ==
TBM will change over time – this is just as sure as the fact that any surviving company evolves and changes over time.

In an optimal environment, the error between reality and TBM, the deviation between TBM and the translation, and the deviation between the translation and standard model are all kept to zero. However, this is unlikely to be the case for long periods of time. This means that an organization will live with artifact errors from time to time. These errors must be accepted to a large extent but it is important for the leadership to strive to minimize the errors.

If the error is left unmanaged and without a plan of reduction, it will most likely impede the domain's ability to refine and evolve the reality further or improve as we may call it, leaving the business vulnerable to competing businesses that do not suffer from equally large model errors.

== Projections into the Future ==
It is likely that as the information-handling abilities held by humans improve, we will find ways to do things differently. Information handling and competition between information handling companies will only increase as we move into the future.

Businesses are able to constantly update their reality and matching TBM will be more successful than the ones that must keep the status quo or live with large errors between reality and TBM or with large errors between a TBM and support systems.

What constitutes business development is the ability to describe the reality in a TBM. Once we have a TBM, the other steps only involve technical transformation, and no analysis or interpretation needs to be performed since it is all defined in a TBM.

In fact – once we have a TBM and a set of best practices and problem-solving patterns on how to create the technical things that build up a software system, the whole process can be automated in theory.

== Waiting for the AI ==
There is no need for any artificial intelligence once we have TBM and want to move to an implemented system – it will all be classical engineering. You have a drawing in the form of a TBM and you transform that drawing into a running system – with manual labor or with a machine that does the labor.

If you do have access to AI, then the AI can be used to find TBM, or perform all the work in the domain. You would however still want to have access to a human-readable TBM so that you can argue with confidence that you actually know what your business domain does. If the domain is subject to inspections and regulations and must adhere to laws and standards, it will probably not suffice to say that you use AI and hope for no questions. Regulators will want to see that you have a good understanding of what your domain does.

How TBM was created will be of little interest as long as it makes sense to a human reader. And yes – maybe even the regulators will be AI – but that will most likely come further down the line. We will see human-based regulators for the foreseeable future who must be humored and respected and we must give them facts from our TBM.

== Reducing Waste and Applying Automation ==
What we have learned so far is that the real value is in TBM. It acts as the artifact that describes what the business does. It described this in a format interpretable by humans and also by machines.

If we focus on reality and TBM alone, we can get all the work focused on the things that are important for the business – supporting the business reality as closely as possible.

The future will likely move us in the direction of automatically implementing business support systems based on TBM alone – we at MDriven already do exactly that.

Once we have reached the point when we have a business support system that does not have a model of its own but instead completely adopts TBM, we do not only remove the need for a translation layer – we also get a perfect match from the system to reality.

== The MDriven Strategy ==
We have spent a considerable amount of time researching what TBM must contain to be fully descriptive for a machine that would implement all the software needed to realize the system that fulfills TBM.

We have based our TBM strategies on open standards like UML and OCL from OMG.

Applying our strategies today will drastically increase the speed with which you can minimize errors between reality and TBM.

Our strategies remove manually crafted translations layers and externally licensed standard models. As the strategies we offer do not rely on manual labor, we have increased the quality of the produced software and reduced the need for time-consuming testing and bug fixing.

The way we offer you to build business support systems leads to a better documented, easier maintained, and cheaper system, with high-level descriptions you can inspect and review that, will work as the foundation for the whole understanding of what it is your business domain does.

With our MDriven strategy, you will follow reality more closely than before, be able to articulate exactly what you have so far, and follow along with forced and/or desired change. You will be able to drive business change through insights gained from the work with the TBM.

You will use more technology but at the same time be less dependent on a particular implementation strategy that is best practice today but old within three years – since our patterns and implementations are not limited to only one technology.

We have verified all this in real-life scenarios – giving organizations a process for continuous refinement of their TBM and as a result, having a perpetually refined business support system. The main goal in such a setup is to reduce the error between a shifting reality and the TBM on a monthly basis – and never stop. Since change happens all the time – a continuous adaption of the TBM is best to avoid letting errors build up and slow business down.

When we build the TBM in a machine-readable format and construct a machine that executes the TBM, we gain the ability to quickly execute the TBM and by doing so, get the domain users involved in verifying that the TBM is close enough to reality – greatly simplifying system usage adoption.

== Seeing Around Corners ==
We predict that this strategy will be the prevailing one as we move into the future. It is easy to theoretically verify this prediction as credible since we know that TBM should exist before choosing a standard system – and we know that a good TBM must fully express the requirements.

This leads to the conclusion that TBM must exist and is enough. It is wasteful to ignore its potential and instead create and maintain other artifacts like standard models and translations. Organizations that waste are in time replaced by organizations that are not wasteful.

We think that this angle we have taken on software development and research is very rewarding for all who engage in it. We see big improvements in user satisfaction, system understanding, system adaption, work output quality, and self-service for information. We see great improvements in software quality, faster delivery, and the ability to model - without effort - very complex and detailed realities.

== The Competition for Providing IT Support Systems ==
We foresee great competition in this particular field of software development. The gains are great and the drawbacks are small or non-existent. However, we have not yet seen anyone else doing what we suggest. There are many players but they seem heavily invested in manual labor routines – and they appear reluctant to give up on their legacy strategies just yet.

The problem is that many domains are given uninformed advice from big players in the field. This is a pity since it gives a smell of immaturity to the whole industry – an industry we are part of. It would be better for all if a few more could move on into the future faster than what we see now. 

The lack of competition is currently a problem for us – what we say would be more credible if we were not so alone. Where are you? The time is here. 

Until then – welcome into the future by contacting us – if you share the thoughts above, you will absolutely love what we do with MDriven. The future will come – welcome it!

No, you will not read about us in Gartner reports; we are pre-Gartner – once there, they will need a new type of quadrant. 
[[Category:Architecture]]
[[Category:TOC]]