VOSibilities

For the last several weeks, there’s been a lot of blog discussion about a Burton Group report on SOA “success” or the apparent lack of it.

An interesting thread of commentary has broken out about the role of CIOs in the success or failure of next-generation application development in business. David Linthicum suggests that CIOs are “…very different animals from company to company.” And Scott Wilson thinks CIOs are in a “delicate position” when it comes to adopting new technologies, balancing needs to progress versus reliable service delivery.

For us, it’s simpler: it’s much more dangerous — bordering on suicidal — to let the fear of change become the rationale for continued stasis. That’s why Burton reports that companies get better results with newly hired CIOs. The new guy has a honeymoon period in which he or she can do the unthinkable. (Marketing execs in software companies are almost as perishable as CIOs. We are often brought in to “fix” the previous guy’s reluctance to change.)

But at the end of the day, a change in leadership doesn’t change the underlying reality that the whole IT organization — from the developer in his cube to the CIO — just isn’t scared enough.

Sure, they’re a little bit scared: “If we have to change, we run a risk.” But it’s the wrong thing they’re afraid of…the wrong fear.

What’s a fossil? Something that stood still long enough to get buried, then wedged into rock to be cooked by pressure over time until it disappears. That’s what developers, analysts, business owners and CIOs are doing: letting the small fear of change become comfortable enough to crowd out the large, more important fear of being fossilized.

And that’s a whole lot scarier. For the business…for individuals.

If this sounds like a wake-up call to developers to lose more sleep at night over why they keep finding reasons not to move to services-based apps, it is. If you think we are saying that enterprise architects should be put on a multi-step program to recovery from PowerPoint architectures, we are. If you think we are suggesting the CIO is more damned if he doesn’t implement today’s visual orchestration systems, you’ve got it.

We are pleased to present a recording of a joint webinar we presented on June 12, 2008 with XAware entitled How to Create and Orchestrate Services for Your SOA and Web 2.0 Applications.

Despite the imposing title, I think you will find the content — especially the lively Q&A at the end of the webinar — very interesting.

 

 VOSibilities podcast #10: Webinar replay - How to Create and Orchestrate Services for Your SOA and Web 2.0 Applications [80:19m]: Play Now | Play in Popup | Download (278)
 VOSibilities podcast #10: Webinar replay - How to Create and Orchestrate Services for Your SOA and Web 2.0 Applications [80:19m]: Download (115)

In a recent post, David Linthicum asks if BPEL is irrelevant. And just as David predicts BPEL providers would do, we fundamentally disagree with the premise. In fact, we don’t see how you could create an SOA without BPEL.

As I read the post it seems he has two sets objections. First, a lack of integration of people into processes and second, a collection of concerns about recovery and exception handling.

ActiveVOS is the first development system that’s based on BPEL 2.0 with no proprietary extensions and to include BPEL4People. As a result, it’s the only 100% standards-based way to achieve long-running orchestrations that include human tasks as first-class participants in the orchestrations.

And if you want recovery and error handling, how’s this: what if you could, in a running orchestration, dynamically switch endpoints when the primary wasn’t available? What if you could change what a running orchestration does based on the current state of the overall business process? IOW, if you could determine that processes that included human tasks had problems with the quality of the work and as a result you could dynamically change what happens to in-flight orchestrations? What if you could, very simply, suspend a failed transaction — one that might have been running for weeks or even months — so that corrective action could be taken? What if you could easily version processes so that in-flight orchestrations could conclude before a new process is implemented?

These are just some of the things that ActiveVOS does that we believe are part and parcel of creating applications in a services-based environment and for which there are no real substitutes. BPMN ain’t gonna do all this (it’s not even executable). AJAX and most Web 2.0 technologies are primarily front-of-screen and do nothing to manage the amazing complexities of long-running orchestrations made up of heterogeneous services.

David, don’t pull that trigger until you talk with us. We’re happy to show you (and anyone else) all this and more, anytime, anywhere. I think you’ll come away with a completely different perception.

