We’ve been meaning to blog about TIBCO’s ActiveMatrix product family for a few weeks now, since we were briefed on it in December. However it took a while for us to get to a point where we felt we had something particularly “aha” to say about it.
What makes ActiveMatrix so potentially valuable is also what makes it a challenge. As TIBCOer Rourke McNamara said in a blog entry from Gartner’s Application Integration and Web Services Summit: “Explaining what ActiveMatrix does in 90 seconds isn’t easy.” Actually explaining it’s value is more challenging, because it’s not what you might expect from TIBCO.
TIBCO talks about “service virtualisation” and describes the core element of ActiveMatrix – the ServiceGrid product – as a “network of service containers” with “embedded policy management for service governance” and “JBI and SCA support for service deployment and provisioning”.
These things are all true, and they’re all cool.
But what does that really *mean*, in really straightforward terms? After talking to numerous journalists and clients about ActiveMatrix over the past weeks, we’ve evolved our introductory explanation to this one, when talking to non-expert IT audiences:
Back in the day, a big challenge faced by large organisations trying to develop and deploy systems was how to create systems relatively quickly, that were quick to change, in complex multiplatform environments. In those days the multiplatform issues was one of 16- and 32-bit Windows, Mac and OS/2 clients; Solaris, AIX, HP-UX, OpenVMS servers; and various kinds of databases and network protocols (this was when IPX/SPX and SNA were as interesting as TCP/IP).
A whole range of “second generation 4GL” environments were created which aimed to help. They married a high-level abstract programming language (the 4GL) to a virtual machine which was ported to all the major platforms and which hid the details of the operating environment – client, server, database, network.
Now let’s fast-forward to today. Java and JEE and web-based application designs helped with some of that old multiplatform nightmare, but it’s not the only game in town. What’s more, now we’re looking at SOA, the challenge today isn’t so much about building discrete systems; it’s about finding a consistent way to build and integrate system elements that can talk to each other within various parts of our companies, and also across different companies and whole supply chains.
In short we have another version of the same problem, only this time the multiplatform aspect is at a higher level – and the scope and scale of the operational environment are much bigger. Now we struggle to get “plain Java”, JEE, .NET and other modern application containers to talk to each other, as well as other “legacy” application platforms – and Web Services protocols and standards are only a partial answer here at best. Even if protocol interoperability gets working better we’re now looking at an environment which is widely distributed, and which may not be 100% under any one party’s control.
So if we’re to try and address today’s challenge for SOA – to enable people building and integrating services to just concentrate on the core logic of what they’re doing rather than getting stuck in the weeds of environment-specifics – we need something like the old 4GL virtual machine, but with lots of extra capabilities – like service provisioning (think about telecoms service provisioning if you know that industry) , and policy-based operational and lifecycle management of services.
That’s what ActiveMatrix does. It provides a virtual machine environment for the SOA age.
As an aside: Why is ESB not the answer, and why is ActiveMatrix not an ESB? Because ESBs concentrate on solving just one part of this conundrum – the operational communication between services. From the developer’s perspective the ESB is pretty much invisible (intentionally), and doesn’t offer any “virtual machine” facilities to that audience. ActiveMatrix works on top of, around, and underneath ESBs.
Of course there’s a proprietary element – although ActiveMatrix is built around JBI / JSR 208 and elements of the SCA specification, the container design itself is unique to ActiveMatrix. Interoperability is standards-based through JBI, but of course interoperability with something else is not the same as “swappability”.
So here’s a couple of interesting questions. Do companies pursuing SOA know they need this, and does TIBCO have the credibility to provide it? And is there enough momentum in the SOA movement to get the mainstream of companies to the point where they need ActiveMatrix, or something like it?
The credibility question is a good one, because it certainly took me a while to work out what TIBCO was doing with ActiveMatrix. I saw it completely as an integration vendor moving into SOA, and was completely unprepared for what TIBCO was trying to tell me – for a while it just didn’t compute. We’re going to need some excellent customer examples, well-explained, to really help people get in the right frame of mind to hear what TIBCO’s trying to say here.
The second question is concerning to me as a student of IT industry history. The truth is that the history of the industry is littered with examples of situations where “movements” were cynically abandoned by vendors in favour of newer, shinier things, just as they got to a tipping point. If you can dupe your customers well enough, you can sell them A, wait until they get familiar with it, and then tell them that A is last year’s model, and sell them the virtue of A’. Example: the demoralising arrival of SOA 2.0.
Many say that SOA itself is one of these cynical reinventions, and there is a grain of truth in that (but only a grain, I’d say). I believe that SOA has real value – and that in the context of achieving that value companies will need facilities like they can get from ActiveMatrix – but my concern is that we’ll get derailed by the “next big thing” before we can all realise that value.
Lastly, a disclaimer: TIBCO is an occasional client and we provided some input to help them refine their ActiveMatrix communications.
