ESB Bashing Continues

I'm not sure what has started this latest round of ESB bashing but here is ZapThink's take on the ESB. I was okay with the article until I got to this part.

From ZapThink's Jason Bloomberg

In particular, it is essential to take a process-driven approach to your infrastructure, instead of an integration-centric approach. Remember that building Service compositions that implement processes typically compose capabilities across multiple execution environments. Furthermore, those compositions are both dynamic and unpredictable -- the business process specialist in charge of the compositions may change them around long after you've deployed the Services. Governance becomes the key to managing that unpredictability, rather than pre-defined integrations.

Business users creating dynamic composite unpredictable applications based upon services you have deployed. I think this is where SOA starts getting the Ivory Tower reputation. I really don't believe that 99.9% of organizations will or even should attempt to achieve this. I think before you propose something like that you should have some details on how you would accomplish it. Show how your service design could so flexible and robust to account for unknown variations on how it is composed without compromising your companies critical data and infrastructure.

My next issue came with this part.

One essential point here is that SOA leverages interoperability more so than portability. In a virtual machine-based "write once, run anywhere" environment, whether Java or Microsoft Common Language Runtime (CLR)-based, distributed computing relies upon the portability of code. SOA, however, leverages the interoperability of the Service interfaces so that you don't need to move the underlying Service implementations around. As a result, running all your Services on the ESB can actually impede your SOA implementation, rather than support it.

I don't disagree with a distributed service environment but again one size doesn't fit all. Managing a distributed service environment is not easy and in fact can also impede your SOA implementation. Extremely strong governance is a must in that type of environment. The fact is some organizations are better suited for a centralized bus approach and there is nothing wrong with that.

The last issue is on messaging. Here is the quote:

So, only use the traditional messaging middleware capabilities of your ESB if you really need them, and only leverage the Service runtime your ESB provides when convenient, but configure your ESB as an intermediary to get full value out of it as part of your SOA infrastructure.

There really isn't any detail here to explain the thought on why messaging is bad. Does it mean all messaging including SOAP based messages? Or is it just targeted at the built-in messaging most ESB's provide? Either way I don't follow. Messaging is very powerful and robust. Given the state of most Web Service development I have seen, more traditional messaging can be a powerful alternative. Remember that a service is not a technology specific thing, right?

The article also had a lot of strong points in my opinion. In particular this is a good quote to reiterate.

The bottom line is to always remember that the business drives the architecture, and the architecture drives the technology. Don't let the technology drive the architecture! SOA is particularly adept at abstracting existing technology, which can include recently purchased products in addition to your legacy environment. But knowing which of your existing capabilities to leverage -- and which to forego -- can make or break your SOA initiative.

IT has been known to go out and buy technology and then go looking for a problem to solve. To the point of the article knowing when to leverage your existing technology is very important. That can be an existing ESB though and that's okay.

SOA Implementation

Since this blog is called the The Grey Lines I would be remiss if I didn't point out the greyness in Joe McKendrick's latest post on ESB's. I certainly understand where Joe is coming from but this is one of those grey areas. SOA is not about the technology, I think that has been beat to death by now. However developing a service and implementing it still requires technology. I'm doubting the enterprise in question chose the ESB route simply for the one project.

There is the belief out there in the distributed nature of an SOA style of implementing services ie location independence, technology agnostic etc etc. I don't disagree with that and designing services should certainly take that into account. However in the enterprise decisions have to be made on technology implementations. The fact is one size does not fit all. While one enterprise may go to distribution (very strong governance needed here) another may find a more centralized platform (governance still needed but not as strong) works better for them.

Decisions have to be made every day in the enterprise that involve compromise. It's just the nature of the beast. I think understanding how your own enterprise functions is a key to picking the right implementation strategies. I know most folks would say SOA is not about the implementation but ignoring it will lead to disappointment with your SOA style of architecture.

Service Versioning

Todd Biske pointed out this article by Surekha Durvasula on service versioning. It's a good article and something to give some thought to. Believe it or not you will have the opportunity to have more than one slightly different implementation of the same service. It's not something I really bought into a while back but I have seen the value first hand.

There are some other low level reasons for versioning services as well which have to do with your schema design ie namespace management and your xml schemas. I'll return with more detail on that in a later post. XML schema design and Web Services is an area lacking in attention in my opinion. Doing it correctly is really the foundation of a good service.

Do you need a really expensive governance product to do service versioning? No not really. As long as you have a policy that is defined and manageable, you are on the right track.

New Blog

I've retired the Darth.Net blog and started The Grey Lines. The main reason behind the move was to take advantage of more features that Blogger allows when hosting with them. Check out the poll on the right hand side of the screen.

What about the name? Well other than the ever increasing grey in my hair it really has more to do with discussing things that are not always black and white. I think most people would agree that the world and it's issues, both technology related and not, are not black and white. Surprising though I don't find reasonableness in opinions to be the norm anymore. It seems to be either side a or side b, wrong or right. It's as if we have made everything into a team sport with winners and losers. Take a look at our current American Presidential race if you don't believe me.

It's my hope that I can talk or have conversations about things (technology or not) that have caught my attention or interest in a way that is both objective and reasonable. How difficult is that to do? It's extremely difficult. I find it a constant challenge to be objective more often than not. Objectivity requires patience, mindfulness and letting go of the ego. These qualities are not always easy to come by. So let the experiment begin.

Experts: 'Indiana Jones' pure fiction - CNN.com

Experts: 'Indiana Jones' pure fiction - CNN.com Okay everyone have the collective... duh. What would we do without experts. Well we apparently can't take a whip and pistol while raiding archaeological digs and shoot wrath of God beams out of the Arc of the Covenant.

Reminds me of some of the SOA experts telling us that it's about the business over and over again, duh..

Mainframe versus the cloud

An interesting interview with an IBM guy on the role of the mainframe in business and the latest buzz on cloud computing. He has a lot of good points and most importantly his points are based in reality and not academic discussions. To summarize, the mainframe is still the key system in a lot of companies, this is especially true in financial companies (I can attest to that). The idea that these companies would move these systems off the mainframe and into some cloud of services located anywhere and hosted by anyone is completely ridiculous. That will be about the same adoption rate as companies moving to a successful SOA. :)

Some of his points are also not valid as well. Running programs in complete isolation is certainly possible on the mainframe but only if you have architected and setup it up that way. I've seen regions bring down regions because of some shared piece of hardware or pipes. As with anything the touted benefits are available if you actually know what you are doing.

I ultimately believe the mainframe will die a slow death as a couple of generations start leaving the workplace. The lack of skilled resources in that field has already started to have an impact. That being said it's replacement will probably not be the cloud. In the meantime it's alive and kicking so brush up on your green screen.