Jaa

Malik's Laws of Service Oriented Architecture

  • Artikkeli
  • 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.

Comments

  • Anonymous
    August 21, 2008
    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?

  • Anonymous
    August 22, 2008
    It is true, there is a "cost per service."  I didn't capture that in the blog.  Good catch.

  • Anonymous
    August 22, 2008

  • 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.  

  • Anonymous
    August 22, 2008
    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

  • Anonymous
    August 22, 2008
    Nick, I wonder if the laws are specific to SOA, looks like they are applicable to software artifact reuse in general. Thanks.

  • Anonymous
    August 23, 2008
    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

  • Anonymous
    August 23, 2008
    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

  • Anonymous
    August 24, 2008
    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.

  • Anonymous
    August 24, 2008
    The comment has been removed

  • Anonymous
    August 25, 2008
    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.  

  • Anonymous
    September 03, 2008
    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.

  • Anonymous
    September 03, 2008
    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

  • Anonymous
    September 05, 2008
    The comment has been removed

  • Anonymous
    September 06, 2008
    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

  • Anonymous
    September 09, 2008
    <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

  • Anonymous
    October 12, 2008
    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.

  • Anonymous
    October 12, 2008
    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

  • Anonymous
    February 03, 2009
    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: