Which IBM ESB?

IBM has been beaten up by the press and blogging community for having two ESB's. Here's how I look at it. One is for new customers and new installations (WebSphere ESB) and one is for the legacy upgrade path.

Google Flow and Goolge Forms

I believe it was 1994 - maybe 1995 when I last talked with Eric Schmidt. I asked him a very direct question, "What is the killer app for the Web?" and he responded, "Groupware". Perhaps that was the Novell corporate line - but honestly, I think he believed it. For those who don't remember - Groupware was a term that involved electronic forms and workflow/collaboration.

I've been reading about Google becoming a business computing platform. If Google wants to be a business computing platform, they need two things:

flow.google.com
forms.google.com

Of course, this moves them from 'unstructured' data to 'structured' - and implies that Google attacks the identity / role problem. But let's get real - most business systems capture data, store it, aggregate it and redistribute it. During the process we monitor it and report on exceptions.

The world has been waiting for a clean simple way to do these common tasks. Google is in an excellent position to enable business 'Software as a Service'. The traditional problem with this approach has been accessing the data once your 'SaaS' provider collects it. Well, Google clearly understands that SOA and Web services provide a real nice vehicle for facilitating data transfers.

Come on Google - make my day.

SAP, IBM, Microsoft and Oracle

The 4 major enterprise ISV's have created their strategy. If you haven't been paying attention, I'll summarized it for you:

Microsoft - Microsoft will make the WS-* protocol ubiquitous by pushing them into the operating system. Then, they will provide unbelievable tooling (Visual Studio) and a firm foundation (Communication, Presentation, etc.). This strategy is developer focused, once again hoping to create an ecosystem of applications sitting on top of their platforms (Foundation, .Net core and Windows). How will these applications get funded? Most likely a combination of new VC money, MS funded entities and internal projects.

SAP - SAP has such a huge footprint inside of large enterprises that it makes it almost impossible to remove. SAP has to keep up with the trends: Provide an application platform (NetWeaver), service enable their system (ESA) and create an ecosystem (Xapps). Done, done and done. SAP has protected their market.

Oracle - Oracle looked like the dog in the group - until they bought out all of their competition. Less SAP, Oracle owns the application space. This means that they are concerned about the business services and processes. Does it matter if it runs on Oracle App Server or IBM WebSphere? No way. Everyone knows that the J2EE stack is commoditized - just ask JBoss. Oracle will use the WSDL as the new 'barrier to removal'.

IBM - At first glance it would appear as though IBM is the ultimate loser. They have lost the Application space to SAP and Oracle. Their WebSphere suite is commoditized which leaves them with two interesting items: Traditional IGS consulting and Business Process Outsourcing. From my view it appears that IBM wants BPO. They'll own your technology because they'll own your outsourced process.


Who wins?
This is a huge, huge gamble that IBM is taking. If BPO goes 'out of style', IBM will find themselves with no application strategy and playing second fiddle to the Microsoft tooling and platform. Ouch. On the other hand, if their bet plays out they will have the ultimate hand in deciding which vendors technology is used. Oracle has a massive integration project in front of them. SAP will find that it is hard to swap out the platform foundation for their ERP suite. Who wins? All of them - to some degree - no clear winner - all advance.

Who loses?
This is easy. Anyone that isn't SAP, Oracle, IBM or Microsoft loses. We aren't done consolidating so some additional companies will have interesting exits, but ultimately the consolidation favors the giants.

Should Stupid People Do SOA?

In not so many words, I found a piece that asks the question, "Should stupid people do SOA?":

"True story: A financial-services firm built an application to track risk management on a Web-services platform. What had once been one application was broken down into 15 XML-based services, some of which were outsourced because they encompassed noncritical information. It was a sound plan; by outsourcing some of the component services, the firm saved both time and money on the project. But there was one thing the developers hadn't considered, and that quickly became apparent when the application was deployed.

