08/21/08 :: [SOA] Malik's Laws of Service Oriented architecture [permalink]

|

Despite what he thinks, I like Nick, he is a warm and smart Enterprise Architect. Unfortunately we seem to have opposite views.  I wanted to write a post about JaBoWS (Just a Bunch of Web Services) for a while, so I am taking the opportunity to respond to his latest post on "Malik's Laws of SOA".

Frankly there are only two paths moving forward for IT: throw-away and recyclable IT assets. You look at HashRocket's 3-2-1 Launch product and you say,  cool, I can build a web app in about 3 days, so if I don't like it anymore, I can just trash it and start over. If in addition you use EC2, you get a nearly perfect throw-away vision for IT. Of course Obie does not include integration and data migration in his 3-2-1 launch offering but I would argue this sounds a perfectly valid vision for IT, well in line with Agile practices.

At the opposite end of the spectrum, SOA's vision is about creating reusable assets which can be composed into new solutions. Reusable assets are crafted and re-crafted to be and become reusable as it does not happen serendipitously. I would argue that this is a valid vision as well. Agility happens at the composition level, while reusable assets are designed and implemented in a less agile way.

Of course if you create assets that are neither reusable, nor that can be thrown away because they cost you so much to develop, you are in deep ... well ... you are in bad shape.

Which vision do I believe is right? The former, the latter, both, it depends, all of the above. I don't think it would make sense for me to say which one I believe in, I am pragmatic, I am for applying the right technology and solution for a given problem. It's clear that I focus most of my time on SOA and reuse and I tend to dislike MVC because it is for me an anti-pattern of information systems construction as it does not surface resources, resource lifecycles, business processes and tasks. It creates assets that are not reusable and the only valid approach to MVC is throw-away Models, Views and Controllers. Obie got it right, with Ruby, he has pushed MVC to its ultimate form. Please note that I am not using the word "throw-away" in a negative way, I highly respect everything that can make IT work better, cheaper and faster. This is the point.

So let focus on SOA, reuse and and Nick's laws of SOA. Nick highly criticized a JaBoWS approach a few months ago. He went as far as saying that JaBoWS are the enemy of SOA. So let's look at his new principles as they probably reflect his vision for SOA:

No one but you will build the services you need in time for you to use them

Yawn... as long as you have the skills, you can probably do that. If you don't have the skills because you are using a specialized Service Container that helps integrating with say a legacy system (that you have no control over and you are quite unfamiliar with its interface), YOU won't be building the service that YOU need. It will be built by the integration developers manning your ESB. So "law" #1 is not a law since it is actually invalid most of the time.

If you want to be successful at SOA you need to create a SOA Center of Excellence and have these guys build services when projects need them. Over time the knowledge will spread across teams and Nick's "law" might become true for some services (not all).

If you build a service that no one else asked for, you will have built it for yourself

Yeah, whatever, some people have too much time on their hand. I would not call that a law: how could that be false?

If you build a service for yourself,  you will optimize it for your own use

Boy, do some people think really hard about what they do.

Now, world class logic:

Therefore, any team building reusable services must build each one only after two or more people have asked for it

How about the improbable situation where someone asks for it, we identify that other projects might need it sometime in the future, but they did not ask for it. What do we do? we don't build anything or does law #1 applies?

Nicks has some corollaries to his "laws":

If you invest in improving someone else's pre-existing service, you will create a reusable service.

You mean someone is going to let me touch THEIR service implementation and tailor it to MY needs? I am being sarcastic here, let's assume when Nick says "invest" he means: pay the other team to "improve" their service so that you can consume it. Assume that this team actually has the bandwidth to do that (and that's a really big assumption), Nick, doesn't this corollary means that JaBoWS is the way to build reusable services?

Creating a reusable service, by improving someone else's service, will cost you more, up front, than writing a completely new one.

Why, where is the evidence for that? This is actually, in general, wrong. Rewriting business logic or systems of record (that you could otherwise be service enabled) is likely to cost you more in any situation. What is likely to cost more is to create services for your own (and only) consumption when you could use other technologies to achieve the same goals (because you need specific skills, dedicated service containers, consume the service and deal with exceptions...).

The foundation of SOA is that it is always easier to reuse than to duplicate. If WS-* or REST for that matter cannot make that happen, then SOA makes no sense.

The cost of maintaining a service increases proportionally to the number of consumers that use it.

Nick, I mean come on, how can you write this kind of thing? First, it is almost always wrong because your proposition assumes that the service has baked in specificities for each consumer, which is hardly ever true (have you ever heard about forward compatibility?). Second, compared to what? assume now that SOA and reusable services don't exist. We now have consumers that duplicated the business logic and system of record for each solution they participate in. Is it cheaper then?

There are two paths to build reusable IT assets:

1) set up a team and start identifying reusable services build them and wait for consumers to come ask for them

2) build Just a Bunch of Web Services (JaBoWS) as needed on a per project basis and then wait for requests to reuse them to make them reusable

IMHO, the first path will most likely fail, simply because it will require an infinite amount of governance, there is a huge mismatch with funding practices (which are aligned with projects) and overall it introduces a huge risk of doing a Just a Bunch of Expensive Work (JaBoEW). Talking about "throw-away", well you are likely to throw away a bunch of work here.

The second path actually has also a high probability of failure because it will grow to an unmanageable situation where nothing is reusable, but you can mitigate the risk of failure. How? It is actually fairly simple:

1) Govern just enough, when you build one of your JaBOWS, do a bit of governance, look around for potential consumer and collect their input. The sooner they are going to consume it, the more input you should get from them (don't forget to ask for money too)

2) Implement a world class Versioning Strategy.  This is how JaBoWS evolve into reusable services. Without versioning you will break existing consumer(s) and create major inefficiencies and aggravation for existing consumers each time a new consumer will require some "improvement" to a service. I argue that without a versioning strategy you are doomed to fail your SOA, you'll never get to the point where JaBoWS can be reused. This is why any approach based on REST, for instance, will fail because they cannot support a versioning strategy. Please note that nobody except for Pete Williams talked about this problem. Stefan, Steve V., Tim Bray, Stu, ... no-one absolutely no-one speaks about versioning in REST.

3) Think Loose Coupling. Governance will be imperfect, your versioning strategy will be imperfect, you still need a strong loose coupling capability to "adapt" consumers and providers. LC is not just about "interoperability". Sure interop is an important part of LC but there is a lot more to it. In the most general sense, Loose Coupling is about "making two (or more) pieces of code build by different teams, at different time, using different technologies, interact with each other by achieving autonomy, modularity, evolvability and variability". Loose coupling involves using:

  • a technology neutral asynchronous reliable communication infrastructure
  • an activation strategy that can scale with new consumers
  • a common extensible message syntax with validation capabilities
  • a clear separation between technical and business exceptions
  • interacting peers not client/server tiers
  • well defined interaction contracts
  • a federated security mechanism
  • an assembly/composition technology (SCA, BPEL)
  • ...

JaBoWS is, IMHO, the path to SOA that has the highest rate of success because it is aligned with the way the enterprise and IT works. It is the anti-big-bang, pragmatic, SOA initiative.

JaBoWS is probably SOA's best possible friend, it is the foundation that will let you create reusable services.

Now, again, don't get me wrong, I am open to Obie's approach to IT, I'll become a Ruby developer, if this approach can be more successful than SOA, I have no problem with that.