Your system – any system – should be transparent in order to gain trust. Would you like to fly a Boeing Max 8 with mashup code from everywhere that no-one fully understands? You can trust systems that are not transparent – but it is easier to build trust for transparent systems.

Transparent systems has been extremely (and I really mean insanely ) expensive to build – and even more expensive to maintain with traditional imperative methods.

Being transparent is not the same as open-source – the shell game with three cups and a ball robbing you blind is “open-source” as in anyone can see the definition, but it is not transparent. Transparency implies easy-to-understand and easy-to-follow – and that does not come naturally to imperative code even if it is open-source.

Transparency in systems is something you will want in these cases:

• Your system is successful and will survive for a long time
• You want more than one person to be able to improve the system with precision without a huge risk of unintended side effects
• You want your system to be extendable and changeable so that it may follow along as time change the domain the system supports
• You want to make sure your system does not do things you do not know about – easy to accept that this important in banking and military-grade systems
• Your system is the basis for how an organization work – new people within the organization will want to know how things are connected and what the rules are
• You have accepted the futility to try to document a system from the outside, since this will only work if the system is changed slowly and since documentation efforts are often equally expensive as constructing the system

Why is transparency increasingly important?

Software is getting more complex and we allow software to do more things for us in our daily life. When the outcome is unexpected we will want to review the rules of the software to see if it is the software that has it wrong or if I as a user simply forgot a rule that should be obeyed. If this review, to find out the rules, takes too long, users will lose trust in the software and we will not be able to reap the benefits of digitalization.

Also as we get more access to AI based systems that look for patterns in data and make fuzzy decisions based on what it sees, we must understand the data we feed it better. The AI will very seldom be transparent as such – and the data we feed it is our biggest opportunity to make it behave the way we want.

How to solve the transparency problem

There will always be a subjective slant to a statement like “this system is transparent”. Transparent to whom?

For those that are fluent or semi-fluent in modelling strategies like UML and OCL an MDriven-model will probably be transparent. But for the the un-initiated reader UML may not be helpful and OCL may look impenetrable. How can we make OCL more transparent to an inexperience reader? It would be good if we could have someone to explain what the expression does in plain English – like a verbalizer.

Part from verbalizing ocl-expressions we also need the full cross reference of all ViewModels available in the system – how actions navigate between these views – what information that is actually shown on those views. Can we do that we would have reached a long way in making the system transparent even to people not fluent in OCL or UML or any other declarative system description strategy.

It is important to remember that the average user that seeks information does not expect to be forced to learn new concepts prior to getting to the information they seek – they expect a bit more clarity on the question at hand – nothing more and nothing less. A fast simple answer is what the user seeks – and maybe, just maybe that answer will get the user interested in what lies behind the answer and seek more information on the subject.

It is important to be able to help the user in a manner so that the user feels that knowledge is easily retrieved – because the fact of transparency will be judged by the average information seeking user. If the users find the system transparent then we have the main key to get users to trust the system and as we get their trust the organization have the ability to reap the benefits of digitalization.

MDriven as a base for transparency in systems

In order to be transparent to as many as possible it helps to reduce the number of important concepts one must understand in order to make sense of a description. In a totally free world where everything is possible any interpreter must also be prepared for any eventuality. As you reduce the possible choices at every juncture the easier it is to follow why a specific path was followed. But if you limit the ways to express yourself too much – then instead it becomes hard to express what you think – and if you have trouble to articulate yourself anyone trying to follow your notes will also have a hard time to understand your original thoughts.

We need to find a sweet-spot between the total freedom of “no limitations at all” and the straight-jackets of a reduced vocabulary, the sweet-spot that makes a complete system description easy to create and easy to read. For starters we should immediately remove the stupid degrees of freedom as I wrote about here, but also introduce a completely controlled environment as I wrote about here.

In MDriven we have only 3 main concepts:

1. Classes and State machines to describe the statics and dynamics of information (Standard UML)
2. View-models to transform your information into UI, Reports, Rest-Services etc. (Standard OCL)
3. Actions – to switch view and possibly execute action language expressions (Navigate)

This limited set of concepts is enough to describe and thus implement any Information system as we concluded some years ago and is described here Line Of Business Application Manifest.

The limited set of concepts makes it possible to actually statically understand most of what your system does – and this is almost ridiculously hard with any other imperative implementation strategy from 99% of the available Hi-Code (C#, Java, TypeScript) or NoCode (https://nocodelist.co)  tools on the market today.

Nevertheless MDriven is an advanced tool for information centric developers. The MDriven tool require a lot from the designer when it comes to the ability of abstract thinking – and as such it is not likely that a business user of a system in a domain will take the time to use the MDriven tools to shine a light on the inner workings of the system – in order the make the system transparent.

When we say that MDriven is a tool for information centric developers we also must mention that we have a firm belief that all developers in IT really must be information centric as this is where the challenges are for all IT related problems. However many IT developers has not reached this conclusion yet as they clinch to the next shiny tool or framework and firmly hope that “this is it – this is the tool that finally allows me do avoid the need to understand the real information based challenges in the domain I support”.

MDriven’s service for Transparency of MDriven Systems

We are announcing the beta release of our Transparency strategy; https://metamdriven.azurewebsites.net/

MDriven Meta – a service for end users that offers transparency of systems. Transparency in IT systems is a thing that will be commonplace in the future if our crystal ball is working.

More on this further on.