THE SOFTWARE SIMPLIST

Web Services Wisdom.

May 2006

The future of OO analysis and design has been called into question in the new services landscape. Join host Udi Dahan for an in-depth analysis on objects, services, and everything in between. (MP3, 10:14 mins.)

The recent hype around SOA has raised questions around the continued validity of object orientation. Although there is consensus around the fact that object-oriented languages (like C# and Java) are here to stay, the continued use of object-oriented analysis and design in the new service landscape has been called into question.

Podcast online here.

Posted by Udi Dahan at 02:30 PM  Permalink |

In the comments of my first entry (Hello World), Bill Rogers asks:

“In general, how would you explain the relationships (if any) between Master Data Management, Service Oriented Architectures and Business Process Management. To my mind these three "buzzcronyms" are linked; in that MDM can foster better SOA which in turn may enable better BPM. As such they should be considered a tripartite "whole" instead of individual initiatives and are in order of precedence in order for the success of that "whole" to be realized.

Would you agree or disagree?”

Well Bill, I’d say that in order to have a fruitful discussion on the topic, these terms need to be better defined, or rather, there needs to be more consensus on what their definitions are. I’ll try to stay within the well accepted boundaries of the terms MDM and BPM while giving my take on SOA in each context.

Most of the discussions around Master Data Management are based on a data-centric view of the enterprise. As such, the goals that are common in data-centric analysis, like normalization/removal of duplication, are scaled up. My personal view on MDM is that its data warehouses all over again, just marketed differently. After looking at the underlying messages of MDM, I’ve found overwhelming similarities with those present on data warehouse initiatives. That’s not to say that they’re the same, only that many of the DB-level practices seem to have been upgraded to enterprise guidance. Personally, I don’t see the relevance, so I’m not much of an advocate of MDM, regardless of SOA or BPM. (In which case I disagree with your above statement :) )

BPM is very interesting entirely on the business level even before we tie it to anything technical. I believe that enterprises can gain quite a lot of value, or at least reduced waste, by better understanding their business processes. Once these processes are understood and documented, then they can be mapped to the existing (and currently under development) IT landscape and a gap analysis can (and should) be performed.

But at the technical level, I think that the use of services as a unit of abstraction is extremely valuable for implementing systems that support the above business processes. However, that discussion is long enough to warrant its own post.

Posted by Udi Dahan at 05:59 PM  Permalink |

In the comments of my first entry (Hello World), Dennis Kornbluh asks:

"So Udi, what do you think of Enterprise Service Buses for SOA apps? What is there to gain with an ESB, other than complexity?"

Well Dennis, I've written quite a bit on infrastructure needed for SOA - what I call a Bus, but we really need to focus our examination on two major contexts: a single distributed system, and integrating multiple, existing systems (EAI).

Articles on the Bus:

1. ESB—What's a "Bus" and Why Should I Care?

2. Is that all a bus is?

3. Location transparency, SOA, & ESB

Another very interesting article on the subject comes from Nick Malik, Jacob and the Data.

However, infrastructure is hardly enough.

In order to "reap the benefits of SOA" (how many times have you heard that from vendors?) you need a good partioning of services.

OK, enough vendor-speak.

There are basically two major contexts to talk about services and SOA:

The first is a distributed system, the important thing being that it is a single system. Often the system is under development. This is a common scenario which often is the result of jumping on the SOA bandwagon. In this context, what we are partioning into services is the system.

The second context can be best described as integration of existing systems/applications - what's been called EAI. In this case, it isn't really clear what we're partioning. Does this mean that this context will not benefit from employing SOA? In a word, no. In two: hell no.

While each context is probably deep enough to fill a number of books, the important thing to understand is that a bus may be used differently in each. Much of the functionality being put into ESB products is to better support the second context. The reason more "smarts" are going into the "network" is the desire to leave the current applications alone. That still doesn't make it the right thing to do.

