Busting down silos is nothing new to anybody who’s suffered through 1990s-style reengineerings. The goal of these efforts was eliminating the waste and duplication that occur when organizations are composed of dedicated units. For instance, if you want to cross-sell new products to existing customers, it’s hard to do that when each product has its own sales organization.
The same can be said with software. Large enterprises are likely to have multiple ERPs, CRMs, and back end databases. There’s also functional duplication or multiple APIs even within single applications. And if you’re a large middleware vendor, you’ll probably have multiple mechanisms for integrating applications, processes, or data.
With emergence of SOAs, it’s become thinkable to tie bits and pieces from the same system, or disparate systems, together into so-called composite applications. You can use third party tools, like business process management systems to tie things together, or you can buy prepackaged composite apps, like SAP’s xApps.
And if you take SOA seriously, you start thinking about breaking down those packaged software monoliths into federated services that could loosely couple with whatever else is out there. In other words, SOA gives best of breed a new lease on life.
Oracle’s Fusion architecture is being designed to decouple enterprise apps into services. SAP’s Enterprise Services Architecture (ESA) forms the blueprint on how its apps will be exposed. However, exposing apps as services that can readily integrate with third party offerings does not mean that SAP, Oracle, et al are ready to cede account control. Just the opposite – they intend to play the hub in larger playing field. Remember, SAP and Oracle, and all the smaller fry that they gobbled up, dominated because customers voted overwhelmingly against best of breed. At the end of the day, they wanted one throat to choke.
Could the story be any different for middleware? Theoretically, with standards, like Java EE or the various WS-web services protocols, it is more thinkable to plug and play generic pieces of software plumbing compared to dealing with pieces of a business process. And in middleware, you’ve got a lot more open source around.
Last week, BEA unveiled a new strategy that could deconstruct much of its WebLogic, AquaLogic, and Tuxedo lines into componentized services that could be bundled at run time. Unfortunately, the branding is pretty confusing (a mélange of microService Architecture, SOA 360, and Workspace 360), but the message is fairly straightforward. OK, for now it’s mostly vision. Over the next few months, BEA will start filling in some of the blanks.
To some extent, BEA’s WebLogic product already conforms to this vision. It offers a choice of frameworks to perform various chores, such as object/relational persistence. With the new mSA architecture, those options would be exposed as services that you could plug and play. For instance, by deconstructing its offerings, you could cram just the pieces of WebLogic that you need inside the tiny footprints that are typical at the edge of network.
Composite apps might deconstruct software as we know it. Yet, regardless of whether it’s middleware or applications, customers still expect one player to be more equal than others – because somebody’s gotta vouch for the integration.