This is the fifth post in my microservices series and follows on from the previous articles:
In today’s post, I take a look at best practices, and ask whether the concept really is ‘best’.
This is the fourth post in my microservices series and follows on from the previous articles:
In the above posts (particularly post two), I identified and discussed what I believe are the key problems with custom enterprise software development. Today, I take a closer look at one of those problems: the monolithic architecture.
In the first and second posts in this series, I took you through a high-level look at microservices as a phenomenon, and a detailed examination of the issues that we face with our software, respectively. Today, I present the qualitative and quantitative evidence for my claim in the first post above: that “enterprise software development is broken”.
The qualitative evidence
Welcome back! In the first post in this series, we took a general look at microservices as a phenomenon and at how they can help us build better custom enterprise software. In today’s post, I take an initial deep dive into the issues that we face with our software, with the aim of giving you a good picture of the state of enterprise software at the moment.
We have identified microservices as a fundamental new approach that can radically improve the timeliness, quality and reusability of our code. Now what?
This is the first in a series of posts by Richard Rodger on the subject of the microservices architecture. The series will run over the next few months.
The enterprise software industry has a problem. I’m going to point out the elephant in the room. In fact, I’m going to walk right over and give its trunk a good, hard tug.
Most enterprise software projects are still delivered late and over budget. Or, to put it more bluntly: enterprise software development is broken.
Let’s think for a moment about what the software that we build is supposed to do: deliver business logic. Yep, the grubby business of helping our clients to sell stuff and make money.
Not too elevated a goal, is it? Not exactly up there with the ceiling of the Sistine Chapel, or the software system that took the space shuttle into orbit.
Yet our behavior often suggests that we – the developers and architects of enterprise software – think of ourselves as creators of great art, or that we are writing the world’s most expensive code. We strive for perfection. We think big. We tend to rely on intuition (take as an example unit testing, which feels like a good idea).
Let’s bring ourselves down to earth. Our code has business problems to solve, users to serve, content to deliver. As our first step back on terra firma, let’s re-acquaint ourselves with our old friends, science and engineering, as embodied in components.
Enterprise software tends to be subject to hugely unrealistic expectations. Even software engineers often underestimate the true cost (in terms of both finance and time) of trying to build near-perfect software. Perhaps this is because the world’s best-known examples of great software systems, such as the Apollo guidance system, or the space shuttle flight computer, were not built for the enterprise. They had the luxury of not having to think about things like return on investment.
In the enterprise software world, we do not have that luxury. Successful business requires risk assessment, risk management, and return on investment analysis. Enterprise software development is no exception. Aiming to build defect-free software is almost never a good business decision, because achieving perfection is exponentially expensive.