First, a wave to the crowd
Before we begin, we need to have a serious talk. Somehow, whenever we use the abbreviation SOA in relation to IT in the presence of Dutch people, they start to giggle. Furthermore, they think we don’t know why that is. But we do know. We are reminded of it every day. For my non-Dutch readers: SOA is the Dutch abbreviation for Sexually Transmitted Disease. So, let’s giggle and chuckle together for a while, and then move on.
I had to do it. It’s like the first stage-performance of a four year old kid. The teachers realize that the kids have to know where their parents are in the crowd, they have to wave to them and receive a wave back and then they can relax and do a stage performance. So instead of trying to keep the kids focused from the start and reprimand them when they wave, they start by lining up all children on stage, turn on the audience lights and tell them to look for their parents, wave, get a wave back, and then start with the actual performance. So, we have waved, and now we can start.
The S and the O
As I stated in my previous post about Patterns and Principles, the most important thing to remember about Service Oriented Architecture is that it is a type of Architecture. That is Architecture with a capital A. In fact, the A of SOA is so big, that I felt I had to discuss the Patterns and Principles first, which I did.
This post is about the S and the O, because SOA is an Architecture that is Oriented towards Services. However obvious that sounds, it does need explaining. What it means is that it puts services central, not systems. Ah, not systems. The Systems, as you may recall from my about-silos-post, are the silos. In SOA, the systems are not the center of the Architects drawing; the services are. Perhaps the best way to explain is by showing how projects are usually started.
How to (not) start a SOA project
Have you ever seen one of these big confusing Project Start Architecture drawings? In the middle is ‘the big blue square‘ representing the new investment, the new XYZ system, or some other 3-letter acronym (I bet you can guess which one). Around this big blue square are drawn a dozen or so smaller squares, representing the rest of the systems of the company.
The goal of the project is, of course, to link all the small squares to the big square and to some neighboring squares. But a drawing like this will never result in a meaningful set of services.
No matter what architectural principles you’re going to introduce after this picture has been drawn, the name of the game is Application Integration. Because once the lines are drawn, the focus of the project is to build the lines between the systems, i.e. to integrate the applications.
In order to avoid this spaghetti in the making, we should not start with the big blue square in the middle, but make a draft of a Service Inventory Blueprint instead. You might recognize this as step two of the SOA Project Lifecycle of Thomas Erl. Using the SOA Project Lifecycle as a yellow brick road, we can indeed make the transition to a meaningful service landscape. I will circle back to this later.
Service Inventory Blueprint
I promised an Orientation towards Services, which starts with step two, drafting a Service Inventory Blueprint. Then this may come as a surprise: a Service Inventory Blueprint is a collection of Service Candidates. What?!? Candidates? Yes, I told you so, it would come as a surprise. At this stage we’re not yet talking about services. A service “exist as a physically independent software program”. And since we’re only thinking stuff up that’s not yet implemented, we don’t have software programs yet. Right now it’s all just hypothetically, so if we want to use the words service at all, we may only say Service Candidate.
So, how do we determine these Candidates? Good question! We first need to find out what your business is all about. Or at least, a part of it. Start small and build iteratively. Look at Business Processes and Business Data-Entity Models etc. (see how all my posts finally come together?) What capabilities do your business processes require from your IT? What capabilities can your Business Data-Entities deliver? Such capabilities translate into Service Candidates almost one-on-one.
Now, with a Service Inventory Blueprint on our hands, the objective of our IT project is very clear: build your Service Candidates into Services! At this stage, no system or silo has been mentioned yet. The services may, as part of their internal working, very well use one or more systems to perform their capability, but that’s for later on in the design process.
How to start trouble
Now, I can hear all of you whispering: “He skipped the first stage of the SOA Project Lifecycle. And it’s labeled a critical stage, too.” Yes, I did skip that one. That’s because, as a consultant, I’m never present at this first stage. Nor at the second, now that you mention it. Usually, I start when the Service Inventory Blueprint has not been drawn, but that other picture has. From that big-blue-square picture, I’m asked to design the ‘services‘ or ’APIs‘. To which my answer always is: ”What services? There aren’t any. These are just lines.” And then the User Stories come in: System A needs information X from system B. So I make up the best name I can think of as service name. Two sprints later, another system needs more or less the same data, but uses another key, does not need these three fields and instead needs those five extra fields. Is that going to be the same service? Or should I invent some other name that more or less explains what we are doing here?
As you can see, the trouble quickly follows.
Technicians party
Why is it, that the big-blue-square picture is drawn in the first place? In my experience this has to do with the scope of projects in general. Where the assumption of SOA is that a company’s biggest wish is to align business people with IT people, the reality is that most company projects are the kind of parties to which only technicians are invited. One generally recognizable project scope is “upgrade this big system to version Y”. That is clearly a technical-guys-and-girls-thing only. No need to trouble our business people with this. But wait! While upgrading, these techies should really follow our latest and greatest architectural principles: everything should now be a service! So where our old system had a direct line into the database of system X, that should now be a service! Where our old system had some file transfer-thingy with system Y, that should now be a service!
At this point in the project, the project scope is no longer negotiable since the budgets have been set. It’s certainly not allowed to have any business people involved because when we decided on the budget, the only thing that we wanted was to upgrade the big blue square. Here are the lines, just make the services!
Back to the yellow brick road
Half way through this article I already solved the problem I just described. So, guess what suggestion I’m about to make? No, don’t start with the Service Inventory Blueprint. That’s step two of the SOA Project Lifecycle. Start with step one: asking yourself questions. Like: is your (entire) company ready for SOA at this stage or not? Are your project scopes all about technology, or are you ready to start dealing with the business questions? Is governance in place? What are the risks? In other words: think about integration sooner rather than later and certainly think of integration before you draw a big-blue-square picture.
Then, once you have your questions AND answers carefully formulated, all you have to do is follow the yellow brick road of the SOA Project Lifecycle. Just don’t forget to follow it all the way through to versioning and retirement, or you’ll still end up with an unmaintainable situation.
Bubble Conclusion
This is the final post of the Popping Bubbles series, in which I have been building up to SOA as (maybe) the final answer on how to pop the bubbles (= silo-thinking) in an organization. The question to be answered is: do we still have Bubbles now that we have SOA in place? The theoretical answer is no: business works together with IT so IT can make all kinds of information available that is relevant for the different business processes and everybody lives happily ever after. As explained in this post however, it’s very obvious that this theoretical end-state is not easily reachable.
So SOA (in practice) is not the final answer. I do hope that this series made it clear what long way we have already come and that where-ever in the series you-as-the-reader find yourself at the moment: you are not alone and there is a way forward.
We have seen all the effort IT (mainly) has made to integrate the different silos and departments and how futile these efforts may have been, and will remain to be, as long as there is not at least an equal effort of the business to help IT help them.
Of all these efforts, SOA at least starts with the assumption that business and IT should work together. And whatever may follow after this starting point, in my experience it gives you the greatest chance on a successful end result for all stakeholders.