So Dennis, I'm sorry I can't give you a shopping list of benefits, but if you use the Bus architectural pattern and do your technological mapping appropriately, I'm sure you'll find a number of improvements in many areas. If you'd like to send in a concrete example, I'd be happy to show you how to model it using the Bus pattern.

Posted by Udi Dahan at 03:34 AM  Permalink |

One of the technical advantages touted by SOA proponents is that it will result in looser coupling between systems/services. Of course, they haven't agreed among themselves what a service actually is so that statement is kind of amusing. In fact, loose coupling has become something of a buzz word in its own right. The only reason more people aren't talking about it is that it had the misfortune to come out roughly around the same time that SOA did.

So, what is this "coupling" thing and why does it matter so much?

Coupling is a pseudo-technical term used to measure the subjective inter-connectedness of two things. Loose coupling meaning that the two things aren't very inter-connected. Inter-dependence is another way of looking at it. If we have two things, A and B, and A cannot function without B, then we can say that A is coupled to B. Of course, this does not necessarily mean that B is coupled to A.

And the reason this matters has to do with money. In the previous example, if I find a bug in B and fix it, that might cost me X. However, later I find out that A began to malfunction as a result of that bug fix, possibly code in A depended on the buggy behavior of B. Now the cost has increased: the cost of the malfunction of A, the cost of finding what's wrong in A, the cost of fixing A, and the cost of rolling out the system again need all be added to the original cost of fixing the bug in B. All this would remain true if we were talking about changing or enhancing B's functionality - the bugs would only pop up in A.

Therefore, it is clear that making any kind of changes to a system whose elements are tightly coupled will cost more than making those same changes to the same system designed of loosely coupled elements.

The cost stated above don't take into account the cost of time - lost opportunities in business. In this day of business reliance on technical infrastructure, the business can only be as agile as its infrastructure. Meaning that coupling has a direct impact not only on the bottom line, but on the company's tactical and strategic capabilities.

Of course, coupling can't entirely be done away with. Business needs to have data from Sales available to Marketing, and so the corresponding systems need to work together. Coupling is as inherent in technical systems as it is in business. However, different application-level communication protocols have different levels of coupling. If, for the simplest piece of data, system A needed to access ten different parts of system B, instead of one, that would increase the dependence of A on B. It is this that we must strive to minimize in our technical architectures.

Posted by Udi Dahan at 05:23 PM  Permalink |

Hello world, and welcome to the blog where readers get their questions on SOA and Web Services answered. This is your host, Udi Dahan, bringing you the cold, hard facts you need to make decisions about SOA. I am “The Software Simplist”, helping you Keep It Simple.

For those of you who don’t already know me, let me take a minute to introduce myself.

I’m a Microsoft Solutions Architect MVP, .net development expert, and SOA specialist. When I’m not writing or speaking at conferences, I pay the bills as the Chief Architect of KorenTec, a software solutions provider in Israel specializing in the architecture and design of large-scale, mission-critical systems for the enterprise and government sectors.

Those of you who do know me from www.UdiDahan.com will be happy to hear that I will continue blogging there too. I will be cross-posting SOA and Web Services content, while the usual stuff will stay on my home site.

What can you expect to see here?

Well, just about everything around what I think about SOA. This includes Web Services, XML, business architecture, technical architecture, design, and implementation. There really is a lot to say, and I'm not one to mince words :)

What I won't do is regurgitate vendor-sponsored techno-marketing babble and try to dress it up by adding all sorts of version numbers to it. What I will do is try to give you my honest views, opinions, and experiences from the real-world projects I've been on. Loose coupling is possible and not technically difficult. The real difficulty lies in changing the way you think about distributed systems.

Are you willing to swallow the red pill?

Remember, all I'm offering is the truth. Nothing more.

Anyway, my version of the truth - that would be Truth 3.2, meaning the second revision of my third epiphany.

Posted by Udi Dahan at 04:17 PM  Permalink |