As a community, we have sat silently by as the pundits have sold products that fail to deliver on the promise of SOA. We have watched, many of us in horror, as the goal of changing behavior, and changing infrastructure, has fallen victim to “yet another tool” to solve the same problem.
Don’t get me wrong. I don’t hate tools. For one thing, there are some tools that support Enterprise SOA*. Not many, but a few. Those tools understand that Enterprise SOA is not about building one service after another, but building the right services, and building them in a manageable and non-overlapping way.
What I hate is the notion that SOA can be reduced to tools; that you can introduce a tool and suddenly all the bad (human) behavior stops. I want to dispel that notion right now.
- If you take a group of well-meaning and intelligent engineers,
- and you give them a process that looks like a normal software development process**, and you train them on it, and they believe that this process works…
- and you add SOA…
- you get JaBOWS (Just a Bunch of Web Services).
I did not invent the term “JaBOWS.” Near as I can tell, Joe McKendrick did, a couple of years ago. However, I am taking it one step further. I believe that JaBOWS has specific causes and can be specifically avoided. Not just with an executive sponsor, as Joe suggested back in 2005, but with a comprehensive Enterprise SOA transformational program, an approach designed to create a reusable infrastructure.
Failing that, companies that invest in SOA are getting tripe, and the entire goal of achieving Enterprise SOA takes a hit. We all lose when any one company kills their SOA initiative for lack of value. In the SOA community, we are all invested in the success of each company that has bought the hype. If we sit quiet, well before those initiatives fail, then we have no right to come back, two years from now, and say “well, it failed because you didn’t do it right.” Or worse, “if you do it again, we can show you how to get value.” That Ain’t Gonna Happen.
As a community, we have to do a better job of defining what it means to build an Enterprise SOA*.
In Microsoft IT, we are using something we call “Solution Domain Architecture” or “SDA” to build an approach to services that, we hope, will result in the creation of an Enterprise SOA. SOA is the benefit, SDA is the way to get there. And the reason to use SDA: to avoid JaBOWS.
In order to force that growth, and leave the bad behavior behind, we have to declare war on JaBOWS.
JaBOWS is the dead end that kills value. It is all that is wrong with top-down approaches that produce unusable services, or bottom-up approaches that produce overlapping and badly coordinated piles of services. JaBOWS is the costly, time-consuming, valueless exercise that so many companies have taken upon themselves in the name of SOA.
Join me now. Join me in decrying the creation of piles of useless and valueless noise. It doesn’t matter if it can be discovered, or governed, or built quickly, if it is not reusable. It doesn’t matter if it is built on WS* or leverages the best security protocol on the planet, if it is not decoupled correctly.
Join me by writing about JaBOWS, and talking about JaBOWS, and sharing experiences about how to effectively avoid JaBOWS. Join me by sharing what is wrong with building too many things, none of which are actually usable outside their original context. Join me, by discussing the processes by which developers build the right systems, not just the tools that we need to buy and the interface standard we need to adapt. None of those solve the problem.
It’s not a tools problem. It is a process and people problem.
Tools + existing processes = JaBOWS. And that is baaaaaad.
* Enterprise SOA goes way beyond “making two apps talk using a web service interface.” It is a systematic approach to developing an Enterprise-wide Service Oriented Architecture that actually allows information, process, and functionality to be composed in new ways, ones that were not foreseen by the authors of the services. Until you have this, Web Services are just “interoperable COM.” Without Enterprise SOA, you have JaBOWS.
** I am including agile development here. There is nothing in Agile methods that makes the problem worse, but there is nothing that makes the problem better, either. If you say there is, tell me what agile book, on what page, aligns the agile manifesto with Enterprise SOA development. I have all the books right here.
PingBack from http://msdnrss.thecoderblogs.com/2008/03/17/jabows-is-the-enemy-of-enterprise-soa/
PingBack from http://msdnrss.thecoderblogs.com/2008/03/17/jabows-is-the-enemy-of-enterprise-soa/
PingBack from http://msdnrss.thecoderblogs.com/2008/03/17/jabows-is-the-enemy-of-enterprise-soa/
You are dead on when you stated that, "It’s not a tools problem. It is a process and people problem." I just wrote a post claiming that the problem with SOA is not SOA itself, it is people who don’t understand SOA.
http://blogs.ittoolbox.com/eai/madgreek/archives/why-doesnt-anyone-understand-soa-23102
I can’t help but think
"No Silver Bullet"
Great post, Nick. And I couldn’t agree more. 🙂
I think 10 years from now we’ll look back and recognize that a lot of what we thought was SOA was actually JaBOWS, serving narrow, tactical needs. And that this hurt perceptions about what SOA could really accomplish.
-Joe
Thanks, Joe.
Nick:
you are dead wrong when you claim it is not a "tools" problem. It is only a tools problem is not until we will move millions of developer from a Synchronous CRUD-Oriented Client/Server programming model to an Asynchronous Inter-action Oriented Peer-to-Peer programming model that then we will reach the level of enterprise SOA.
Today people do JaBoWS just and only because it is enforced by the consumer side programming model. It has nothing to do with people and process, and only with tools. The day we will smash MVC, Object Orientation and ER as the foundation of the application architecture, that day only, will we be able to create an enterprise SOA.
Very true. The same was true for structural analysis and later for OO. All that stuff gets always oversold claiming that it would solve all the problems easily and create maintainable products quickly. But as we know there is not an easy solution to a complex problem. It requires careful engineering and knowing a specific environment. Methodology can obviously help but a lot depends on experience of people.
I am actually very pleased hearing that.
Hi JJ,
I know how fond you are of Service Component Architecture (SCA). I like SCA but introducing SCA will not solve the JaBOWS problem. It will be just as easy to create the WRONG async services tomorrow as it is to create the WRONG sync services today.
SCA is not that innovative. It is good, but you can build async services today, with Biztalk or an ESB product. I like SCA, but it doesn’t solve the problem I have raised here today.
I know you care about SCA, but it is not a silver bullet. SCA does not solve every problem.
Especially not JaBOWS.
Nick, yes, it is true that SCA promotes an AIOP2P programming model, it is also true that one could come up with a better technology -no doubt about that.
But what I am really talking about is at the EA level: People, Process and Technology (tools).
How can you expect that "People" and "Processes" would change while they have been optimized for the current programming model ("Technology")?
You are fighting 40 years of evolution. You are recommending an unnatural, therefore unlikely, change. It is not until the programming model will change that "People" and "Processes" will be re-engineered to reach new levels of optimization in relation to this new "Technology".
At the end of the day, thinking that "tools" are adequate today is a bit of a stretch. I urge you to consider the argument that "it does not matter how many times you say interoperability", that’s still not going to give you Service Orientation. Web Services Annotations on a CRUD-Oriented programming model are simply equal to XMLized remoting. Service Orientation is about enabling an AIOP2P programming model, whether you use SCA or not is just a technical detail.
The key concepts of an AIOP2P model are: bi-directional interfaces, orchestration and assemblies. (WSDL,BPEL,SCA) is definitely a match, but again I am not caught up on it. Loose(r) coupling can
be achieved with technologies such as XML and SDO.
Incidentally, one of the major contribution of SCA is to add bi-directional interfaces and orchestration to traditional programming environments (Java, C++) in a non invasive way. So in itself, SCA has enabled the emergence of an AIOP2P programming model across the programming landscape.
So overall you are correct in saying that "SCA" is not the solution to Jabows, but by far it opens the door -and I don’t know any other technology today that can claim that- to go passed beyond Jabows and focus on "inter-actions".
Hi JJ,
Looks like we agree on two key points:
Enterprise SOA is about building a distributed Service Oriented ecosystem, not about a particular technology.
The current technologies make it difficult to build services well, and we want to build services well. SCA helps by making it much easier for developers to build services that are async, bi-directional, etc.
Let’s set aside those key points, shall we?
I’d like to establish one more detail. It’s a nit, really, but important nonetheless.
In Enterprise Architecture, you cannot change any of the three sides of the Iron Triangle without affecting the other two. The Iron Triangle is Information, Functionality, and Process.
You asserted that EA’s triangle is "People," "Process," and "Technology." Not so. People are part of Process, just as technology is part of functionality. Information is the third leg of the EA Iron Triangle.
You did make one statement that I’d like to replay, but I’m going to change a few words… let’s see if you still agree.
You said:
>>How can you expect that "People" and "Processes" would change while they have been optimized for the current programming model ("Technology")? <<
We agree that the call-and-response programming model is suboptimum, and that we should build systems in a different way.
So if I replay your statement with a few words changed, would you still agree with it?
>>How can you expect that "Information" and "Processes" would change while they have been optimized for the "synchronous, call-and-response" programming model ("Functionality")? <<
You will notice that I took out the notion of "current" model. I don’t agree that the "call-and-response" model is current. I think that it is outdated and obsolete. I hesitate to call that the "current" model, although it is clearly the model that the people and processes are oriented towards.
You will also notice that I replaced People with Information in order to align with the EA Iron Triangle.
So, if you agree with my rewording of your question, I’d like to answer it:
Answer: How can I not?
Through the introduction of ESB’s and Biztalk and Event Driven SOA, we have already changed the functionality. The CURRENT model, the one we have been adopting for 10 years, is that of an async distributed interaction model.
However, the information and processes are still tuned to the synchronous model, and bottom-up silo thinking. It is not the synchronous model that causes JaBOWS. It is bottom-up silo thinking.
That doesn’t mean that we shouldn’t continue to innovate on functionality, including innovations like SCA. However, SCA cannot solve the JaBOWS problem because it does not address bottom-up silo thinking.
And therefore, to adopt Enterprise SOA, whether using SCA or not, we must change the information and the processes of software development, deployment, and governance.
The change in the tools to SOA is already sufficient to require us to change the other two. Going forward, as we change the tools, we will need to again change the processes.
JaBOWS is not a cause… it is an effect. The cause of JaBOWS is that the information and processes support JaBOWS, even when that is a suboptimal thing to support.
Introducing SCA will not change the information or the processes. The information and processes have been changed already, without the introduction of SCA. Therefore, introducing SCA is not a prerequisite to fixing the problem of JaBOWS.
Thanks Nick, this is a great discussion.
>> Looks like we agree on two key points:
>> Enterprise SOA is about building a distributed
>> Service Oriented ecosystem, not about a particular technology.
Yes, of course
>> The current technologies make it difficult to build
>> services well, and we want to build services well.
Yes
>> SCA helps by making it much easier for developers >> to build services that are async, bi-directional, etc.
Yes, but I would not claim we are there yet. Again, I’d like to restate that if tomorrow Microsoft came with a much better composition technology, I’d be the first one to talk about it. Recently for instance, I have been really impressed at how Oracle is using SCA in its SOA Suite 11g. It goes beyond SCA, while building on the foundation of SCA.
>> Let’s set aside those key points, shall we?
Yes, I truly think the agreement has to be technology neutral, this is an architecture problem (Elements and Relationshipts) not a technology problem (transport, protocols…)
>> I’d like to establish one more detail. It’s a nit,
>> really, but important nonetheless.
>> In Enterprise Architecture, you cannot change any
>> of the three sides of the Iron Triangle without
>> affecting the other two. The Iron Triangle is
>> Information, Functionality, and Process.
In my world, EA does not own Information, Functionality and Process. Information is the property of “Core Data”, Process is the property of the “Lean Six Sigma” team and functionality is directed by the business. I could get shot in one instant if I had the good idea to tell the business how they should run their business. I don’t how Microsoft’s EA is structure, but you are surely lucky to own this kind of things. My view of EA’s responsibilities is again “People” (as in roles and skills for developers, architects…), “Process” (as in delivery methodology) and “Technologies” (as in OSes, HW, Containers, Integration…)
>>You said:
>>>> How can you expect that “People” and “Processes”
>>>> would change while they have been optimized for
>>>> the current programming model (“Technology”)? <<
>> We agree that the call-and-response programming
>> model is suboptimum, and that we should build
>> systems in a different way.
Great !!
>> So if I replay your statement with a few words
>> changed, would you still agree with it?
>> How can you expect that “Information” and
>> “Processes” would change while they have been
>> optimized for the “synchronous, call-and-response”
>> programming model (“Functionality”)? <<
I am not sure “Information” and “Processes” are related to Synch-call and response. The way information is stored and processes are implemented is, but not the information itself and the process definition themselves.
>>You will notice that I took out the notion of
>> “current” model. I don’t agree that the
>>”call-and-response” model is current. I think that
>>it is outdated and obsolete. I hesitate to call
>>that the “current” model, although it is clearly the
>>model that the people and processes are oriented
>>towards.
But that’s what millions of developers and architects are doing every single day of their lives. This is ASP.Net, this is Struts/JSP/EBJ, 99% of the technologies on the market are aligned with this model.
>>You will also notice that I replaced People with
>>Information in order to align with the EA Iron
>>Triangle.
>>So, if you agree with my rewording of your question,
>>I’d like to answer it:
>>Answer: How can I not?
>> Through the introduction of ESB’s and Biztalk and
>>Event Driven SOA, we have already changed the
>>functionality. The CURRENT model, the one we have
>>been adopting for 10 years, is that of an async
>>distributed interaction model.
No this is incorrect, EAI (and BizTalk) is about “synchronization”, even when you do it in an EDA way (not a batch way). I am the first one to say that BizTalk put orchestration on the map with XLang in 1999 (almost 10 years !). But BizTalk never developed a composite programming model. They focus on an integration model (this is where the market was, I am not blaming anyone). I talked at length with Steven Goulet in 2003 about this topic that the future of BizTalk was a composite application model blended with .Net, but he dismissed this idea.
BizTalk has evolved instead to become a “store-and-forward” based integration platform with all the “intelligence” in the middle. You can admit that there are better composition mechanisms.
>> However, the information and processes are still
>>tuned to the synchronous model, and bottom-up silo
>>thinking.
Again, I don’t think Core Data or the business is influenced by our synchronous model. At least, I don’t see that influence in our logical data model or process definitions.
>>It is not the synchronous model that causes JaBOWS.
>>It is bottom-up silo thinking.
Again, I think the programming model is the cause of the silo mentality, no the effect. I don’t think people wake up in the morning and think, I want to build this in a silo today. If you have no composition technology, you have no other choice than “replicate and synchronize”, because you can’t get at the business .
>>That doesn’t mean that we shouldn’t continue to
>>innovate on functionality, including innovations
>>like SCA. However, SCA cannot solve the JaBOWS
>>problem because it does not address bottom-up silo
>>thinking.
I think this is the heart of our disagreement. The silo mentality goes away as soon as you can reuse logic and data wherever it is. Again, please believe me, if Microsoft comes up with something better than SCA, I’d be the first one to cheer (you can also adopt SCA). It is simply undefendable today to claim that you don’t need a service composition technology. There is nothing wrong with Bottom-Up, Top-Down, or Meet-in-the-Middle. They all make sense. What does not make sense is “replicate (data and business logic) and keep synchronizing them (data and business logic) as they change on one side or the other”. THAT is insane.
>> And therefore, to adopt Enterprise SOA, whether
>>using SCA or not, we must change the information and
>>the processes of software development, deployment,
>>and governance.
Now you lost me, I thought you were talking about “business” information and processes.
>> JaBOWS is not a cause… it is an effect. The
>>cause of JaBOWS is that the information and
>>processes support JaBOWS, even when that is a
>>suboptimal thing to support.
Again, we agree this is an effect, but not of the information and processes, it is an effect of the programming model. You can’t change 40 years of evolution in solution delivery by keeping the same programming model.
>>Introducing SCA will not change the information or
>>the processes. The information and processes have
>>been changed already, without the introduction of
>>SCA. Therefore, introducing SCA is not a
>>prerequisite to fixing the problem of JaBOWS.
Again, SCA allows me to build services that expose a bi-directional (hence composable) interface and manage long running inter-actions (BPEL). These services are highly reusable (especially via the concept of a mediator component introduce by Oracle). If they are ‘highly reusable” because of their shape and the technology that allow me to compose them, then I am not building a bunch of JaBoWS, I am building enterprise services.
So I still think it is hopeless to go the “methodology” route without overhauling the programming model. This evolution is inevitable because “reuse” makes economical sense, it is just we never understood how to do it without technologies like XML/XSD, WSDL, BPEL and SCA. Reuse makes economical sense because it allows the creating and operation of IT assets where the cost is the lowest. This is what I call “right-sourcing”. Microsoft can come up with it own, it can even be better. I welcome it. Competition is good. But ignoring will be deadly, make no mistake.
http://maxtechtalk.blogspot.com/2008/03/jabows-yam-jaboms.html#links
Maybe the problem has to do with the SOA concept (hype). SOA is often proposed as a solution before companies have a clear understanding of their problem. Companies are starting SOA initiatives instead of "Solving a problem x project". This doesn’t make SOA the means to the end that it should be. Combine this with a vendor pushing its expensive integration product and consultants and all the ingredients for an expensive not very successfull project are in place. I think this kind of technology/concept push, can better be replaced with small sized low tech projects that tackle practical integration problems. SOA should be in the back of your head as a concept for solving problems.
Man these projects with your own employees (not with expensive consultants like me) until they get a thorough understanding of your integration problems.
After that buy an expensive product and hire me 🙂
Nick, JJ,
A very interesting discussion, but…
The issue here goes far beyond tooling. No matter how good your tooling and programming models are, if your services are not aligned with the enterprise business model and semantic, you will still end up with JaBoWS. The issue here is that SOA is a business problem, that we are trying to attack as a technology issue.
Regardless of the technology used, bottom up approach to SOA leads to JaBoWS. Top down design can and should improve situation, but majority of practitioners considers it too complex and expensive.
We are still cought up in an application centric mentality and a result have even invented a term application services. Untill we start considering SOA as a true enterprise undertaking JaBoWS will continue to rule the world.
Hi Boris,
My point exactly. That is what SDA does. It’s good to know that someone gets it.
— N
Hi Joris,
Hate to say it, friend, but your prescription treats a different disease. Good advice, but doesn’t solve for JaBoWS.
— N
I am glad you accept that web services are better than COM, EJB, or CORBA for interoperability. Thus, they are better than what came before, by being a message oriented enterprise integration strategy. I am generally of the mind that most claims of any greater benefits of SOA just confuse things and waste money. Fowler’s concept of Service Oriented Ambiguity lives on. [ http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html ]
What is it in non "Enterprise SOA" web services that prevents them from being "composed in new ways, ones that were not foreseen by the authors of the services"? Why can’t Enterprise Architecture just coordinate the bottom up creation of services to increase the probability of future reuse?
The pendulum is swinging back to making IT simpler…by focusing on the user experience, by dealing with the fact that so-called enterprise technology is starting to trail consumer technology in capacity, availability, usability.
Take a step back and think about the business value of what you are providing- not some ridiculous concept of "alignment" that people bring up, but how you can use IT to bring money to the organization, or, if you can’t, make it cost less. If you aren’t tracking back to one of those objectives- get out of the way.
Hi Matt,
1) Alignment reduces IT spend by 10-12% yoy project spend.
2) Building a service layer that produces semantic consistency cannot happen bottom-up. Without semantic consistency, services cannot be reused at any kind of scale. Every app creates new services. Complexity flourishes.
3) I estimate that, in a sufficiently complex environment, building a consistent service layer and then, over time, moving front end apps to the same, will reduce the app portfolio by as much as 30%, and will reduce the complexity of the ecosystem by 20%. Complexity begets cost.
I have business goals, my friend. This is not about WS vs. COM.
— N
Hi Nick,
How about an action plan for this. I totally agree with you, if we don’t pipe up now, we might as well pack our bags.
Here’s what I am suggesting:
1. Find ways to publicize/evangelize the current state of the art in the industry – JaBoWS 1 – SOA 0. I am really disappointed that even the super-smart analysts are sugar-coating the truth and still talking about SOA success stories – not sure based on who’s metrics (sure as heck not mine!).
2. Publicize, evangelize and educate (and I would like to get educated myself!) the huge differences between the 2.
3. Define processes and methodologies to actually start building SOA – start with the business process, go through proper analysis and modeling, DO NOT re-write APIs into Web Services, look beyond your silo, etc., etc. There’s more than enough smarts out there to put this together easily.
4. Try to keep track of the real success stories, to regain the respect for SOA.
What do you think?
hb
An interesting post. I agree that "Enterprise SOA" is a goal, and JaBoWs is a diversion at best dead end for many. I however see "Enterprise SOA" somewhat differently [ http://blogs.sun.com/RealSOA/entry/soa_governance_defined ] – as an architectural style that provides and facilitates evolution of enterprise IT towards a network of Enterprise Services. I know that sounds a bit trivial, however if one goes further and defines Enterprise Service is a self-contained component delivering business functionality combined with an extendible set of non-functional, policy-driven qualities it becomes clear that the main difference between E~SOA and JaBoWs is Governance.
Another way to look at it: Enterprise Service is a a service who’s name would be familiar to the CEO and (s)he knows and cares about what it does. In other words whereas "services" are mere digital artifacts, Enterprise Service are true business assets, and SOA governance (when properly done) turns the former into the latter. Then throw out *reuse* for the sake of *responsible reuse*, add some virtualization and refinement [ http://blogs.sun.com/RealSOA/entry/service_refinement ] capabilities (because it you strive to design your service for all the uses across the enterprise – bottom-up or top-down you will never get it done) and enterprise SOA becomes a piece of cake.
and yes, tools do not matter that much as long as they allow you to do all of the above 🙂
Hi Alex,
You assert three concepts here:
1) Enterprise SOA as an architectural style
2) Enterprise SOA = Enterprise Service + Design governance
3) Enterprise Service = Understandable digital business asset
Question: Does the design governance that you are asserting in #2 above REQUIRE adherance to an enterprise wide information model?
You use the term “non functional quality” and it makes me think you are describing what we call System Quality Attributes. While I agree that the only rational way to insure enterprise class quality is through governance, I am concerned that your definition appears to stop there. To me, alignment to a common information model, as difficult as it may be to create, is imperative if we are to get semantic interoperability.
And, in my opinion, the best and most promising avenue for attacking the scourge of JaBoWS is via semantic interoperability.
Do you include issues of Semantic interoperability in your understanding of Enterprise SOA?
— Nick
Hi Nick,
thanks for a very thorough response – it’s probably the most detailed and relevant I ever got. Naturally, I could not resist the temptation to answer, but my reply quickly grew past what’s reasonable for a comment in both size and scope, so I decided to post it here: http://blogs.sun.com/RealSOA/entry/to_or_not_to and put these trackbacks in both comment streams.
And for the record: I agree with your agreement 😉
I’m always a bit worried when someone has "the answer." Lot’s of red flags go up when someone tells me:
Let’s assume that every problem worth solving has a cause. Interesting assumption. Reality: Any one problem
I just came across this post and found myself in agreement with most of your points. Just creating a service and exposing it for people to use doesn’t mean you have a working SOA program. Tools do not solve the problem of SOA but people and processes do. Tools provide support for the strategies, processes, and policies that people put together. However, no single tool or a suite of tools will provide a complete SOA or EA solution. A lot of manual processes will still be required. The key to a successful SOA program is governance. Without it, you will end up with JaBoWS.
I also wanted to add to the discussion on SOA and agile development. I actually explore this topic in depth in one of my posts: http://leoshuster.blogspot.com/2008/05/soa-agile-software-development.html. I strongly believe that agile development is one of the worst things you can do to your SOA program.