Before we start talking about how to do things better, we need to have a clear picture of how we do things today, and why that approach is not optimal. Obviously every organization is different, and there is a continuum of maturity. In this post, I am going to attempt to describe what I think is a fairly typical, or average, scenario. Some organizations will be better, some worse.
This average is based on a lot of experience with a lot of different organizations. It is not based on any one organization, so if you know me, and you see yourself, it is totally coincidental!
I think the best way to describe how things are normally done today, is that there seems to be a fundamental, possibly unacknowledged, assumption that everything will be all right in the end.
A lot of development is done is isolation – individual components are developed separately from each other, by different teams, or different developers, sometimes even by external organizations. Each of these groups will do their own local, usually manual, testing of the individual components they are developing.
As much as 90% of the time allocated to the project may be consumed before starting to do any proper integration testing – i.e. making sure that all the individual components actually work together when they are assembled into the whole system.
Often this integration testing late in the project lifecycle will identify many problems, a decision will be made to work 24×7 until the project go-live cut-over to get all of these issues fixed, and then we have everybody working under a considerable amount of pressure, which leads to cutting corners, and giving up on good practices in favor of just getting it done.
To make matters worse, the developer’s memory of the codebase is not fresh – it could be weeks or months since they last worked on the component where the issue was found, and it might even be a different person trying to fix the issue, who has no familiarity at all with the code in question.
Often there is a lack of documentation, tests, and so on. Does this story sound familiar? It is starting to hurt. We have absolutely no idea what the quality of our system is – i.e. how good or bad it is.
When we arrive at the go-live day, we have a lot of fear and uncertainty. We have no idea if the system is going to work in production. We have never tested it under a production-like load, and we have not really tested it for performance, longevity, etc.
Maybe this is not you, maybe you are lucky enough to work in an environment that is not like this, but I can tell you from first hand experience that there are a lot of environments that are exactly like this.
So what do we do about it? We need to change the fundamental assumption of SOA development. We should be assuming that the system works and that it is in a releasable state at all times.
That means that we need to adopt techniques like continuous integration, continuous inspection, and continuous delivery. Every time a developer makes a change, we need to get fast feedback to the developer (and other stakeholders) to tell them if that change was good – did it break the build? What was its quality score? Did it cause any of our tests to fail? Could we release the system with this change in it? How confident are we to do that?
We need to find problems faster, when they are smaller, fresh in the developer’s mind, and easier to fix. We need to check quality at every step in the process. We need to test the application, we need to automate the testing, automate the provisioning of environments, test the environments as well as the applications. Essentially, we need to go through a mini-release cycle over and over again, every time we introduce a change. We do this to prove to ourselves that we can still build the application, to know how confident we are in its quality, and to know that we can actually provision an environment and deploy the application in to it.
There is nothing magical about this. People are doing this today in many software projects. We can use the same methods and tools to achieve the same benefits in SOA projects.
We can achieve almost everything we want to do without really needing much changed in the products. There are some things of course that it would be great if Oracle added to the products, but that need not be an excuse to get started.
In the next post, I am going to outline a roadmap of where we want to get to, and then over this series of posts, we will in essence conduct an open proof of concept together, to show that we can achieve these goals, and how, in detail.