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.
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/
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".
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