It was chaos. Instead of one application logging data, there were 15 services that needed to be managed--and all were sending messages to the system-management application. That app would in turn notify the IT department of the errors it was logging. Not only did the risk-management application crash, but it took the system-management application down with it, both of them overwhelmed by the essentially 15-fold amount of data generated. The company eventually had to redesign the way messages were handled to ensure that the system-management application only logged the most critical ones.

And that, in a nutshell, is the conundrum of combining a service-oriented architecture, in which loosely coupled business processes are transformed into discrete interfaces that can be easily plugged and unplugged as business conditions require, with the outsourcing of those business processes to third-party providers. The advantage is the disadvantage. You can break business processes down to their most granular, logical elements; focus your development efforts on where you can provide the most differentiation; and let someone else handle the overflow or the low-profit transactions. But you open yourself up to a management challenge the likes of which you've never seen."

Here's my view: Stupid people shouldn't do SOA (on-shore or off-shore). Stupid people shouldn't do object oriented. Stupid people shouldn't do ERP. Stupid people shouldn't have white-collared jobs... but they do.

In many ways nothing has changed. SOA doesn't keep stupid people from making smart mistakes or smart people from making stupid mistakes. It sure doesn't hide mistakes. In some ways it makes the mistakes more visible - which, if properly managed is good. I'd love to see the 'service oriented sequence diagrams' and the 'integration testing plan' for the aforementioned system. Any semi-competent architect should have seen the cross-cutting concerns and performed integration testing - SOA or otherwise.

SOA is an architecture that specifically leverages a continuum of talents: 'brains', 'average' and 'grunts'. Use the 'brains' to create the common services and practices and make the 'grunts' use them. Leverage the 'average' dudes to verify that the 'grunts' are doing things in alignment with the 'brains'. Done. Stupid people (grunts or not) always slow things down.

LINQ

If you haven't checked out the LINQ project from Microsoft, it is worth your while. Dealing with databases and XML documents has always been a pain in the rear. We have the constant mismatch that Hugh pointed out. Well, Hugh didn't get his new language - just a bit of pain relief.

Oh yea - also announced, Microsoft built a workflow engine that works off of state transitions. It only took them 30 years since their founding to build one. Woo hoo. If doesn't come with a set of WSDL's I'm going to be so pissed...

Extended Service Portfolio Management

A few months back I came across a great blog entry:

"At a fundamental level, the radical shift to SOA calls for a different mindset – a dramatically different one at that. The adoption of SOA shall signify itself to be an important development in the IT world. Software will be described as a portfolio of capabilities and possibilities instead of modularized applications. Data models will be standard-based and externalized to enable interworking between services, and data will be considered to be like any other form of "digital content" ever ready for exchange and transformation between systems."

Guys like Frank Martinez, Carlos Perez and John Udell have discussed the value of creating services whereby they may be recombined in a manner that was unintended at design time, 'unintended recombinants' if you like. Services were meant to be used, reused and reused in manners which the design never intended. Services that were designed correctly hold a special latent value - they hold the value of recomposition, both at design time and perhaps more importantly at runtime.

As large organizations perform Service Portfolio Management, they are beginning to notice that certain service designs enable reuse and recomposition. Nothing new here. However, as the service ecosystem begins to grow the Portfolio Manager will spend less time on their current 'service capability view' and more on the 'service possibility view'. Here, the goal is to evaluate opportunity.

The Service Portfolio Manager must become a specialist not only in enterprise refactoring but also in shopping and procurement. Services will be built, bought, leased and borrowed. Recombining services, from anywhere, for value-add solutions is at the heart of a Service Oriented Enterprise.

10 Low Profile SOA Comapnies

Here is a list of 10 SOA centric companies that fly a bit lower on the radar:

Redberri - Redberri Integration Platform helps enterprises to leverage the power of service oriented architecture (SOA) to streamline processes within a reliable, scalable and secure infrastructure.

