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 that a business domain perceives is seldom the same amongst competing business domains. Even If they are almost the same it is likely that the competing domains will try to find ways to specialize in order to gain 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 that 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 for 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 the 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 to change 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 to align the three artifacts must be taken.
Standard system implementation considerations
Implementations of information support systems that do not find and maintain the TBM first – but instead tries to make the model of the standard system the new reality for the organization is 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 domains core business – the chances are that the forced shift of reality actually impede the domain work rather than support 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 domains ability to compete and evolve.
Since the reality now is controlled by the supplier of the standard system it is effectively an abdication by the domains leadership. Even if it is a quick and low cost implementation the ability to control and mold the reality is lost and 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 is 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 process 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 its 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 evolve and change 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. This is however unlikely to be the case for any longer 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 for its reduction it will most likely imped on the domains ability to refine and evolve the reality further or improve as we may call it. Leaving the business vulnerable for 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 able to constantly update their reality and matching TBM will be more successful than the ones that must keep status quo or live with large errors between reality and TBM or with large errors between a TBM and support systems.
What really 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 need to be performed since it is all defined in 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 in theory be automated.
Waiting for the AI
There is no need for any artificial intelligence once we have TBM and we 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 actually 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 just say that you use AI and hope for no questions. Regulators will want to see that you have a good understanding on 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 and they 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 get can get all the work focused on the things that actually are important for the business – supporting the business reality as close as possible.
It is likely that the future will move us in the direction to automatically implement business support systems based on TBM alone – we at CapableObjects already do exactly that with MDriven.
Once we have reached the point when we have a business support system that do 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 system to reality.
The MDriven strategy
We at CapableObjects have spent a considerable amount of time researching what TBM must contain in order 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 that you can inspect and review and 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 be able to follow along with forced and/or desired change. You will be able to drive business change by 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 continuously refinement of their TBM and as a result have a continuously 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 to build up and slow business down.
When we build the TBM in a machine readable format and construct a machine that execute the TBM we get the ability to quickly execute the TBM and by doing so getting 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 exists prior to 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 that TBM is enough. It is wasteful to not use its potential and instead create and maintain other artifacts like standard models and translations. Organizations that waste are in time replaced by organizations that do not waste.
We think that this angle we have taken on software development and research is very rewarding for all that 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 ability to without effort model even 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 small or non-existent. However yet we have not seen anyone else that does what we suggest. There are many players but they seem heavily invested in manual labor routines – and they may not want 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 if immaturity to the whole industry – an industry that 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.