Learning Enterprise Architecture lessons from being a parent

I apologize to readers of this blog who are childless, because this analogy isn't going to necessarily grab you, but I encourage you to read on, because I think there is an important point I'm going to make.

When my wife was expecting our first child, we focussed a lot on the due date. It was the be all and end all of our lives. We drew up birth plans, we went on hospital visits, we talked about it for hours. In the end, all the planning went out the window. Without going into details, it didn't go very well. In fact it went about as badly as it could - with the exception of Anna being born happy and healthy. And very shortly afterwards we realized a really important lesson. The birth wasn't the important thing. The birth was over and done with within 24 hours. What really mattered was the ongoing situation. Bringing up a child is much harder than giving birth, no matter how hard the birth is.

So what's this got to do with SOA and Enterprise Architecture? I've recently been involved in reviewing some good and bad SOA projects (not WSO2 projects I hasten to add). And one thing that characterizes some of the bad projects is the focus on the due date. A focus on delivering the baby. Get it out there. Not a focus on building a good project environment. Not a focus on how this project is going to live and evolve and grow beyond day 1, but simply deliver on the project scope and be done.

The problem with this is that designing an Enterprise Architecture isn't like designing a toy. If you design a toy, its a one-off. You create the design, ship to manufacturing and thats it. EA and SOA are much more evolutionary activities. You need to think about how to keep this "baby" alive and growing and healthy and learning. For example you need to know how:

• To do updates into the live system
• To test changes in a widely distributed system
• To monitor the live system - both at the technical and the business level
• To accomodate many different parties each updating and controlling their own part
• To backoff changes that break something
• etc

I think Open Source and Agile development have taught us many lessons in this space. For example, many open source projects are just as concerned about the ongoing life and management of the project as the actual releases. They know that in a distributed development organization, the only way to keep the project on track is to make sure it always builds, and always runs. So they use continuous integration, build and test to ensure that the system never goes out of kilter, and if it does, it gets fixed straight away. By using good automated tests with enough coverage, developers know they can make radical changes without danger of breaking the system. This is the mentality we need to apply to SOA and Enterprise Architecture.

I'd like to give a great example. One of our customers is a big purveyor of digital content to mobile devices, and they have our ESB in a continuous available mode. They are currently having peak loads of more than 1000 messages a second and the load is constantly increasing as they add new services into the system. They add services in continuously. The system configuration is updated more than once in some days, with zero downtime and heavy load. This is the kind of living system that is successful and agile and really delivers on the promise of SOA.

So if you are in a project that is 3 months from delivering I have two pieces of advice. Firstly, think how you want the world to look like in 4 months time. And make sure that is what it looks like now. Put your system in place right now, even if its not yet working. Make the production delivery look like just another milestone on a continuous plan. Treat it like an average birthday (the ones where the day before isn't very different to the day after) rather than the birth day!