Service-based IT architecture can ensure public IT security while simultaneously reducing costs

With a service-based IT architecture, we, as one of the world’s most digitized nations, can ensure the IT that binds our extensive welfare model together.

The best public IT solutions make the work more efficient for the skilled people who take care of us in our interactions with the public sector. At the same time, these solutions ensure that our rights and personal data are protected as individual citizens.

As a public IT purchaser, you should ask your IT supplier the following question:

“How do you ensure that our solution can be continuously developed and maintained – in terms of security, development requirements, and costs?”

All too often, large IT tenders place disproportionate emphasis on the immediate costs of building, modifying, or configuring an IT system. They forget to consider the long-term perspectives, where maintenance and system inertia can eventually tip the cost balance.

Over time, this has resulted in a plethora of inflexible public IT monoliths that deprive administrations of real progress.

The monolith is the comprehensive and closed IT structure that we often end up building, despite our good intentions, when we need new systems. However, the monolith is expensive in the long run.

A minor change can incur significant costs because other parts of the solution risk being damaged when, for example, we alter the underlying data structure.

Example: One Day’s Work Requires 14 Days of Testing

A minor extension that should realistically only take one day can often last several days and, for example, end in a 14-day test. This happens because it takes time and insight into large parts of the solution to understand the consequences of the change, and because the risk of errors elsewhere in the solution is very high. Therefore, it becomes expensive and extensive to work safely.

As a result, changes are often bundled into larger releases – every six months or perhaps just once a year. This leads to long delivery times for minor changes and means that customers and users have to deal with many changes at once.

This is a problem in itself, but furthermore, releasing becomes complex and risks introducing new errors when the various changes need to be merged.

Over time, the monolith tends to grow both in size and complexity, and the aforementioned changes grow along with it. Consequently, the monolith becomes increasingly static and requires ever-growing resources for quality assurance, which likely leads to deteriorating workflows and service levels over time.

Solution: A service-based IT architecture 

The above is, of course, far from satisfactory. Therefore, more and more are in the process of dismantling the large monoliths and thereby regaining the development potential in their IT structure. The goal is to reduce costs and the ever-increasing sluggishness in the further development of our systems.

One of the most significant factors in this is to divide the systems into truly independent subsystems. In the monolith, we have often tried to divide the system into independent modules.

“In practice, however, the modules are not independent as long as they work on the same data structures and database schemas. If we really want to reduce the disadvantages of the monolith, we need to change this.”

Microservices take this principle to an extreme, but we can also achieve a lot with less drastic measures on the way to a service-based IT architecture.

Independence is crucial 

The crucial factor for a service-based IT architecture is the independence between the modules and components into which the system is divided.

The modules must have their own data structures and database schemas, which are not known to other modules, and interfaces must be defined in a contract between the modules, containing only the information they share.

The same concepts can certainly be found in multiple modules, but there will be differences in the content and thus the data structure they have.

The Case Module – an example of an independent module

A case module, for example, may have a relatively complex data structure for a case, while a document module may only need a case to have a name, a number, and perhaps a status.

Changes in the data structure of the case module will therefore be harmless to the document module as long as the interface between them continues to deliver a case with a name, number, and status to the document module.

“The module division ensures that we do not break anything as long as the modules adhere to the contract with the other modules.”

Thus, the test for implementing a minor change in a module will be isolated to understanding the consequences within the module. There is therefore a much greater likelihood that the aforementioned one-day task can actually be completed within one day, and that the testing task is reduced to a corresponding size.

If we build our systems as truly independent modules and continuously ensure that our modules are of an appropriate size, we will be able to significantly reduce the costs of further development. This will give us a much better opportunity to ensure progress and adaptation of our systems.