Whew…it’s been a busy week. We were at JavaOne, threw a great party (pix soon, I promise), met lots of people and got lots of great feedback.

Oh, and speaking of parties, we crashed SAPPHIRE in Orlando. Yes, it was we who dressed up actors in prison uniforms labelled “SAP County Jail” on the back and had the actors hand out ActiveVOS demo CD’s labelled “SAP Liberation Plan” and “Evidence” during SAP’s big user convention last week.

Why? In two words: public service. SAP bigots may think that’s an over-the-top characterization of what they will label as a PR stunt. But there is a method to our madness. We are convinced that SAP is pulling the wool over users’ eyes about BPM. And while we are realistic about our chances of liberating today’s SAP users, we feel compelled to reach out to them just in case they want a get-out-of-proprietary-BPM-jail plan.

What am I talking about? Consider this interview with an SAP architect who says:

SAP NetWeaver already provides capabilities to model and execute business processes that include both automated activities as well as human-executed activities. As the BPEL4People standardization progresses we will presumably see more and more compliant implementations.

Isn’t it clever to conflate NetWeaver — the most closed, proprietary BPMS on the planet — with BPEL4People? If you can just get a little of that standards-based branding onto your proprietary platform (especially in an press interview about standards), it may be enough to keep the prisoners in lock-down and maybe even bring a new busload or two inside the gates.

By “…we will presumably see more and more compliant implementations” I presume SAP was referring to the announcement last week of SAP’s plans for BPM, in which they purport to “usher in a new era” in BPM. The interview was published before the press release was issued, but if this is what she was referring to, it looks like NetWeaver users looking to free their business processes from proprietary stacks have just had their jail sentences unilaterally extended.

Consider three points. FIrst, there’s not a single standard mentioned in this press release. That’s not ushering in a new era. That’s 1980 all over again. Second, notice the repeated use of the phrase “the planned implementation.” This is all about some SAP NetWeaver product you can’t actually get until Q1 2009. Can you say, “freeze-dry the prisoners until we’re ready?” Third, I fell asleep during a demo of this at JavaOne in which the demoer couldn’t even get a PowerPoint to work.

‘Nuff said (for now). Be sure to watch the hilarious video of our “prisoners” being harassed in Orlando as they attempt to hand out CD’s to arriving guests. We didn’t go inside the hall. We didn’t interfere with anyone…but SAP set the security people on us anyway. Guess a little standards-based competition is too much for the self-proclaimed ushers of a new era.

 

 Video of Active Endpoints attempting to liberate SAP users at SAPPHIRE [2:48m]: Play Now | Play in Popup | Download (313)

Have you ever bought a consumer electronic device, gotten it home and then decided that the purchase was a big, big mistake because the remote control was nothing but unrelated, unlabeled buttons that were not lighted for visibility in a dark room?

Well, after five or six years of singing the “SOA is piece parts” jingle and installing buttons without labels or lights, enterprise architects, consultants and the industry in general are discovering that business users, specifically application developers in line of business development teams, can’t do anything useful with “SOA.” No surprise there, though the purists blame “culture” or “people and process failures” or, my favorite, the “inability to sell the benefits of SOA inside the organization.”

Face it, SOA has been a juggernaut for enterprise software companies eager to prey upon large companies’ insatiable need for flexibility in order to sell them (parts of) the Brooklyn Bridge. It’s one of the oldest scams in the world: pretty your pig with the currently popular scent. This is how even CAD systems — about as far from SOA as you can imagine — got the SOA label.

Now, we’re beginning to see more and more of the kind of teeth-gnashing reappraisal that accompanies dire predictions of the “failure” of SOA. And, not coincidentally, the desire to find the next big thing: AJAX is hot, so why not WOA?

All of this angst about SOA is clearly prelude to the mass adoption of SOA. Once SOA moves from concept and process to actual developer-oriented product — just as the web went from HTTP (the standard that embodies a concept) to browsers (a product developers can develop for) — mass adoption is inevitable.

Consider this comment from Chris Howard of the Burton Group at Interop, as reported by Network World’s Jon Brodkin:

…very often, IT departments implement a SOA program that may be technically proficient but doesn’t meet the needs of business users…

Hear, hear. Howard also talks of “fatigue” setting in. Of course people will tire of essentially abstract and useless toys as the realities of needing to succeed in business overwhelm the desire to play all day.

Let me give you another indication of SOA-as-piece-parts fatigue: we’ve cancelled our pay-per-click campaigns on SOA search terms on the major search engines. The words are expensive, thanks to the enterprise software companies that hope to sell more unintelligible remote controls, and the clicks we received weren’t people looking for solutions — just more architecture.

Instead, we hit a nerve when we started talking to Java developers about how to create service orchestrations with a visual orchestration system. We’ve had 200 people attend and nearly 400 people watch a replay of a webinar showing Java developers how to succeed in actually creating something and deploying it as opposed to training them how to sew together some Rube Goldberg application architecture.

However self-serving it seems, I am confident that we at Active Endpoints are on exactly the correct product track, one that will bring SOA to fruition: actual tooling, digestible by mere mortals, that makes creating true SOA-based applications both easy and fun.

We are all about adding lights and intelligible labels to the remote control.

View a recording of the April 17, 2008 webinar BPEL Basics for Java Developers, presented by Active Endpoints’ Ron Romano and Alex Neihaus. This webinar was extraordinarily well-received and offers Java developers a conceptual introduction to SOA-based service orchestration using familar concepts.

There are two files in this post. The first file is formatted for an iPod and can be viewed here on the blog. Please be patient while the podcast downloads into the player. It is also available in our podcast feed (search on “vosibilities” in the iTunes Store to subscribe).

The second, a DivX-encoded AVI file, is significantly larger in size (@460MB) and can be downloaded for more comfortable viewing.

 

 VOSibilities podcast #3: BPEL Basics for Java Developers webinar April 17 2008 (iPod format) [91:49m]: Play Now | Play in Popup | Download (613)
 VOSibilities podcast #3: BPEL Basics for Java Developers webinar April 17 2008 (DivX-encoded AVI) [91:49m]: Download (379)

A fascinating post on the Inside Architecture blog lambastes SOA tools for creating JaBoWS (just another bunch of web services).

Nick Malik writes:

Don’t get me wrong. I don’t hate tools. For one thing, there are some tools that support Enterprise SOA. Not many, but a few. Those tools understand that Enterprise SOA is not about building one service after another, but building the right services, and building them in a manageable and non-overlapping way.

Nick goes on to say that companies that companies that do not implement a “comprehensive Enterprise SOA transformational program” end up with “tripe.”

Have you ever violently agreed with some one’s conclusions but disagreed as violently with the premise? Well, that’s where we find ourselves after reading Nick’s very passionate (and well-written) post.

In short, when you build a SOA up of piece parts, you would tend to believe that service orchestrations — the actual applications — can be built from piece parts. And they just can’t. What’s good for the architecture isn’t good for the developer.

Developers — especially Java types who are creating web services willy-nilly and then running into a wall trying to use them — need something both familiar and holistic to actually get some value from those web services. They need a visual orchestration system which is complete, standards-based and familiar. Something that masks the complexity of long-running transactions, includes human tasks, eliminates hand-coding of XML, offers discovery of available services and, above all, makes testing and deploying services-based apps easy.

ActiveVOS can do all that, and more. Yet some people call us a “tool.” (I’d prefer SOA development system, but at the end of the day, if you are the tripe-buster, what do you care what people call you?)

Nick is exactly correct that the tools people have been using before VOSs yield little but JaBoWS. As long as developers have to put all the pieces together, you can’t get anything else. But there’s magic in making SOA development integrated and familiar.

Don’t blame the tools. Instead blame those who become captives of their own thinking, by extending the assumptions they made in building their SOA to the development of applications to run in that SOA.

Anne Thomas Mannes of the Burton Group has recently written a post that sums up what I believe is the missing in the discussion of SOA and BPM: the enormous challenge in getting line-of-business developer teams to use these techniques.

