The Frankenstein Principle in IT Analysis

Reading IT blogs and professional journals makes you sure that everything will be different in IT in general and in IT analysis in particular. Digital transformation and disruptive innovation leave no stone unturned. In addition, artificial intelligence could even replace the profession of analyst. The fact that agile software development is also revolutionising the analysis process is already common knowledge.

But the announced change of our days is nothing new. About 20 years ago it was object orientation that (allegedly) turned all IT professions upside down, and later – albeit to a lesser extent – service-oriented architecture (SOA). Apparently, our job description is subject to constant change. And a lot is actually changing, which also requires constant learning from us. Here however the question is posed: Is there nothing that remains? Does the IT analysis as we do it today still have anything to do with the – let’s say – seventies? Is there such a thing as the “essence” of IT analysis, which is at its core and which remains constant despite all IT trends?

Engineer – Creator- Manager

Let’s do a mind test: Briefly forget all the job titles that exist in IT projects. Forget about the requirements engineers, business analysts, solution designers, delivery managers, data analysts, UX designers and everyone else. And then we think about what we need to handle a software project. We will come to three groups:

• We need people who know the technology – someone who knows the programming language, can set up a database, can handle all the other tools you need to create a software application and test it. We call this group the engineers.
• The second group is concerned with what the software is supposed to do at all. Software is not an end in itself – it must create value for the organization concerned. Someone needs to know the laws of the subject area, make sure that the developed software complies with those laws, so that the goals can be achieved. We call this group the creators.
• Finally, there is the matter of time and cost. Every software project is confronted with scarce resources. The third group takes care of it. These are the managers.

Engineer – constructor – manager. This is the timeless division of labor in every software project. Every new function that often arises out of time can be divided into one of these groups. This was the case in the seventies, and will continue to be the case in the future.

As business analysts, we clearly belong to the “creators”. That would have defined our role in an IT project. But we now want to take a closer look at the role of analysts. What does an analyst do when he creates? What is his task? And what does the solution look like?

The Essence of IT Analysis – the Frankenstein Principle

Of course, no two solutions are the same, each has its own special features. But here, too, the question is raised: Isn’t there a pattern that (almost) all IT solutions follow? Is there such a thing as the “essence” of a solution that also applies beyond the respective time and its fashions?

Do you know Victor Frankenstein? You probably don’t have a positive association with this name. That was the one with the monster, wasn’t it? Yes, that’s exactly what I mean. And Frankenstein had the best intentions. He wanted to create a perfect human being. He needed three elements: a skeleton as a solid base; muscles to give the being dynamics and movement; a skin as an interface to the outside world.

This is where the parallelism with IT analysis lies. The solutions we design are generally not human beings. But they are systems that – just like the essence of Frankenstein – require three elements: skeleton, muscles, skin.

The Skeleton

The skeleton is the static part of our solution. It is the system of entities and relations between them. The relevant things, whether abstract or concrete, are expressed by a data model. The way of representation has changed over time. In the past, entity relationship diagrams were mainly used for this purpose. Today, UML class diagrams are primarily used. There are also different variants for the technical implementation: Relational databases are still state of the art. Object-oriented databases have been in discussion for a long time, but have never really been able to assert themselves. So-called NoSQL databases will probably gain in importance in the near future.

The Muscles

Muscles – that is the dynamic aspect of our solution. They bring movement into our systems. In general, we are talking about processes that create and change static data and thus represent reality. There are two different types of processes:

On the one hand the “processes on a large scale“. This is the order in which individual building blocks or functions are used to achieve a specific goal. For example, this is the way in which a certain business case is processed by different departments in an organisation. Sometimes one speaks here also of a workflow. Business analysts who specialise in this area are called process analysts or process managers.

On the other hand, there are “small-scale processes“. These are the algorithms that run within the building blocks. Examples are various calculations. In many cases, these algorithms are determined by the developer first. In some cases – especially when it comes to technical procedures – the analyst already makes a corresponding proposal.

The Skin

Every system designed by analysts needs an external interface through which it interacts with its environment. In our metaphor for an artificially created being, this would be the skin. In most cases, when it comes to the communication of the system with humans, this interface is represented by a screen, through which information is entered or made available.

Depending on the type of system, there are also other external interfaces. Perhaps data is supplied via sensors. If not humans but other software systems are the communication partners, then the “skin” of the system may be represented by API interfaces.

The constant in IT analysis …

Skeleton – Muscles – Skin. Or to put it another way: data model, processes, (user) interface. These are the elements of any solution designed by an IT analyst. Requirements are not the goal – nor are user stories. The goal is the design of this system from skeleton, muscles, skin (just like Victor Frankenstein 😉 ) – or in IT language from data model, processes, user interface.  And this goal is timeless. This applied to the design of mainframe systems in the seventies and eighties, it applied later to the design of client-server solutions, it applies today when we design web systems – and it will apply to the most innovative artificial intelligence solutions.

… and the changes

However, this does not mean that there are no changes and no progress in IT analysis. These changes are even necessary. They can be divided into three groups:

• Technology: the progress of IT technology gives the analyst more leeway in designing his solutions. Today’s web technologies, for example, open up completely different possibilities than the mainframe systems of the 1980s.
• Methodology: The methods used for analysis also lead to changes in the way we work. An example of this is the implementation of UML (Unified Modeling Language).
• Procedure: the agile software development procedure also requires a change in the IT analysis. It is no longer possible to create a consistent, sophisticated model. A rough overall model is refined step by step in an iterative-incremental way.

All these changes result in the analyst being able to perform his work better and more efficiently. But despite these changes, the core of the activity remains the same: it is the analyst’s task to design a system, a system of skeleton, muscles and skin – or of a data model, of processes and a surface.

Conclusion

Collecting and documenting requirements, writing user stories, … This is how the tasks of an IT analyst are often described. Yes, that’s part of it – depending on the approach chosen. But it doesn’t hit the core of the activity. With all the changes, innovations, developments with which the activity of IT analysis is confronted, the actual task of the analyst remains constant: this task is called creation. Like Victor Frankenstein, the analyst creates the skeleton, muscles and skin of a system. In the case of IT analysis, however, we are not talking about the skeleton, muscles and skin, but about the data model, processes and user interface.

An IT analyst must always be aware of this task. On this solid basis, new developments can lead to an increase in efficiency and quality, so that the system created in IT analysis is more successful than the creature of Victor Frankenstein.

Notes:

Josef Falk has published two more post in the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.