Middleware for the REST of us

I’m sitting in my third Oracle Fusion Middleware briefing, this one at the Willard Hotel in Washington, DC. Thomas Kurian has been going through all the products in the Oracle stack in excruciating detail.

First let me say this: Thomas Kurian is a really smart guy. He holds an BS in EE from Princeton summa cum laude (that’s Latin for really fucking good). He holds an MBA from the Stanford GSB. He’s been working for Oracle forever and he even knows how to pronounce Fuego (FWAY-go). I’m dutifully impressed.

Unfortunately, all those academic credentials and 10+ years in the industry is barely the minimum requirement for getting your head around the middleware space. Either I don’t have enough (0) letters after my name, or I just don’t get it.

For starters, there are way too many products — the middleware space is filled with “ceremonious complexity” (to quote Neal Ford). App servers, data services layers, service buses, web service producers and consumers — even portals, content management and collaboration has been sucked into this space. Don’t get me wrong: the goals of the stack are admirable — middleware tries to glue together all the heterogeneous, fragmented systems in the enterprise. Everyone knows that most enterprises are a mess of disparate systems and they need this glue to provide unified user experiences that hide the complexity of these systems from the people who have to use them. That makes the world a better place for everybody.

That was also, not coincidentally, one of Plumtree’s founding principles and the concept — integrating enterprise systems to improve the user experience — has guided my career since I got my lowly undergraduate degree in Computer Science from Stanford in 1998.

So, it’s a good concept, however, if you’re considering middleware because you’re trying to clean up the mess that your enterprise has become, you need to ask yourself the following fundamental question:

Does middleware add to or subtract from the overall complexity of your enterprise?

Your enterprise is already insanely complicated. You’ve got Java, .NET, perhaps Sharepoint, maybe an enterprise ERP system like SAP and say, an enterprise open source CRM system like SugarCRM or a hosted service like SalesForce.com. The bleeding edge IT folks and even (god forbid) people outside of IT are installing wikis written in PHP (e.g. MediaWiki) along with collaborative software like Basecamp written in Ruby on Rails. I’m not even going to mention all the green-screen mainframe apps still lurking in the enterprise — wait, I just did. This veritable cornucopia of systems just scratches the surface of what exists at many large — and even some mid-to-small-sized companies — today.

So clearly there’s a widespread problem. But what’s the solution?

At the end of his impressive presentation, I asked Thomas the following question:

“How can middleware from Oracle/BEA help you make sense of the fragmented, heterogeneous enterprise when you have existing collaborative (web 2.0) technologies written in PHP, Ruby on Rails, etc. running rampant throughout IT and beyond?”

(Okay, so I wasn’t exactly that pithy, but it was something close to that.)

His Aladdin-esque answer came in the form of three choices:

1. “Take control of” and “centralize” your IT systems by replacing everything with Oracle Web Center spaces
2. Ditto by migrating everything to UCM (Stellant)
3. Build a services framework and aggregate everything in one of four ways:
   1. Use a Java transaction layer (JSR 227)
   2. Use a portlet spec like JSR 168 or WSRP
   3. Build RESTful web services
   4. Use the WebPart adapter for Sharepoint

   I like to call answers one and two “The SAP Approach.” In other words, we’re SAP, we’re German, wir geben nicht einen Scheiße about your existing enterprise software, you’re now going to do it the SAP way (or the highway).

Will companies buy into that? Some companies may. Many will not. ERP is a well understood space, so this approach has worked for SAP. Enterprise 2.0 is not terribly well understood, so that means even more diversity in the enterprise software milieu.

So the only approach that I believe in is #3: integrate. Choose the right tool for the right problem, e.g. the WebPart adapter if you’re using Sharepoint. Use REST when appropriate, e.g. when you need a lightweight way to send some JSON or XML across the wire between nonstandard or homegrown apps. Use JSR 168/286 for your Java applications. Even use SOAP if the backend application already supports it.

Keep things loosely coupled so that you can plug different components in and out as needed.

This requires a lot of development — the glue — but, I don’t think there’s any way around that. (You should take that with a grain of salt, because my company has been supplying the government and the commercial world with exactly that kind of development expertise since 2002.)

As for the overarching, user facing “experience” or “interaction” product — that’s where I’ve always used Plumtree (or AquaLogic Interaction).

Will I start using Web Center Spaces? At this point, I’m still not sure.

If it can be used as the topmost bit of the architectural stack to absorb and surface all the enterprise 2.0 software that my customers are running, then perhaps. If it’s going to replace all the enterprise software that my customers are running, then no way José.

This conundrum really opens up a new market for enterprise software: I call it “Middleware for the REST of us” or MMM (not M&M, 3M or M3, because they’re already taken): “Mid-Market Middleware” — similar to the way 37signals approaches (with a great deal of hubris and a solid dose of arrogance) the “Fortune Five Million” by marketing their products toward the whole long-tail of small and medium-sized companies. Maybe the world needs a RESTful piece of hardware that just aggregates web services and spits out a nice UI, kind of like the “Plumtree in a Box” idea that Michael Young (former Plumtree Chief Architect, now Chief Architect at RedFin) had back in the last millennium.

Oracle Web Center Spaces might be the right choice for some very large enterprises, but what about the REST of us?