The lore of averages
I was chatting to a friend who's a top-notch Java developer over the weekend: we were shooting the breeze about Groovy, Rails, Spring, Hibernate and various other Things That Get People Excited (let's call them TTGPEs), and discussing how far they were likely to penetrate into your average IT shop. "Why do so many people insist on following the J2EE application model and associated patterns so slavishly," said my friend, "when they're so plainly not the right tool for the job in so many scenarios?"
"The thing that you never get from reading development books," I said - he'd just finished showing me a book on Groovy - "is how difficult it can be for your average IT shop to get on board with a new development technology, when you take commercial considerations into account. You can see from looking at code samples that language A is more compact or give you more productivity than language B. But what you can't see is the bigger picture of costs and risks."
I remembered a post of Steve Jones' I'd seen a couple of months back about
development as a discipline for the masses - and also
this one from Jeff Schneider about the value of SOA governance.
You see, the problem for your average IT shop in taking on TTGPEs is that even when they have been demonstrated to save time and/or money, there are two real barriers to adoption. Both barriers exist primarily because these shops have no option but to see development resources as a commodity.
First, within an average IT shop - think of one within a small utility provider or a local government - the business can't make a case for paying top whack to hire the very best developers. So, they have to shoot for the "mass market" of developers - hopefully capable and dependable, but not likely to be stellar performers. They also don't have a lot of time or money available for recruiting, so they tend to minimise the complexity of interviewing as far as possible - asking for "industry standard", well-recognised skills. Unless they can find TTGPE skills within that "mass market", they're not going to consider bringing those skills into the organisation. J2EE skills are now mass-market skills. Groovy skills aren't (yet).
Second, within such an IT shop, work tends to follow those same "industry standards", because the risk of doing TTGPEs is that if people leave or get sick, and new people have to be brought in, they have to be able to get new resources up-and-running quickly. If new staff have to spend weeks or months trying to re-engineer glamorous but unknown technology before they can continue a project, that's a huge, ugly cost.
Regardless of whether J2EE is increasingly being revealed to be more like a VW crossed with a tractor than a Ferrari, then, the truth is that most people have little choice, for now, but to stick with it and make the best of things.
Labels: 4GL redux, development, governance, industry
TIBCO's ActiveMatrix and 4GL for SOA
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.
Labels: 4GL redux, SOA, TIBCO
