Frankenstein IT solutions

At the various organizations that I’ve been involved with regarding IT strategy and architecture it always strikes me that they so often “bury” themselves in technology. What started out as a nice architecture has derailed into a Frankenstein solution, as I’d like to call it.

Often, this happens due to a combination of the usage of monolithic (and bought licences of) software products, the phenomenon “sunk cost” and architects who, as a result of that, as a carpenter (have to) treat everything as a nail.


What do I exactly mean by Frankenstein solutions? A couple of examples:

  • Tailormade software is needed to make the ERP system fit the company specific business processes. It is decided to build the tailormade solution into the ERP system, in such a way that it’s completely interwoven. With, as a result, updates of the kernel break the system. They should have chosen a loosely coupled solution, but that wasn’t possible because the IT landscape didn’t cater for that, didn’t have the right tools.
  • The integration middleware offers features to build business logic and store data for the longer term. This is used to fix issues in the back-end systems related to data quality and the lack of certain data.  At the same time the mistake is made to make the middleware team responsible for the solution created.
  • A NoSQL data platform has been acquired and solutions are built on that platform to connect relational data sources and harmonize data. The resulting solutions are very complex and nobody understands them anymore and authorization and privacy issues arise as soon as relations in the source system change.

In all three examples, the tools have been used as a hammer. But the solution is oftentimes not a nail. Sometimes you need a screw, glue or a click-system. But, because we can only hold a hammer, we try to make it fit anyway. This, while you have learned as a kid that you cannot fit a triangle in a square hole in your block box. Unless you of course try to fix it in a creative way, by turning the block and making it fit. Or hit it hard with a hammer.

How can we escape this?

With the arrival of PaaS (cloud platform-as-a-service) services, it has become possible to choose the right service for the right challenge. What seemed to look like an unsorted box of legos of which many users were scared because of the complexity that such a large number of different blocks could bring with it, this turned out to be a blessing in disguise. Together with the arrival of better governance and monitoring tools in the cloud, the solutions you build with these PaaS services become more manageable.

It will make the architect’s life also easier. Instead of making choices based on already acquired, expensive licences of product x or y, the architects can now easily choose new PaaS services if the challenge asks for it. It has also become easier to “fail fast”, because if the solution doesn’t seem to work as expected in a proof-of-concept situation, you can easily turn the cloud service off again.

It does however require a lot of knowledge. The architects not only need to know everything about the various cloud services, but also about the applied architecture patterns. And the operational costs of the services. Luckily, the cloud suppliers have become more an more clear on this. Every supplier provides “open source” best practices and patterns that you can easily use. And a calculator to estimate the operational costs.

Finally: It’s always difficult for any organization to change an already chosen direction. More so, if lots of money has already been invested. But it is very important to also think about the maintenance cost. And the job satisfaction of the people who have to keep the solutions afloat is also very important. It too often is the case that 80% of your IT budget goes to maintenance and thus only 20% to real innovation. And as a result, many IT people leave the company dissatisfied. So, make sure that the architects in your organization have more than a hammer in their toolbox!

The El Niño of the digital ecosystems

After digitizing current processes we started optimizing them. All purely focused on efficiency. Saving costs. Improving margins. Happier customers. Now is the time to start the real digital transformation. A revolution is needed.

Many organizations are working on process optimization. They are looking at eliminating human interaction by means of digitization, integration and robotization. Organizations working LEAN will go a bit further and will continuously try to improve the efficiency of processes. Mostly, this is all based on current revenue streams and business models. Also, it is assumed that the organization has a relevant function and will keep that function in the ecosystem.

What’s happening around us?

Every organization is part of an ecosystem. Ecosystems that become more and more digital. By exchanging information digitally between parties in such an ecosystem, these ecosystems will become more and more efficient. First we used EDI and today, in modern application landscapes we use APIs more and more. APIs that are becoming smarter and smarter and can find eachother more or less automagically. APIs that are a direct interface to an existing application. An application that most of the times is a system of record. Not a very “interesting” application most of the times, only capable of handling basic administrative needs such as handling orders and ship notices.

The middleman in crisis

There are only a few systems of record that really deliver true value add for an organization. The real value add of an organization usually is in the uniqe position in an ecosystem and the processes it delivers by means of a combination of all kinds of software systems, on-premises and in the cloud. But what happens when your combination of services suddenly is not relevant anymore? Because ecosystems have found a way to solve the isssues in another, much better way? Your organization actually doesn’t have a function anymore? Because you are actually the middleman? Crisis!

We are seeing everyday that new ways of working together in ecosystems evolve rapidly. The most important unique selling point of blockchain is to cut out the middleman. This is possible because the system enables collaboration without having trust in place. You don’t have to trust eachother. The trust has been digitized. By means of smart contracts. Look around you. Blockchains that enable peer-to-peer lending, that make wholesale and banks obsolete, that replace marketplaces and trading systems, etc. etc.

Blockchain is a revolution

Blockchain is the El Niño of the digital ecosystems; it changes traditional collaborations between companies and disturbs the balance. We will probably see an Al Gore like person in the near future who will warn us of the dangers. But, just like in nature, it will take a while but a new balance will evolve. After which the landscape will be thoroughly changed. There will be many victims, but sometimes that is needed to make the next step, as a whole.

If your organization will become a victim depends on how much value add you deliver. Oftentimes this depends on the need for physical assets or infrastructure. For example: A supplier of green energy who does not have assets but only handles the trade and contracts can be replaced by a blockchain. The supplier that also owns the wind- and solar farms and the infrastructure for homes and factories will be much more difficult to replace. Until the time that you’ll be able to generate 100% of your own energy need. But if energy surplus needs to go back into the net, you’ll be needing infra again. Uber can easily be replaced by a blockchain. Uber doesn’t have assets. And really no value add. Blockchain is a revolution. In every boardroom this should be on the agenda permanently. Make sure you understand the technology and its impact. Don’t be an American member of congres who doesn’t understand Mark Zuckerberg’s business model and technology. Work out a solution and really start innovating!

Cheers, Gijs


The business value of Microsoft Azure Logic Apps

I’ve written a paper on the business value of Microsoft Azure Logic Apps for Integration. Mainly useful for CIO’s and IT managers considering Azure PaaS services for their Integration needs.

It describes the components of Microsoft Azure, and then drills down into aPaaS and iPaaS to position Logic Apps, API Apps and API Management. Furthermore it describes common integration needs in complex application landscapes such as keeping data in sync, creating composite apps, involving supply and demand chains and integrating apps and portals.

Next it describes the real business value, so that you can explain it to your business stakeholders as well. This includes creating value add on top of commodity SaaS apps, leveraging investments in legacy applications (your Systems of Record), decreasing time-to-market, channel renewal, agility: basically digital transformation using Gartner’s pace-layer application model.

Lastly it describes the different integration themes that Logic Apps can help you with.


Please share as you like.

Cheers, Gijs