As seems to be the trend with me going to analyst conferences, I wrastle for some time with many drafts and snarky write-ups about my thoughts. In the end, taking a wider, industry view, as reflected by the company at hand, wins out. As I try to tell people, my prime interest is in seeing the industry thrive and evolve, not torn apart by the likes of me, customers, and, more often, itself.
So, here’s some “summary,” as promised to make up for all that damn note-posting.
(The funny thing is, I was originally just going to post on how GMail should list links to all the emails you’ve sent/recieved from someone when you’re replying to that person. The use case being so that you could remember who the person was if you didn’t immediately know. Yeah, sorry…too much navel gazing there.)
Composite Applications Meet Mashups
One of the big concepts at the BEA Analyst Summit was composite apps. SOA’s can help enable composite apps, so you can imagine BEA, the self-proclaimed Masters of SOA, are all over composite apps. Which is not to say that you couldn’t have them without SOA’s, just that the two are a natural fit. The Pratt & Whitney customer story was a great tale of composite apps and SOA’s at work.
On the Glass with JavaScript Includes
A phrase you hear a lot is “on the glass” or “screen” integration. Indeed, that’s the most successful approach in web-land: JavaScript includes rule the school when it comes to quick and easy composite apps. As I suggested to several people, if you’re doing any sort of content/portlet platform, you should really, really use JavaScript includes as one of your interfaces. SOAP interfaces are par for course; REST interfaces, now I’m listening ; JavaScript Includes, jack-pot!
They’re wildly successful on the web for pulling (flickr, technorati, del.icio.us, Google Text Ads etc., etc.) and pushing (every single hosted website log tool, including Google Analytics and the much better StatCounter) data between websites and services. JavaScript includes are pure on the glass composite applications at their best: they’re easy to use and cheap to develop. They call it The Sweet Spot: Kids like it because it taste good, moms like it because it’s healthy.
Dude, and don’t even get me started on bookmarklets. That’s some consumer tech ripe for the enterprise picking. Those little bookmarks are so damn useful. Look no further than our man Udell for proof positive.
Consumer Tech Driving Enterprise Tech
It’s worth pointing out, as several BEA folks did when I told them I liked Web 2.0 ideas and technologies, that “composite app” is just a fancier term for “mashup.” For reasons of “coolness” — apparently, you have to be under 35 to know the term — “mashup” has received bigger flurry of “yuh!” than “composite application” did.
Which of course, begs the question: how can we get the enterprise software vendors of the world to use cooler words like “mashup” instead of “composite application”? Would it work? The over 35 crowd (hopefully it’s obvious that I’m poking fun at that claim instead of those over 35) might think it’s a toy; The Kids might think it’s false . Or, the mind shift required to make the name change possible might just result in better software.
More importantly, it highlights the a major trend in innovation that’s worth pointing out, obvious as it may be to some: consumer technology is driving (or should be!) much of enterprise technology. Business needs drove technology much more in the past. But now that there’s actually quite a lot of money in consumer software, there’s quite a lot of innovation in it. I’m not the first to point this out by far. On the other hand, enterprise software vendors don’t seem to be benefiting from that trend as much as they could.
REST and SOAP
Another trend, of course, is REST vs. SOAP. Sure, consumer sites like eBay, Amazon, and flickr are REST heavy, but what about in the enterprise? It seems not so much…though it’s tough to say. The interlacing of SOAP and SOA makes me worry that SOA’s slogan will simply become “SOA: it’s like CORBA…except this time it’ll work!”
Point being, I’m not too thrilled about the long term viability of an SOA approach based on SOAP. SOAP is complex, and that complexity causes costs. That creates a whole market that’s geared towards making the SOAP based SOA easier to use.
A Love Complex
As a vendor, you love that: enterprise vendors help their customers solve problems by writing better software than the customers could themselves. Writing the best software possible is BEA’s model, and they’re very proud of it. As they said, “the reality is that we’re providing these features that our competitors can’t provide.” Quality software aside, the love of complexity is really just short term though because…
As a customer, you hate complexity. In the world of requirements, protocols, and everything in-between, complexity is a cash-burner. When it comes to web services, the further away you get from a URL that anyone could type in a browser, the more complexity you have. Complexity is why you spend so much on IT. That’s why I’m such a broken record when it comes to Agile software development and lean tuning: they’re complexity killers.
If the Software Won’t Get You Laid, At Least it Should Be Fun
Not to mention the fact that REST is so much more fun than SOAP. Even XML-RPC is more fun to use than SOAP. As crazy as the idea has been put in the past, developers ultimately play a huge part in the success of a technology. Just think of the cycle:
- You, an enterprise software vendor, sells a big middleware stack to some wing-tips.
- The wing-tips tell the developers: here is your middleware. Now let’s implement that system!
- The developers dislike the middleware.
Now, you, the enterprise software vendor, are at the mercy of the developers. The developers are the ones who’re going to make your software look good…or really bad. If the developers are late delivering, you can fully expect them to start saying, “that damn middleware takes too long to work with. It’s too complex.”
They could be right. They could be wrong. It doesn’t matter: in the scenario you’re middleware looks bad to most people. And if they actually paid for the middleware instead of got it for free, so much the worse.
More than likely, this same trend will start happening with dynamic languages. “I could have delivered on time, but this Java takes so long. I whipped up something in Rails last night though…”
Both of those instances are nefarious uses of one of the better, but little used, Agile tools “failing in order to learn how to succeed.” If you’re a vendor, that’s a terrible tool to be at the wrong end of.
“But Brutus says he was ambitious”
As one of my architect buddies put it today:
A great opening quote for your upcoming book on enterprise software: “In the late 90s, enterprise software was alive and well until it was slowly beaten to death by enterprise software companies.”
While there is no upcoming book, he’s right on. Obviously, I’m not here to kill enterprise software, or run around saying it’s dead. Hardly. On the other hand, I sure would like to see enterprise software, stop harming itself with complexity.
I am that weird type who likes it, and the even weirder type who likes systems management. It is my sickness.
BEA
From the content I got at the BEA summit, I can’t really make the call as to whether BEA’s offerings are too complex. Things don’t really get that low-level at such events: though, it is fun to see the spark in tech-people’s eyes when you open the door for them to talk about tech stuff instead of feature tick-lists, workflow management, and reports, all of which tends to dominate the Q&A’s.
From what I did hear — the goals, ostensible purposes, and lengthy on- and off-line conversations — BEA is taking a smart approach to things. Let’s just hope they don’t end up in WS-Hell and the mind-set that takes you down that path. Even Superman and Navy Seals might find that one a hard extraction.
BEA’s Holland, Graffiti, and Runner projects where the most encouraging things I heard about along the lines of running towards simplicity. I’m hoping to hear, see, and talk a lot more about them in the future. Those project have the potential to un-burn those who got burned by portals.
It’s Possible
BMC doesn’t make a big, or any, stink about it (I and others often wonder why), but thanks to some internal marketing and the enthusiasm of the people who picked up the charge, while I was there we managed to get tags into an enterprise software system, even a search box. Which is a ginormous sentence to say: I’m a huge believer and have practiced getting Web 2.0 technologies into enterprise software. It’s strange going, but possible.
(I could write even more about search being the ultimate feature. But I’ll save that for another time, it’s not even my idea, I just borrowed it from someone else.)
“Mashup” is shorter than “Composite Application”
Yes, which has always been the point, hasn’t it? Less is more. When you’re making a “composite application,” why not just drop in a JavaScript include instead of configuring and wiring up a portlet to an SOA’ed WS? Do you really need a “suite” of applications to type a memo? When you’re creating an SOA, why not just write up a 3-5 page POX API, and that’s it? Do you win much from adding those 80-200 other pages and XSDs? You can no doubt, dear readers, figure out my answers to those questions.
Of course, even that creates a problem ripe for vendors.
Just wanted to say that this is all great stuff. 🙂
Nice work, and great write up on the proceedings. This is a space we are getting right into (but being IN an enterprise, I have to say that this sort of thing gets done as skunkworks, because we are SO busy implementing some "enterprise software").
I admit that I haven't spent much time lookng at BEA – we have dabbled with Websphere 'things', and Oracle are trying to sell us on their "Red Stack", and what we prefer and have more experience with is Sonic (SonicMQ/ESB/BPM – http://www.sonicsoftware.com). I have been trying to get a look at Intalio's set up as well – have you seen/heard much of it? (www.intalio.com) They have an early adopter program that I haven't managed to crack yet, but it is mostly built from opensource components. Ismael (one of the guys behind Intalio) talks a lot about "Office 2.0" on his blog (http://itredux.com/blog) … you might have come across him already.
It feels like that one scene in the end of Return of the King, where the Riders of Rohan are screaming DEATH DEATH DEATH and then charge the assembled Orc hordes.
Invigorating!
All: thanks for the kind words (I'm pretty sure Danno's comment are meant that way ;>)!
Ric: I'd love to talk with you more, if you have the time to spare, about all the in's and out's of the evaluations you're doing. If you have the time, my email is [email protected].
I love the three step cycle:
Sell Enterprise Software to upper management.
Inform the developers they have to make it work.
Developers hate Enterprise Software.
Sadly this is far to common a pattern or maybe it’s an anti-pattern. I’ve probably been reading too many pattern books in general.