GridScope - GridScope’s vision of Simply Managing Services™ is to provide a simple, dynamic solution for federated management of web services that underlie your enterprise-critical business processes.

FiveSight - FiveSight Technologies provides open source WS-BPEL-based business process execution and service orchestration products along with related support, training, and consulting services.

Xcalia - Xcalia makes SOA easy to implement with agile business intermediation software that combines heterogeneous data with services to rapidly develop and deploy transactional composite applications.

SOAPKnox - SoapKnox is developing products in the area of Web Services (SOAP) to ease developers in their development and deployment of Web services.

Above All Software - Above All Software provides business integration software that allows our customers to maximize the business value of their service-oriented architecture (SOA).

Cast Iron Systems - Cast Iron Systems is the inventor of the Application Router, a simple yet scalable integration appliance capable of connecting, transforming, and routing data and events from source to target systems.

GT Software - GT Software is a leading provider of enterprise application and data solutions that integrate mainframe data and applications into client/server and Web applications using ODBC, JDBC, J2EE and Web services.

Neon Systems - NEON's continued growth in the Web services market provides customers and prospective customers with the most robust set of solutions to support Service-Oriented Architectures (SOA).

Kenai Systems - Kenai eXamineXT provides One-Touch Vulnerability Assessment for Web Services.


Did I miss your company? Send me a note! jschneider at momentumsi dot com

IBM Ships ESB

IBM has announced that they have an ESB - and will be shipping it within the month.

Yesterday was a busy day talking with IBM personnel about the ESB and their new WebSphere Process Server. Naturally, I voiced a few concerns about calling it an ESB but if anyone can create a category, it is IBM.

What I heard was a couple interesting comments:
- Don't concern yourself with SOAP over MQ
- We agree, it isn't about JMS
- Don't worry about the protocols, we'll add'em in later

Hmm. If a WS-startup were to have told me this I would have gone off - however, this wasn't - it was IBM. Big blue customers will buy this. They will build on endpoints and mediate in the middle.

I remain disappointed in the lack of clarity around the ESB but am happy to see IBM put some new weight behind their SOA marketing. Congratulations to the IBM teams for getting these products out the door on schedule.

Our customers have been asking us for an ESB evaluators offering which is now available. Send an email to webservices@momentumsi.com. In addition, we'll be putting the IBM ESB into the MomentumSI SOA lab as soon as we can. We remain committed to pushing vendors towards the next generation of standards and pointing out those that are stuck in the J2EE world.

Pop Quiz: WebSphere was the IBM J2EE/Component brand; What is the IBM SOA brand?

It is time for WSEE

When I looked at open sourcing my stuff as part of an ESB - I quickly determined that the ESB had so many definitions (many of which didn't contain orchestration) - that the ESB had already crashed.

Modern software infrastructure is based on standards. Standards are grouped into profiles. Profiles are implemented and become products. I don't always like it - but that's the way it works. The ESB 'pick your standard' circus has demonstrated that our customers need more than marketing umbrellas.

We need architectural profiles.

The successor to the ESB MUST be profile based. Think RFC 2119.

What is an ESB?

MomentumSI's Definition of the ESB:

"An ESB is a collection of platform specific (Java) API's front-ending a vast subset of the Web service protocols, formats and identifiers."

---

---

---

---

I almost forgot - I've been meaning to congratulate Sonic on inventing 'SOAP over JMS', also known as the ESB. Unofficially, MomentumSI has been predicting that the bus would crash since October of 2003.

Here is the really sad news: ESB isn't dead as a category. It won't die until a replacement category is created. In my humble opinion, the ESB 2.0 won't work. What is the replacement: The Enterprise Service Network? Application Oriented Networking? I don't know. What I do know is that in an unprecedented display of incompetence Gartner & Sonic took a shotgun to the ESB category and blew it away.

Annrai, Frank, Dan, Roman - uhh... what the hell are you guys waiting for??? I'm going to start referring to you guys as the "Ball-less-four".