Anne writes:

I’ve talked to many companies that have implemented stunningly beautiful SOA infrastructures that support managed communications using virtualized proxies and dynamic bindings. They’ve deployed the best technology the industry has to offer — including registries, repositories, SOA management, XML gateways, and even the occasional ESB. Many have set up knowledge bases, best practices, guidance frameworks, and governance processes. And yet these SOA initiatives invariably stall out. The techies just can’t sell SOA to the business. They have yet to demonstrate how all this infrastructure yields any business value.

More to the point, the techies have not been able to explain to the business units why they should adopt a better attitude about sharing and collaboration–which is the fundamental cultural shift required for SOA to succeed. The pervasive attitude is “What’s in it for me?” As one of my interviewees said, “Altruism is not an enterprise strategy”.

Many Americans will remember former President Clinton’s famous prescription for political success in the 1992 presidential campaign: “It’s the economy, stupid.” In a single sound bite, Clinton moved beyond technical discussions of monetary and fiscal policy to the heart of the matter: people cared then, as now in a period of economic turmoil, about bread-and-butter issues.

The challenge of SOA and BPM in business today is that it’s all been high-falutin’ theory. And lots — lots — of money spent on piece parts that look good on architecture diagrams but which are unimplementable by mere mortals in line of business development project teams.

It’s no wonder these “stunningly beautiful SOA infrastructures” cannot be “sold” to the business. By themselves, they do do nothing. Squat, nichts, nada. It takes developers to make these investments pay back for the business and those guys are too smart to sign up for science projects when they get paid to do business applications.

Those who care about SOA and BPM and making it real should take Anne’s advice and stop navel-gazing at their lovely accomplishments. The discussion needs to turn to how to enable real developers to use SOA effectively.

To anyone reading this blog, it’ll come as no surprise that we are quite sure we have the answer. That’s why we created a new category, the visual orchestration system, and a new product, ActiveVOS, specifically for line of business application developers.

It’s a tall claim, but we have the stuff to prove it. (It’s also why we took the unusual step of putting a top-level menu on our new website called “Proof“.) ActiveVOS is all about the application, stupid. And it’s about ending the habit of peeling money off the roll simply to build beautiful architectures nobody can use.

 I’ve been saving this episode’s video for the release of ActiveVOS 5.0. In this podcast, Mike Pellegrini, our chief architect, white boards the revolutionary concepts behind the new scenario testing and remote debugging capabilities in ActiveVOS 5.0.

Now that we have shipped ActiveVOS 5.0, I think episode becomes much more powerful because you can actually request an evaluation and try this for yourself. I’ve seen demonstrations of these new capabilities and I can tell you that if I were working in a SOA or BPM environment, this is precisely what I would want. Testing message-based, loosely coupled applications made of up black boxes isn’t an easy thing to even think about, much less achieve.

Or at least it wasn’t until we shipped ActiveVOS 5.0. (Those of you reading this post on our blog can click the image above to see a screenshot of some of these amazing new features.)

We hope you enjoy Mike’s chalk-talk.

 

 VOSibilities podcast #2: Mike Pelligrini on scenario testing in SOA applications [4:21m]: Play Now | Play in Popup | Download (321)

One of the reasons I really enjoy working with application development software so much is the vitality of the online community. My recent post reacting to what I perceived as a dismissal of BPEL4People generated both responses and traffic for this, our brand spankin’ new blog. Unlike other technology areas, app dev — and the SOA world in particular — is full of well-thought-through blogs and fascinating personalities. I appreciate readers who have taken the time to find us and who are interested in what we have to say.

And, as the newbie in this universe, I seem to have stepped into the middle of a BPMN versus BPEL discussion. My post was perceived by some as exactly that: one should pick BPEL or BPMN. It felt like I got into a religious war, with competing accolytes for each side doing that shout-over-the-wall-at-the-other-side thing.

I want to make sure we are clear about how we view BPEL and BPMN. Over this last weekend, I had an email discussion with Mark Taber, our CEO, which I’d like to paraphrase to make sure everyone understands what we think is important for customers who are trying to orchestrate services that include human tasks. In short,

