Innovation-ready-IT: The way forward for IT

A company can escape the cycle of stuttered innovation and start using IT as an offensive weapon instead of just an internal system of record.

There are ways out of the dilemma of an IT manager, i.e. being accused of obstructionism or ending up with a complexity that – over time -make live hell for every one.


The good news is: It will be a lot cheaper then spending millions of euros for major transformation (i.e. ERP) programs every few years. The bad news is there needs to be a lot of learning, some investment in infrastructure and the discipline to keep on the new track.

Let’s explore the elements for innovation-ready-IT:


Innovation-ready-IT must be cater for all the requirement of a VUCA World, i.e. a world that is Volatile, Uncertain, Complex, Ambiguous.

First of all, ERP’s tediousness to react to change must be addressed, as ERP systems still dominate the overall process and system landscape in most companies. Here is a guideline – and a warning: This is a post that needs to go into some length into the realms of  IT architecture.

Specialize in 3 System Layers

Adopt the 3 specialized types in systems of engagement, transaction and perception.The temptation to build more and more functions into ERP has been great in the past. Most data is available in ERP, there is no need to build interfaces to other systems, the ERP system takes care of many aspects of software development automatically and IT has the programming skills necessary. The vision has been to put more and more functions into the one integrated ERP Core system thereby consolidating the system landscape and ending up with fewer systems to take care of, less interfaces, less problems.

Bildschirmfoto 2015-11-13 um 12.29.42

Collaborative applications have been implemented in ERP. An example is the SAP’s solution manager, a system that his supposed to enable the Business and IT organization to keep transparency about system design both in implementation as in operation phases. All information is in this system, engineering wise, everything is there. If those obstinate humans would only use the system! It has been a pain to use from the start, as it followed the ERP paradigm: Supply correct data. The paradigm of usability had been a second thought and even later attempts could not change that. A system  that has the purpose to make humans understand another system better should really have been implemented in a system of engagement: A system that values usability foremost.

Reporting solutions have been implemented in ERP Systems. Data Warehouses came into existence mainly because data processing takes so much time and slows down the ERP systems. In later years, data warehouses improved the way data can be drilled, analyzed and displayed more and more, as they specialized more and more. But those functions that go beyond standard reporting are mostly underused by businesses. Data Warehouses may be branded as “Business Intelligence” System, but for the most part they are used as reporting systems. The history of Data Warehouse systems is an impediment to their specialization on providing real insight for companies. Managers tend to expect to expect nothing more than standard reporting. They do not expect more, as they never got anything more. Data Warehouse systems are there, but they are still strongly influence by ERP thinking that centers on providing correct, transactional data.

So what’s wrong with correct data?   A former client of mine, a CEO, had an inspiration in a session on how to improve the performance of the companies Ecommerce operations: “We need to be faster – 80% correct data is good enough”. IT honestly didn’t know how to set-up a data warehouse system with 80% correct data. Do you? I do not. The point is: We need correct data, that is a sine qua none. But the data needs to be accessible in a way that ERP systems are not build for. True insight needs accessibility. This can best achieved in systems of perceptions. I do not argue for different data warehouse software packages, the point is to use them differently.

Once a company has understood the three different design paradigms for systems of engagement, transaction and insight it is time to transition by moving more and more functions into the systems of engagements or systems of perception

Strangle ERP Systems

ERP systems, the main systems within the systems of transaction layer, need to be simplified over time, by focusing them on what they are built for: Correct transactional data used in automated processes. Functions focusing around user engagement or user insight need to be implemented in the other two layers.

But I am afraid this alone will not reduce ERP complexity significantly. There is a lack of engaging, insightful system in most companies, so there is not much to transfer at all. It is not enough to make ERP more nimble. More is required: You need to take a slice out of the systems of transaction pie of business functions.

More – splitting ERP’s? But an ERP is based on the promise of a single source of truth. How can we split that? Consolidation of more and more systems into an integrated ERP system is what most companies pushed for years, spend multi-million Euros on!

The target needs to be to split the system of transaction layer while keeping the integrity of an ERP system:

  •  An integrated system of transaction layer is non negotiable, as it provides reliable data and efficiency through automation.
  • An integrated ERP system is non negotiable, as it is basic assumptions under which it has been build is integration, i.e. the ERP system is the leading system for nearly all data

Thereby one might conclude: One integrated system of transaction layer equals one integrated ERP system. Should it?

If your company is not part of a VUCA business environment, yes! Go for the central ERP system. If everything is stable, a company can invest massively in automation and efficiency, flexibility is costly. This way a company will have an excellent, efficient execution system. Supplement this with good systems of engagement and systems of perception and you are done.

