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!


Cloud. A euphemism for the Internet. Internet. A virtual community without any governance. Anarchy! How can we still make sure that this keeps on working?

For many people this may come as a surprise, but for most of us it won’t: The physical world has been divided in countries with each having their own government / governance in place and the Internet is one big global virtual world. The Internet gurus are all convinced that this should never be tampered with. The Internet is self-governing.

Of course there are some principles to which the Internet adheres and within which’ boundaries it further develops. Global agreement on for example domain architecture was necessary. The right choices that have been made in the beginning turned out to be very valuable. Once in a while we do come to a grinding halt however. Think about the limitations of IP numbering. For once and for all let’s not forget: when you, as a developer, think “uhm, that should be big enough”, just multiply it with at least a 1000 from now on. Just as a side note. 🙂

Architecture has been invented to be able to build a foundation that can keep up with future developments on it. Otherwise, stuff implodes. But especially in IT, architecture means “being able to cope with change”. A good architecture can prove its value for years to come. Until the next possible paradigm shi(f)t.

So, is architecture needed? Yes. Can it work in an anarchistic environment like the Internet? For sure. At least, when you take into consideration that you can always be surprised by rebels who don’t care about your architecture and just spray your artwork with graffiti. Or build a terrace on your flat rooftop. By preparing for the worst, at acceptable cost, an architecture can sustain fine. But, like I said before, a next big invention in IT can for sure start shaking the foundations. For example, a bit that can be 1 and 0 at the same time is something we have to carefully think about before we start deploying solutions built on that paradigm massively.

I’m convinced that with the current methods of developing distributed solutions we are well on our way to build fine, architecturally sound applications that can be deployed in the anarchistic clouds. Microservices architecture is an excellent way to thrive in this chaos. Microservices architecture is anarchytecture! So, what are DevOps then, actually?

Cheers, Gijs

p.s. Thank you Skunk Anansie for the inspiration for this blog post and hence its title.