In the Bible of Software Development, a new book has just been written.
Steve Jones’ SOA Anti-patterns is one of the best things I have read in a while. I do have to say, however, that I must be missing something on one point here.
Description
Organisations start with a detailed Process map and then attempt to “fit” this into a Service Oriented Architecture; this refactoring leads to process becoming the dominant feature and leads to a Process Oriented Architecture (POA) rather than SOA.
EffectAn organisation’s “Services” come in two basic types, firstly end-to-end processes that co-ordinate lots of individual steps, and secondly a large set of fine grained services that represent individual steps. Any hierarchy or structure is solely from the basis of process. The fine grained services proliferate and become difficult to manage while the large business process elements become difficult or impossible to change. The systems slowly, or quickly, stagnate and lead to solutions being built on top of the existing solution and the general treating of the process oriented system as a legacy application.
I must be missing something here, but this seems to represent EXACTLY what I hate about BPEL orchestrations. Now, I tend to be a fan of having somewhat fine grained services for systems-type access, and larger “Service-Services” that call back into them. The problem here is, both the anti-pattern and the resolution are pretty murky:
The first resolution is to independently of the process map create your services architecture. This will provide the structure for breaking down the processes and creating a clear hierarchy of use. Next, this service architecture should be over-laid onto the process map to understand where the cuts should be made. The current solutions can then be refactored to create a more service oriented solution by attacking the major inflexibilities in the system and then looking towards incremental change of the current systems.
This isn’t even so much about a technique or a pattern. What he is really saying here is “Hey, it helps if you plan stuff out and put a little A in your SO.” That is a whole lot of words for a “well duh” kinda point.
I do have to say, however, that Point to Point Web Services, DIY Transport, UBER Service and Defensive SOA all represent things that I have been railing against for months now at my current employer.
Having woked at both an ILEC Telecom and one of the big three US Railroads, I can safely say that there is a lot more "system" thinking than "business" thinking in these types of company's IT departments. The IT staff in these sorts of companies tend to approach a problem from the perspective of, "ok, we have to solve a problem in this area, so that means we need to replace systems a, b, and c. They serve such and such a purpose, so that means that we need to come up with a solution that basically does x, y, and z."
What I believe the author is trying to say is that you should step back and essentially ignore the current systems. First create services that solve business problems, such as a generic Commodity lookup in the case of a Railroad or a generic product/offering lookup in the case of a Telecom. Once these building blocks are in place, attempt to use them in the problem domain and enhance them as needed.
Bree
There's probably some overlap of ideas here, but there was a similar article at developerWorks:
http://www-128.ibm.com/developerworks/webservices/library/ws-antipatterns/
I don't think this IS an antipattern. Look at that "effects" graf: the first two sentences, in my judgement, describe a good outcome.
Then the third and fourth sentences describe what would happen with horribly bad and careless governance; but notice that bad and careless governance leads to much the same result no matter what the starting point was. So I think there has been a bit of a bait-and-switch here, all within a single paragraph.
A hole is not an antipattern until you fall into it.
The "Resolution" is fairly good advice how not to fall into this particular hole, but would not help much if you were already in it.
Cheers for the feedback!
Completely agree that the resolution for the Percolating Process element (which I think is the one your are talking about) is a little bit of stating the bleeding obvious. Unfortunately I've found to my cost that Process Oriented Architecture is being widely used under the guise of SOA, with organisations planning Visual COBOl Enterprise edition style projects.
To be clear on the resolution, what I'm saying is that you need a clear BUSINESS service architecture to put the process oriented world into context and give it clear boundaries.
(And for the record the first SOA Blueprints Anti-patterns post went up before the IBM one... a case of either great minds think alike, or small minds seldom differ).