VOSibilities

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 (61)

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.

Pssst…wanna have some fun at JavaOne? Join us for our Tiki Bar Party on Wednesday May 7, 2008. Get all the details here.

Why a Tiki Bar Party? Because we’re big, big fans of Tiki Bar TV and we wanted to have some fun ourselves. So, we maxed out on the kitsch and we’ve invited a bunch of people — including you — to join us.

But you have to work for those free cocktails (featuring unforgettable tipples like the BPEL Island Julep and the VOSarita). You gotta get two button at the show and then wear ‘em to the Bamboo Hut to get in. Pictures of these oh-so-cool-you’d-want-’em-anyway buttons are below. Where do you get the buttons? At the Active Endpoints and XAware booths, which are in Startup Row in the Pavilion.

How can you lose? Cool buttons, cooler drinks and fun people. Sounds like a pahhty. We hope to see you there. Remember: check out www.javaoneparty.com, print the invite and get those buttons to join us at the best party at JavaOne this year.

Here’s the Active Endpoints button:

 Here’s XAware’s button:

We are pleased to offer our first audio podcast. Until now, we’ve used our podcast feed to offer videos, webinar replays and news about Active Endpoints in PDF form.

Now, we are going to a more “classic” use of our podcast feed by providing audio interviews with the people inside Active Endpoints who are driving our product and market efforts. I hope to offer regular podcasts that span the gamut of topics: from marketing to technology with everything in between.

Enjoy this inaugural episode with Chris Keller, a founder of Active Endpoints, who I stuck in the “Wayback Machine” and asked a couple of tough historical questions. First, “Why BPEL”? And second, “What lead to the requirement for BPEL4People and WS-Human Task”?

 

 VOSibilities podcast #4: Chris Keller on Active Endpoints, BPEL and BPEL4People [14:20m]: Play Now | Play in Popup | Download (54)

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 (306)
 VOSibilities podcast #3: BPEL Basics for Java Developers webinar April 17 2008 (DivX-encoded AVI) [91:49m]: Download (251)

I was reading Frank Cohen’s blog today (he was nice enough to help get the word out about our webinar on Java and BPEL this coming Thursday) and I ran across this very interesting comment Frank made after having attended a Java conference recently:

Java architects and developers are frustrated looking for Business Process Management (BPM) standards and tools. Brian Sletten’s talk…was titled “Avoiding ESBs” but could have been better described as “I’m sick and tired of waiting for vendors to give me a decent Business Process Management (BPM) platform!”

Here in VOSville, we think one of the mega VOSibilities (that’s posibilities for those of you who are already tired of my lame puns) that exists in the marketplace is at the junction of visual orchestration systems and BPM. I know, I know, this ain’t very specific. But, I can’t say anything more at the moment.

Let me just say that we are cooking up sumthin’ very special that will answer this precise criticism. And, I promise, you won’t have to wait long to see the water (and our competitors’ blood) boil.

But, you do have to wait. While you do, Frank was kind enough to send over information on a bootcamp his company is holding. Here’re the details. You should check it out.

Frank Cohen and Robert Schneider are putting on their Open-Source Test Automation Bootcamp, a 3-Day Hands-On Course, in Philadelphia on May 14-16, 2008. Companies such as AMD, Amazon, TV Guide, Ford, and The Jackson Labs sent their testers, architects, and managers to learn Frank and Rob’s test methodology, test patterns, and best practices. Plus they received hands-on training with free open-source test tools, including soapUI, Selenium, and PushToTest.

The Bootcamp delivers hands-on training to test Web applications, Web services, Ajax, Service Oriented Architecture (SOA), and REST applications to optimize these for performance, reliability, and proper function. The Seminar teaches practical methodology and techniques to surface performance bottlenecks and optimizations to improve scalability and throughput.

Bootcamp instructors Frank Cohen and Robert Schneider are the leading authorities and teachers for testing and optimizing software developed with Web, SOA, AJAX, and REST designs and implementations.

Details can be found at http://bootcamp.pushtotest.com

Active Endpoints today announced the Java Advancement Kit, a set of education, training and products that will enable Java developers to take the next step in their professional advancement by quickly and easily using web services to create compelling service orchestrations.

 Active Endpoints Announces the Java Advancement Kit: Download (132)

Please join us for an informative webinar on April 17 entitled BPEL Basics for Java Developers. Register here.

This informative webinar will help you expand your Java knowledge to acquire an understanding of the basics of BPEL. A high-level overview of BPEL and its importance in a web-services environment will be presented, along with a brief discussion of the basic BPEL activities and how they relate to Java concepts. The following topics will be covered:
• Parsing the Language of SOA with Java as a guide
• Breaking out of the VM: evolving from RPC to Web Services
• BPEL Activities - Receive, Reply, Invoke • BPEL Facilities - Fault Handling and Compensation (“Undo”)

We hope you can join us.

Try as I might, I can’t find a single line of source code in the download of Intalio’s Community Edition ”open source BPMS.” Imagine my surprise at this considering they have been claiming open source leadership for years. They even call themselves “the leading Open Source BPMS company.” Sure, you can find source code for individual piece parts if you go to another website and find it as part of Intalio’s donations to open source projects, but here I am talking about their claims of open source leadership in regards to their Community Edition product.

Because of the complexity of enterprise software, I believe software companies have to hold themselves to a higher level of “truth in labelling.” We don’t like it when toothpaste has antifreeze in it. And I don’t like it when an purportedly open source product has no source and licensing restrictions that sound like they were written in Redmond or Walldorf.

It may be simplistic but calling something “open source” means you get source code. While Sandy Kemsley finds it amusing when I quote Wikipedia, the simple fact is that Wikipedia’s definition of FOSS says open source allows users to “…study, change, and improve its design through the availability of its source code” (emphasis mine). To call yourself the “open source leader” and to launch an “open source service” (whatever that is) means you should conform to the conventional definition of what FOSS is. And that ain’t what Intalio is doing, near as I can tell.

I was recently fact-checking an upcoming analyst report on BPMS in which the author mentioned in passing that Intalio didn’t actually include source in its Community Edition downloads. I was dumbfounded (and more than a little miffed that these analysts could so blithely give these guys a pass on so fundamental a point).

Incredulous, I asked our product management people to take a look. As willing as I am to call Intalio out for misleading users about its Community Edition, I am still not willing to cut and paste the heated analysis I got back from the product managers. So, let me try to summarize:

• As far as we can tell, the license included with their product includes the restriction that users may not “…decompile, disassemble, or otherwise reverse engineer or attempt to reconstruct or discover any source code or underlying ideas or algorithms of the Intalio Software by any means whatsoever…” (again, emphasis mine)
• As far back as 2006, Intalio was happy allow confusion between “open source-like” and real open source in its licensing to morph into “open source leadership.” (Here, you have to knock Gartner for not being more consistent and giving Intalio the room to claim open source street cred undeservedly.)
• At the end of the day, Intalio’s claim of an open source mantle isn’t about standards or FOSS, it’s about its sales model.

It’s that last point that I really object to. It’s OK to be proprietary. It’s OK not to ship the source code. What’s not OK is to use the terminology of standards and open source to confuse users for the (very legitimate) purpose of driving sales. That’s just misleading.

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 (174)

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?

David Worthington of SD Times covers the release of ActiveVOS 5.0 and writes that we have “…cracked the code to bring Web services into mass deployment for line of business applications.” The entire article is here.

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.