- No one but you will build the services you need in time for you to use them
- If you build a service that no one else asked for, you will have built it for yourself
- If you build a service for yourself, you will optimize it for your own use
- It is therefore the optimal service for you to use
- It is very unlikely to be the optimal one for anyone else to use
- No one besides you will use it
- You will not use anyone else’s
Implication
Therefore, any team building reusable services must build each one only after two or more people have asked for it, with full knowledge that the resulting service will almost certainly be available too late for any of them to use it.
Therefore, no team should intentionally build reusable services.
Additional Laws and Corollaries
- If you invest in improving someone else’s pre-existing service, you will create a reusable service.
- Creating a reusable service, be improving someone else’s service, will cost you more, up front, than writing a completely new one.
- The cost of maintaining a service increases proportionally to the number of consumers that use it.
Another additional law:
– The cost of maintaining a bunch of services increases proportionally to the number of services.
So, should we have some few reusable services that cost more per service, or should we have more non-reusable special services that cost less per service, but cost more just because there are more of them?
It is true, there is a "cost per service." I didn’t capture that in the blog. Good catch.
– The cost of maintaining a service increases proportionally to the number of consumers that use it.
The marginal increase in service maintainance cost for each additional user must decrease proportionally with the number of users, at least for some ranges of numbers of users. Otherwise a shared service is never worth building.
Hi Jane,
That depends on the service. For some services, reuse provides no direct cost benefit, but instead provides some other enterprise benefit. For example, it may be that a particular security service is "expensive" to own, but allows for consistent auditing, and the timeliness and accuracy of audit data is an important goal.
Reuse is rarely the primary benefit of SOA. The first and best benefit for SOA is flexibility. The second is often scalability. In my experience, Reuse is sometimes on the list, but often well below those two.
— N
Nick,
I wonder if the laws are specific to SOA, looks like they are applicable to software artifact reuse in general.
Thanks.
Nick,
I’m confused. Are you saying that eBay, Amazon, Google, etc. shouldn’t design reusable services? They’re clearly not builing them with a single predetermined consumer in mind….
Thanks,
Jeff
Nick:
hi,
>> If you invest in improving someone else’s
>> pre-existing service, you will create a reusable
>> service.
You mean someone is going to let you 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?
I have writen more comments here: http://www.ebpml.org/blog/123.htm
Hi Jeff,
Commercial service providers are using this axiom:
>>Any team building reusable services must build each one only after two or more people have asked for it, with full knowledge that the resulting service will almost certainly be available too late for any of them to use it.<<
When those services were designed, they took into account the needs of multiple requestors. The success of those services will depend on their reliability, customer service, and ability to meet many needs (breadth).
They did not meet the needs of immediate requestors. That much is a given.
Hi JJ,
Read your blog response to this entry.
I’ll admit that your statements appear to contradict themselves.
At one point, when discussing SOA approaches, you say:
"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"
Then you say:
"The second path actually has also a high probability of failure because it will grow to an unmanageable situation where nothing is reusable,"
So at this point, it looks like you don’t like JaBOWS.
Then, you say:
"JaBoWS is, IMHO, the path to SOA that has the highest rate of success "
Wow, JJ. That’s an interesting turnabout.
You suggest a "mitigating approach" that includes "just enough governance," versioning, and loose coupling.
May I suggest that this "mitigating approach" is fundamentally different from JaBOWS?
It is structurally different. Different people have to do different things during the development process.
It is informationally different. The minimum governance you suggest requires information gathering that is aligned to enterprise information models, not just projects.
It is infrastructurally different. There has to be code practices, and containers, and software support, in order to make that versioning strategy work.
Would you be willing to consider that there are not two paths, as you suggest, but three. Your "mitigating strategy" is really a different thing, a third way.
and a way that I support.
You have described, rather nicely, the notion of Middle Out SOA Architecture.
See… we agree after all.
— N
Nick:
thanks for your answer, it is really a question of where is the center of gravity of the middle out solution.
We agree, "reuse" implies a degree of coherence that goes beyond the boundaries of a single project. The question is really where do you reusable assets come from? What is the starting point?
a) a priori discovery of reusable assets
b) a posteriori investments to make an asset reusable
As you can see, there is no meet in the middle here. I think we agree, if you are not careful about what you do, both approaches will fail.
I know you are an EA, so you see a role for EA in SOA, but at the end of the day, EA cannot drive SOA, this is a solution architecture problem. EA can guide Solution Architecture, of course, but once the approach has been defined and refined, EA is out of the loop.
I am sure we can discuss for ever about the responsibilities of EAs and SAs in SOA, but wouldn’t you agree that the key is to disturb as little as possible the course of projects (funding, timelines, LOE, skills…).
I think this is true for any technology, not just SOA.
Nick:
Great discussion. There’s always tension between big requirements up front (BRUF), and getting something usable out the door quickly. The increased scope and murky requirements of enterprise SOA only raise the stakes in this debate.
I’m currently with a team that has produced a simple service model based on HTTP requests and RSS responses. The cost to create, combine and extend these services is comparatively low, encouraging a bottom-up approach to SOA.
I guess this puts me more in the JaBoWS camp, which is a long trek from my RPC, CORBA and RMI upbringing. But given the lessons from the Agile community, JaBoWS with iterative improvement may be the only cost effective way forward.
Hi Ralph,
I’m glad your team is being successful. Congrats.
I think we agree that the only way to make a service reusable is to start with a service and extend it.
Whether that makes you a JaBOWS service developer is a different statement. You appear to have accepted JJ’s argument that there are only TWO approaches.
I believe that there are THREE approaches. There is a JaBOWS approach which says "write whatever and hope it is reused" and then there is a Middle-Out approach that is different.
Middle Out is different because there are organizational differences, process differences, and infrastructure differences that are necessary to make it work. The fact that you have described two of those differences… (a) that you standardized on a single approach that empowers reuse, and (b) that you intentionally sought out an existing service for upgrade… makes me believe that you are using a Middle Out approach.
In my model, what you are describing is probably not JaBOWS. So why use that term?
So the problem is not that we disagree. It is that we are describing the same concept, and the same benefit, using two different words.
That is not disagreement.
"A rose, by any other name…"
— N
When I think about the word "service" I treat it as a high-level business service – looking for ways to represent the business level coupling fracture lines.
As such, these services aren’t really used and definitely aren’t reused.
I’ve put up a short blog post on the topic:
<a href="http://www.udidahan.com/2008/08/23/services-dont-serve/">Services Don’t Serve</a>
I’d assert that without capturing the business decoupling in such a way, and aligning the services you describe according to those boundaries, one would have little chance of success – even if they followed your pragmatic laws.
Your thoughts?
Hi Udi,
Great point. There are two uses of the word service to consider, and then there are multiple levels of abstraction.
First, Service Oriented Architecture depends on the notion of executable message endpoints. The originators called them services, but they could have called them anything. They selected that word, and it stuck.
At the same time, there were also good folks who were focused on an entirely different problem: aligning IT to business, who used the same word. They used the word ‘service’ to refer to the business services that a business offers. At this level, it is an abstraction of the capabilities of a business. ITIL adopted this use of the word ‘Service’ and ITIL is growing, so we can expect to see more of this idea.
As we take the thinking of ‘business capability’ or ‘business service’ internally, it is easy to see where the meaning blurs.
Inside MSIT, we had this problem, and we still do, but the term we agreed to use for a ‘business service’ that is NOT a messaging endpoint is ‘business capability.’ We do not use the word ‘service’ for the concept of ‘business capability’, even though a large number of folks are trained on the Microsoft Operations Framework (which is based on ITIL) and MOF does use that word. Alas.
Second issue, multiple levels of abstraction…
We have identified layers of ‘messaging endpoint services’ that are useful from an enterprise standpoint. Close to the end-user is ‘business process’ because, at the end of the day, every activity takes place in a process.
Services designed to support the specifics of a process are not reusable. Nor should they be. In one sense, you should ONLY create a ‘process-specific messaging service’ as part of an application design, and it is not valuable to share it, much less reuse it.
But services at this level need to get access to domain data and to perform transformations on that data. Depending on how your next layer is designed, you may be able to reuse those data services and perhaps even a few of the transformation / activity services.
Below that is a layer of horizontal services that are not tied to data but rather to consumption of infrastructure features. In this layer, services could validate credentials, assign hosting to a specific server, or generate e-mail from a template. There are many things that can be done at the horizontal level.
Both the domain level and the horizontal service level have services that can be reused. Services at the business process level cannot.
The rules above apply only to the domain and horizontal service layers.
Does that help?
— Nick
<Quote>
Reuse is rarely the primary benefit of SOA. The first and best benefit for SOA is flexibility. The second is often scalability. In my experience, Reuse is sometimes on the list, but often well below those two.
</Quote>
I love you… I can’t get it explained in my company. See also:
http://soa-eda.blogspot.com/2008/09/soa-versus-service-calls-short-story.html
-Jack
Dutch Railways
Nick,
I’d say that you are USING those lower level services/functions rather than re-using them.
Re-use is about repurposing an existing asset to be suitable in a different context.
In OO terms, calling a method on an object is "using" it. Inheriting from that object, overriding some of its methods, adding properties, that’s reuse – with all the dangers it brings with it (like versioning the base). There also is no clear boundary between the object and the inheritor. I can go on, but it’s fairly clear that taking the principle of reuse to services would go against the tenets of service orientation.
On the use of data transformation functions by multiple consumers, I’d see that being valid under one business service, but not across them. Each business service requiring its own view of customer, order, etc – not just data but behavior as well would make it infeasible to have a single CustomerDataAccessService across the enterprise.
Without understanding and explicitly modeling the higher level business services, I’m worried that will people misread the whole "reuse" thing of SOA and attempt the "1 entity == 1 service" fallacy. It is because of that danger that I espouse the business services approach in the hope that it will steer them clear of that fallacy. Once the strong boundaries of business services are in place, the use of lower level functionality by multiple consumers will be more or less OK.
If it’s OK with you, I’d ask that you add this broader context to your laws of SOA.
Thanks.
Hi Udi,
If I create a service during the lifespan of Project Alpha, which produces a system named Athens, and then, at some later day, I use that service again during the lifespan of Project Gamma, which produces a system named Galetia, then I have reused the service. It was used OUTSIDE of the context in which it was designed.
More interestingly, Project Gamma is quite likely to create a unique interface to the service, suited to the needs of the project. You appear to be comfortable with this idea when you argue against "the fallacy of 1 entity == 1 service," so I suspect that we are on the same page there.
When Project Gamma extends the service, creating a different interface to existing underlying mechanics, it would be difficult not to draw a connection to the OO concept of inheritance, with all of its concomitant problems.
In that case, I stand by my use of the word ‘reuse’ even though I also suggest, rather strongly, that holding up ‘reuse’ as a first order goal for SOA is a fools errand.
While I agree that the concept of 1 entity == 1 service is an antipattern, I’m not sure that I can see how your solution is effective in avoiding it.
My concern: I’m not 100% clear how you define a business service, and whether it is distinct from a business capability.
If your notion of a business service is similar to a business capability, then I would suggest that your attempt to tie SOA to it may not be successful and may, in fact, produce other antipatterns that are no less pernicious than the one you seek to avoid.
If, on the other hand, your notion of a business service is tied to a set of _features_ that software can provide, especially when associated with encapsulated business objects, process-based data transformations, and cross-team communication, then we are in complete agreement. In that case, the boundaries created through this notion can greatly aid in the partitioning of a SOA space. I have argued for that notion myself.
That lack of clarity on my part is my most important stumbling block to making the statement you seek in my blog post.
You are an excellent speaker and trainer, Udi, and I’ve had the fortunate experience of having attended one of your presentations. I believe that you are a knowledgable and intelligent man. That said, I simply do not know enough about your viewpoint to say whether or not I agree with you.
— N
SOA/REST/WOA [REST] What’s Missing in REST? RESTful JSON: Bringing REST and RPC Closer Together Malik’s Laws of Service Oriented Architecture Also read the response here and then all the comments back and forth above. Great dialogue. Technorati Tags: