1 Let’s do a pre-study

It is very common that an organization wish to understand the opportunities and risks in implementing a new set of business features by software development. This is often done in order to allocate a budget and understand if there is business case. This is done before a development team is allocated or procurement activity is initiated. All these types of efforts done before actual costs are expected may be defined as a “pre-study”.

The tool-box at hand for the typical business person, for conducting pre-studies is often limited to word processing, spread-sheet or presentations. Sometimes a modeling tool may be used to illustrate requirement dimensions such as use-cases, information models, processes etc.

The hand-over of the pre-study to a development team or a procurement team is very often problematic as the level of detail needed for them to proceed is not possible to obtain given the tooling above. This lack of detail and the limited support for an accurate abstract representation of the feature set in the pre-study will often result in a lengthy dialog with the business stakeholders in an agile fashion deeming the pre-study to be of little or no value.

A more efficient approach than to do a pre-study would be to equip the business representatives with a tool that would allow them to accurately represent any business software by a given set of standard projections. These standard projections may then be used as either base for a procurement document, as a complete architectural document given to a development team or as input to a model executor of choice.

This requirement cube consists of the following views.

•    Information model
•    Declarative view models
•    State machines
•    Interaction model
•    Access control model
•    Correct and relevant test data.

The MDriven tool box allows for you to describe these views in standard UML and can be exported as XMI or XPS.
Challenge yourself and create your next pre-study in MDriven!

2 What (standard) product should we buy?

It is often very tempting to accelerate digitalization efforts in an organization by deciding to buy a standard system, after all – how different can our way of operating our business be from other similar businesses?
One efficient way to establish a base-line requirement to use for the comparison is is to define your organization’s domain language in a structured way in order to compare it with standard systems candidates? Is it ok that ”Work order” is called ”Project” in the chosen system or that a government authority needs to manage “customers” in the (standard) CRM? What can be changed?

Instead of the glossy brochures and smooth presentations, challenge the vendors to demonstrate how your domain model may be managed in their system. This will give you clear insights of how well your model might fit in the candidate system.
Another way is to require the information model from the vendor’s system, buy importing parts or the complete model you may use the Autoform feature in MDriven to emulate basic functionality and test how integrations towards your existing application landscape would impact it.
It is important to also reflect of the level of change over time that is needed from the standard system, it will by default represent a master data source for parts of your business. This might be perfectly fine for the areas of your business that might see little or no change, typically regulatory areas such as book-keeping and similar. For areas with higher degree of change one needs to understand that the selected system will control what is possible to evolve during the expected system life expectancy. For areas with higher degree we suggest that you use the MDriven technology in order to support your business in an efficient way for a long time to come.

3 Gist is fine but modernity is dated

It is not uncommon that what finally sets the End of Life (EOL) for a software system is the lack of support for the technology (modernity) that it is realized in. In mature and slowly evolving businesses it might that the only reason for change of a software system is the need for new modernity, not necessary the lack of Gist. One way to handle this situation is to start a project that mainly re-implements the Gist in a new modernity. This will give the system a new supported life for about 3-9 years before the next shift is needed.

One other way is to use MDriven with its reverse database and auto form technology – ”the Gist extractor” to re-establish a Gist that may be used to realize a system in one modernity and then move it onto new modernities as they come and go. Thus ensuring a steady system support supply and hence no need for refactoring. Ever. Given this it might be possible to “swap” out an old system overnight and replace it with a new system the day after. Same gist – new modernity. No business impact! This strategy is usually very fast as quite a bit is automated and the rest of the Gist may be done just by replicating the behavior of the old application. We have seen speeds up x100 in comparison to the effort spent implementing the original system.
In the same manner it is possible to “lift and shift” a system from an on-premises environment into the cloud. MDriven can be used to expose REST API in a secure manner for applications lacking API:s still on-prem and thus allowing for a controlled journey to the cloud.