• We understand people are adopting BPMN. It’s a standard…and our company is all about standards.
• Today, BPMN is being used mostly for notation..that’s OK, but unless it’s executable it’s not any more relevant to writing an application than Visio is.
• If you want you BPMN notations to be executable, today that means buying proprietary execution stacks, which lock up your business process logic better than a life sentence at Guantanamo Bay.
• BPMN is only going to be useful when you can output it to a standardized, open and executable language. Guess what: we think that’s BPEL.

So, far from dissin’ BPMN, we think it’s got it’s legs…but the legs are built of BPEL.

As a kid, I was fascinated by Etch-a-Sketch toys. But I gave it up when I realized that after hours and hours and hours of drawing, my artwork (if you could call it that) was locked into the toy. I couldn’t change it easily and one simple shake would destroy the entire picture. That analogy holds perfectly for BPMN without BPEL: you can etch-a-sketch all your business processes with it, but if you want to run it, the BPMN ends up inside some vendor’s proprietary execution stack.

What standards-based SOA implementation wants that?

This week has been a big week for us. Monday, we launched our new web site. And yesterday, we shipped ActiveVOS 5.0, a major new release for us.

As a result, we’ve been getting lots of attention (including some from competitors who suddenly find themselves behind in the race to deliver advanced functionality at the astonishing new price points we have announced). But of all the early comment and discussion we have seen, the most satisfying to me personally is this blog post by Todd Biske.

Todd took special note of the part of our ActiveVOS 5.0 announcement in which we describe our advanced scenario testing and remote debugging. Todd writes, in part:

…I lamented the fact that when a new development paradigm comes along…we run the risk of taking one or more steps backward… I used …test-driven development as an example. As a result, I’m very happy to see a vendor in this space emphasizing this capability in their product..

Many years ago, I developed commercial applications for a hospital. I used to love writing the code. But I hated debugging it. In those days, debugging tools weren’t visual, weren’t integrated and weren’t very helpful. While it wasn’t as manual as sitting at the machine console with the machine language registers in a run book, like the poor bastard above, it was pretty damn close.

Then the PC revolution made integrated testing and debugging a fundamental part of most IDEs, a very good thing. (And I moved out of writing code to marketing packaged software, also a very good thing for users.)

But what of SOA and testing apps? What about an environment in which messages are flying all over the place? What does a developer need for a testing environment when the service he or she is communicating with is, literally, a software black box? It’s a problem that our 1950’s dude would find insurmountable. You can’t test services-based applications with the tools of the past. It’s a mega problem.

And ActiveVOS has licked it. Believe it or not, it was the scenario testing and remote debugging capabilities I saw in an early demo that cemented my decision to joint Active Endpoints. I knew, as Todd does, that while testing is not something that may grip you in a web demo, good debugging makes working in ActiveVOS a pleasure for SOA developers. (Our web demo, BTW, emphasizes these breakthrough capabilities, so look out for them in the demo.)

So, thank you, Todd, for looking beyond the front-of-screen UI candy to where it really counts and for knowing that eye-candy may be great in a demo, but it’s the parts of a system developers actually use everyday to manage applications that makes all the difference in the long term.

Today, we are very excited to announce ActiveVOS 5.0, the industry’s first visual orchestration system. You can read the details in the press release below. (And starting Wednesday, March 5, 2008, you can actually request a trial.)

As they say in the TV commercials, this changes everything about SOA. From capabilities, to pricing, to performance, to support for standards, ActiveVOS changes it all…for the better.

We hope you will become part of the revolution.

 Active Endpoints ships ActiveVOS 5.0: Download (247)

Please forgive me. This post strains two metaphors and doesn’t do it very artfully. One, the camera obscura, represents, literally, the “dark room” in which many developers find themselves when working with a non-standards-based SOA development platform. The second, “through a glass darkly” represents the transition, indeed, the revolution, that developers need to accept in order to get SOA applications widely deployed.

Because this metaphor exists only in my head, I’ll spare you the rest of this post if you can’t figure out what I am talking about. Here’s the bottom line: ActiveVOS is the answer. Read no further, just download the product and see for yourself.

OK, back to my strained, mixed metaphors. The camera obsucra projects the application you’re trying to create from the other side of the wall. Building that application with proprietary tools is the equivalent of getting there “darkly.”

What I am trying to say is there are three things about building SOA applications you should always keep in mind:

• If it ain’t standards-based, just don’t do it. For those of you who have wedded yourselves to Oracle or whatever-your-favorite-proprietary-vendor-stack-is, you are trying to trace the image on the wall using doomed technology. (Now that was a good use of the camera obscura metaphor, don’t you think?)
• You need the complete package. Piecing stuff together yourself is the ultimate in getting there with muck all over you. It will take longer, cost more and be less flexible. Period, end of story, full stop.
• You gotta reuse what you already have. Nothing is worse than being told you can’t start with at least a trace of the image on the wall. Maybe you’ve got lots of what we used to call “legacy mainframe” stuff (which we all know is running the business). Maybe you want to use Java. Maybe you need to include human workflow. Whatever the situation, having to start over just isn’t an option.

Mercifully, I’m gonna stop here. It may be that you have no idea what I am talking about. But I don’t think that’s the case. More likely, you are mounting a defense in your head of why you cannot “abandon” the path to SOA-based applications you’re on.

C’mon, just between you and yourself, aren’t you willing to admit there’s a better way? Visual orchestration systems, and ActiveVOS in particular, are the digital camera to proprietary systems’ camera obscura.

Our first podcast episode features our CEO, Mark Taber, detailing Active Endpoints’ vision for making possible the mass adoption of services-based applications. Mark touches on the problems facing developers and project teams who struggle with today’s overweight, expensive and hard-to-use tools. He also details how ActiveVOS is the most open and flexible solution to what has until now seemed like an intractable problem.

We hope you enjoy this podcast. If you have any comments or questions, please email us or leave a comment on the blog.

 

 VOSibilities podcast #1: Mark Taber on Visual Orchestration Systems [2:38m]: Play Now | Play in Popup | Download (374)

This is a big moment for me…if not for you. This is the first post on our brand-spankin’ new blog. And I’m all excited about the possibilities.

I’ve been involved with a number of blogs for other companies over the last year or two. And I’ve discovered that a surprising number of people come back to read the first post. A first post therefore needs a little of the mixture of celebration and relief people feel when that new ocean liner actually launches when the woman (always a female for some reason) breaks the bottle of champagne over its bow. Or maybe it’s just me being traditional, but it seems all new blogs that are any good start with a bit of …ahem… manifesto.

So, herewith our objectives. We hope this blog will be informative and in the words of some people I recently worked with, cheeky. We already are showing a little cheek (sorry, it starts right away) by naming this blog "VOSibilities." The pun on visual orchestration systems and the word "possibilities" is courtesy of our own Victor Chan.

Let me say for the first time something we’ll be saying repeatedly: we believe strongly that visual orchestration systems will revolutionize the way project teams design, develop, test, deploy and maintain composite applications. We seek nothing less than mass adoption of services-based applications, all done in an open, standards-based way. So, VOS is the category, VOS is the means, VOS is the objective…VOS is the answer.

But it’s the answer to what, exactly? It’s the answer to app dev miasma. That big, dark, noxious cloud of proprietary this and that, the uncertainty of being able to leverage skills and the inability to effectively absorb technology in a way that makes developing composite applications not just fast and efficient, but fun.

And because good technology is always fun, we’re gonna have a lot of it here. We’re going to get loud, we’re going to get visceral and we’re going to say what we think.

So, if you found this post before there was anything else on the blog, thank you. If you are reading it to wonder who the heck these loudmouths are, thank you. If you are one of the competitors I intend to skewer regularly here, a special thank you. And remember…it’s all in the name of open, direct debate.

This is just the first of many times we’ll get to talk to each other.