For companies that are exposed to a VUCA environment there is a different path: Strangle existing ERP, replacing them step by step with new functions using a platform as a service. Strangler Applications is, defined in the words of software architect Martin Fowler:

Gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.

This is a target picture as well as a roadmap. The target is not to strangle the ERP system to death. ERP is still the best system for stable environments where efficiency, automation and data integrity is called for. But it will not have its dominating position, as it is not sufficiently agile for the digital revolution.


Humble/Molesky/ O’Reilly (see sources) give a guideline for the strangling of applications:

  • Start by delivering new functionality
  • Do not attempt to port existing functionality unless is its to support a business process change
  • Deliver something fast
  • Design for test and deployability
  • Architect the new software to run on a platform on a service

Platform as a service

A platform as a term borrowed from cloud computing. Platform as as service (PaaS) is defined as “a platform allowing customers to develop, run, and manage web applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app”.

Let take a most extreme example of a PaaS architecture first: At Amazon every business function is encapsulated in an API. Different business functions communicate via these API’s. Each business function has defined inputs and outputs for its API, but is a black box in every other aspect. This is actually, not very unlike traditional ERP Systems, as these can be seen as set a large number of transactions communicating via API’s. The main difference between the PaaS Platform at Amazon and ERP systems is that each encapsulated business function has its own data base and ERP Systems shares one data base. Amazon therefore goes further in the encapsulation of the business complexities, as its business functions are more independent to change then functions implemented in ERP systems. The cost may be a massive redundancy of data and corresponding data alignment problems which need to countered by strong  IT architecture control practices.

But let us not go into all the problems of software engineering. The point is: A Platform as as service as run internally by Amazon is a most extreme example. Please note not to mistake Amazons internal platform as a service with AWS: Amazon Web Services, a commercial offer to customer for cloud competing services. Amazon builds its systems on AWS, but AWS does not yet provide business functions to customers on a large scale. But in the long run, this is a vision for AWS to go, threatening the very existence of ERP companies like SAP or Oracle.

A classical company endowed with an ERP system and subject to a VUCA world should:

  • Identify those business areas and functions where business requirements are relatively stable. Those areas lend itself well to be served by an integrated ERP System. Typically these areas are Finance and Controlling, Sales & Distribution and Purchasing.
  • But even in those stable areas, additional functions which provide more than the basic process flows, should be build and run on a platform as a service platform. Typical example is a supply chain tracking tool for orders and deliveries or ordering systems for the sales force.  The key is to remain flexible to cater future business demand more easily and not fall into the complexity gap of “one system for all purposes” again.
  • All business areas and functions requiring more flexibility should be implemented on the platform as a service with defined API’s. Integration technology wise, this is basically a service oriented architecture.
  • Strong, agility oriented architecture and software development practices need to be put into place

This switch to cloud based platform as a service with more software development is threatening to existing IT departments, that take the predominance of ERP Systems as granted. There has been time not so far past, that software developers where seen as a job for the fewer and fewer people, especially in the western world. Coding will be done by few and mainly in cheap labor countries. This vision of the future was wrong. Software development is not an anachronism any more, but a strategic need for a companies flexibility.

Strangling ERP? Who on earth is doing this? Well, take SAP for example

The need to change is very real. Especially for SAP. SAP is rewriting all their ERP software  to make the with to real time databases, SAP HANA (High availability networking appliance). All data will reside in the SAP HANA in-memory Database and there will be applications sitting on top of the database using the data for what ever purpose business needs. These applications communicate via defined API’s. In other words SAP is no longer investing in classic ERP Systems, but is changing fundamentally towards a combination of a central real time data bases and a platform based software design.  Since it still retains the central data base, it is a slightly different  vision as Amazons internal platform, where data is encapsulated by function, but it still can be described as Platform as a Service. SAP can not just go and alienate their installed customer based running R/3. The change to a new ERP technology stack will be gradual and will involve “strangling”.

SAP markets its new HANA platform with the slogan “run simple”. Not “Run fast”. As HANA is often misunderstood to be just about speed, this wording says much, as SAP appears to have understood that the digital age demands more simplicity and flexibility of their software solutions. If you have a quarter of an hour take the time to watch Hasso Plattner talk about it in his refreshingly authentic style.

All this work to separate system layers into specialized systems of engagement, transaction and perception and slicing up the system of transaction layer to make it more agile is not worth a dime if IT does not accelerate the time it currently needs to deploy changes. As Stability still trumps Change, how will the new IT layers and platform be at least as stable as before?

The answer is: Continual delivery. Lets look at these other two elements of Innovation-ready-IT in the next post.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *