VOSibilities

BPMN 2.0 and WS-BPEL 2.0 are the two most important standards for BPM today. But why are there two? Can’t you just care about BPEL or just care about BPMN? In fact, both standards matter and the two should be used together. To back that up, I have to convince you both that BPEL needs BPMN and that BPMN needs BPEL. In today’s post, I’ll concentrate on the first: why BPEL needs BPMN.

First, lets assume that you are convinced of the value of BPEL. You see that it is a great high-level language for creating business processes and orchestrating services. Its service-centric approach is simpler and better for long-term manageability and reuse than other approaches to business process management. It is an accepted OASIS standard with multiple vendor implementations, so investments in BPEL processes are not tied to a single vendor and you can find people who already know the language without having to train them from scratch.

But if you are convinced you want BPEL, why should you care about BPMN? There are two main reasons:

1) To get the value of a standard notation;

2) To improve collaboration with a wide variety of stakeholders in the process, since BPMN is a significant simplification over existing notations used for BPEL.

When WS-BPEL 2.0 was standardized, the OASIS Technical Committee chose not to standardize a graphical notation for it. This was unfortunate, since no one creates a business process by writing BPEL in XML, which is the only standardized representation. Every vendor, and every BPEL developer, creates their processes using a graphical representation, but that representation is different for every tool.

And the notations used by these tools haven’t really been very good. They typically provide a one-to-one correspondence between control flow constructs in BPEL and things on the canvas. However, if you use the BPMN notation, it shows a notation that can mostly be understood without any knowledge of BPEL or even BPMN for that matter (as long as the labels are chosen carefully).

Let me make both of these points with the help of a trivial process example. Take a look at the BPMN representation of a process that I’ll call the “Question” process.

(Click on each image to see a larger version)

It is trivial to follow what is going on, especially if you know the standard notation. You can’t tell by looking at this diagram, but I’ve used two different BPEL mechanisms for getting to the next activity. I use a BPEL link to get from “Receive Q” to the first diamond (the beginning of the BPEL if statement). I use a BPEL sequence to get from the second diamond (the end of the if) to the “Record Answer” activity.

The user who is looking at the graphical representation of the process doesn’t need to know about the distinction between these two mechanisms, so the diagram doesn’t show a difference. The developer may want to know about the difference, so ActiveVOS highlights them differently on mouse-over and shows them differently in the “process outline view”, but that isn’t really important for today’s discussion.

What is important is how different the process is represented in different tools due to the fact that no notation had been standardized. I’ll show what this process looks like in three different BPEL process designers.

Here is how ActiveVOS would represent this process in previous versions of the product (or using the optional “classic” style in 7.0):

Here is how the Eclipse BPEL Designer represents it:

And, here is how the designer for Oracle’s BPEL Process Manager represents it:

In all three of these representations, each of the paths through the if statement are represented by a bounding box. The problem with this representation is that nested if statements can result in so many nested bounding boxes that it is hard to follow what is going on. BPMN simply has arrows through each path and the paths merge back into a single control flow at a gateway diamond.

Also notice the differences in the handling of links vs. sequences. Both ActiveVOS classic and Eclipse represent sequences with their own bounding boxes, then any arrow that is a direct child of a sequence box is known to belong to the sequence, rather than being a real link. Eclipse also draws the links in different color. The extra sequence icon and corresponding bounding box just interferes with the ability for non-technical users to follow what is going on in the process.

Oracle’s designer is odd in this respect. Sequences are not shown in a bounding box, so they don’t clutter up the control flow (a good thing in my opinion), but links aren’t shown at all! There is a link from the “Receive_Q” activity to the if statement, but there isn’t any representation of it on the diagram. It shows the “Receive_Q” and the if as if they happen in parallel. You have to look into the properties of “Receive_Q” to discover that it has an outgoing link, and further rummaging to find out where it goes.

The BPMN representation is, by far, the easiest version of this small process to understand. The process illustrates just three constructs whose representation is simpler with BPMN than with other approaches: ifs, sequences and links. The other BPEL constructs are generally as easy or easier for non-technical users to understand than previous approaches.

But, as valuable as the improvement in readability may be, the greater value that BPMN brings to be BPEL is probably consistency. Having different tools represent similar constructs in such different ways is detrimental to one of the key values in having a standard: skills portability. With a common notation, people will be able to carry their knowledge of how to understand and work with standards-based business processes between vendor tools. It will also create a greater incentive for people to learn these technologies and for schools to teach them. After all, people aren’t usually to thrilled about investing a lot of energy into learning proprietary technologies, and no school really wants to be teaching proprietary technologies.

I’ll bet that it felt like a momentous achievement to get a group of very well-known bloggers, analysts and technologists to agree on a “manifesto” for services-oriented architecture (SOA).

Imagine the group-think of it all: a bunch of people with widely-varying views came together and produced….yet another statement. I imagine the camaraderie and group hugs that must have accompanied this effort resulted in repeated choruses of Kumbaya…or at least a serious drinking party to celebrate the achievement. (Guess which we like better.)

OK, OK…I know there’s no reason to be snide. And, yes, I realize that the manifesto is unobjectionable..that criticizing it is the equivalent of dissing motherhood or sunshine or quarks.

But the big problem for SOA — which is “dead” one moment and “strategic” the next — is that it doesn’t need yet another descriptive manifesto…it needs manifestation. Consider the definitions of manifesto and manifestation. Manifesto is about intention. Manifestation is about materialization. One is talk. The other is about something real.

And high-faultin’ talk has been SOA’s problem for…well…forever. While it’s good fun to have an ole-time, intellectual techno-debate about this aspect of implementing SOA versus that technique for doing it, the consistent response to SOA from legions of developers has been, “We just don’t care. And, not only don’t we care…since you are making this so hard, we’re gonna stay right where we are doing things as we have always done them. Good luck with your SOA thing.”

What happens when industry thought-leaders run smack into the biggest wall of them all: developer resistance? They talk some more. Consultants build big engagements to explain to management how to get around developer resistance. Vendors who bought one of everything and lumped it all together as “SOA” have made implementing their stacks so expensive and complicated they advocate “centers of excellence” — that is, internal lobbying groups — who try to explain it all to the average development team using…guess what…still more words.

In short, SOA needs fewer words and more products mere mortals can use.

How about we manifest SOA in products so that it’s invisible? So that you can do the right thing without knowing the first thing about SOA? Do civil engineers demand that we understand the properties of asphalt before we drive on it? Must you ascertain the precise chemical composition of your dinner before you eat it? No, we just drive home at night and stick a fork into the main course. We don’t think twice about it.

That’s what SOA needs to be (and what we think ActiveVOS achieves). As an industry, we need to take what we know, stop talking about it and scaring people off — and build it into shrinkwrap-like product that have people doing the right things automatically.

We are pleased to present the latest episode of Dana Gardner’s BriefingsDirect Analyst Insight. This time Dana talks with noted industry analyst Dave Linthicum about his new book on SOA and cloud computing.

We hope you enjoy this fascinating interview. Also, in case you’re interested, you can also access a white paper Dave recently wrote on SOA development tools here.

 

 BriefingsDirect Analyst Insights Podcast #45: Dave Linthicum's new book on SOA and cloud computing [45:40m]: Play Now | Play in Popup | Download (2079)
 BriefingsDirect Analyst Insights Podcast #45: Dave Linthicum's new book on SOA and cloud computing: Download (152)

Scary big. That is how big Oracle is in middleware. After bragging that they had beat BEA to be #2 in the middleware market, they bought them. Then, with the acquisition of Sun, Oracle has control over the underlying technologies of Java and Java EE, plus the primary open-source challenge to their database dominance. Of course, IBM has also done its share of gobbling up middleware companies, so between them, the number of products and acquisitions has become overwhelming. We made exactly that point last week at Oracle “Open”World by dressing up actors as prisoners “shackled” to Oracle SOA Suite (Check out the hi-jinks here, here and here.)

Up to now, enterprises have typically had one choice that drove most other technology choices in the data center: .Net or Java. If you chose .Net, then you are a Microsoft shop and you’ve decided that the advantages of living in a single vendor world outweigh the disadvantages of being tied to that one vendor. However, if you chose to go with Java, you probably did so because you wanted to then live in the world of standards-based technologies, where for each technology purchase, you could separately evaluate products from a number of competing vendors.

But now, with much of the Java middleware world being absorbed into one of two vendors, the era of having a choices for each purchase is coming to an end. Instead, there will be just one big decision. Do you want to be a Microsoft shop, an Oracle shop or an IBM shop? All other decisions will flow from that initial decision. This is because the development teams in each of those companies will naturally be forced to give a high priority to getting any new software to work with existing software from the same company. Getting it to work with the other company’s software will be a “goal,” but as someone deeply involved in the development of software products, trust me when I tell you those are the kinds of goals that tend to slip as the ship date of any product nears.

Does it matter? Isn’t three enough? Yes, it matters. And no, three isn’t enough. Actually, the real problem isn’t the small number of choices; it is that the switching costs are just too high. If there were three good choices for each purchase, that wouldn’t be so bad. But when you are virtually locked into a single vendor for each new purchase once you’ve started down the road of buying from them, then it is a real problem. The lack of competition for individual products removes critical competitive pressures from individual product lines, so the products grow to become heavy, badly integrated, expensive beasts.

And, if enterprises have to pay more for lower quality software on their servers, this affects everyone. The ultimate consumer pays for the more expensive software in higher prices, but they pay even more for the lower productivity that comes from software that is hard to use, hard to manage, and unresponsive to the needs of the business.

We get up in the morning and think about what we can do to make ActiveVOS the antithesis of the bloatware from Oracle and IBM.

Last week, CTO Michael Rowley and I showed ActiveVOS 7 to Rob Barry of TechTarget’s SOA Talk blog.  I know it’s a party foul to quote yourself in a blog post, but we are grateful that Rob chose to highlight one of the main accomplishments we believe we have achieved for BPM in ActiveVOS 7:

“BPM suites that focus on business users, they don’t get technical enough,” said Alex Neihaus, VP of marketing at Active Endpoints. “They become islands of computing and sit off by themselves. And with BPMS for architects and developers, the level of cost and complexity is beyond the level of what most people are willing to undertake.”

This “third way” between the cost and complexity of stacks from Oracle and IBM and the unfulfilled promises of Lombardi and Pegasystems to integrate easily across the enterprise are why we believe we have become so popular among development teams. Looking past old buying habits and the new politics of “end user” BPM, our customers are seeking great technology at an affordable price that can be used to create integrated processes as that are themselves services.

You can read Rob’s entire blog post here.

As we promised in part 1 of of our discussion on the new features in the ActiveVOS 7 BPMS, we are delighted to post part 2 of a conversation among me (Alex Neihaus), Luc Clément and Michael Rowley. In this second podcast, Michael and Luc cover topics that are of interest to enterprise architects, developers and operations staff. Topics include continuous development (including support for the open-source Hudson project) and new features in the BPMN designer that improve productivity and operational enhancements.

We hope you enjoy this podcast.

 

 VOSibilities podcast #37: ActiveVOS 7.0, part 2 [28:32m]: Play Now | Play in Popup | Download (1360)

We are very pleased to announce ActiveVOS 7.0. The full press release is attached to this post. You might also be interested in seeing our new screenshot tours, browsing detail about the new release’s features and reading What’s New in ActiveVOS 7.0.

 Active Endpoints announces ActiveVOS 7.0: Download (393)

One of the hottest topics in enterprise computing today is the proper relationship between business users and IT. Our CEO, Mark Taber, blogged about one aspect of this important topic just yesterday. Also yesterday, Gartner’s Jim Sinur wrote a very compelling post asking additional questions about the proper relationship between IT and end users.

Today, we are pleased to make available a new white paper by well-known industry analyst Sandra Rogers which offers additional insight into this very question.

Here’s an excerpt from the paper:

Organizations are discovering that the use of more visual and self-documenting solutions can better ensure that requirements are commonly understood and agreed upon, and measure if certain business goals met. Utilizing BPMSs like ActiveVOS that help individuals capture current and future state, that are easier to use and allow for multiple and concurrent cycles while designing and enhancing business processes, can greatly impact overall results. The use of such technology that provides deeper transparency into one’s processes, enables the sharing of best practices, and allows business stakeholders building degrees of freedom in adjust application and process parameters can help bring all parties into further alignment.

We hope you enjoy Sandy’s paper.

 Aligning For a More Successful Business and IT Development Paradigm: Download (551)

Joe McKendrick has revisited the debate about the relationship of BPM and SOA by commenting on JP Morgenthal’s assertion that SOA and BPM initiatives should be kept separate.

With all due respect to JP, we think he’s got it wrong. BPM and SOA do need to be reconciled.

JP seems to have fallen into a trap that confuses the need to achieve two complimentary goals with the need to combine the initiatives that strive for those goals.

So sure, the initiative to introduce a business process culture into an organization should be separate from an initiative that drives toward a service-oriented architecture, but both initiatives have to be able to succeed. Those that merely view BPM as the killer application that justifies purchasing stacks of “SOA” middleware are missing the key “BPM” value proposition. Conversely, pure-play BPMers risk building impenetrable fortresses of locked in process that can’t be shared/reused.

In JP’s world, the benefits of BPM will not materialize for either the business which is trying to rationalize work or by the architecture groups trying to rationalize infrastructure supporting that work. In order for them both to succeed, any application that is developed with a BPMS must introduce its new functionality as a collection of services.

Implementing “BPM” does not suddenly provide an excuse to intertwine business logic with presentation logic. Reusable services must be created in order for the long-term success of the enterprise and its BPM initiatives. BPM must be inclusive – not a fiefdom.

Workflow, human interaction, reports, event processing — all need to be incorporated in a service-based architecture if we’re ever to get to better business (i.e. BPM) and IT (i.e. infrastructure) alignment. In other words, BPM itself needs to be service-oriented.

Without a major course correction in current BPM-SOA approaches (with BPM as a consumer of services only) the respective visions of BPM and SOA stakeholders will not materialize. A service-oriented BPM has a much better chance of yielding an outcome where BPM and SOA can actually share and deliver on a common vision. Claiming, as JP does, that SOA and BPM “are not – repeat not – related” gives the incorrect impression that people who are creating business processes don’t need to care about SOA and that people creating services don’t need to care about BPM.

Neither is true.

As an enterprise architect, you have a tough job. Business people do not want to be “governed.” They see no need to use the infrastructure that you have carefully put in place. The more rigid you are, the more likely they will find a way to circumvent. Even if you find out they have ignored your policies, you are frequently not empowered to make them use the infrastructure. Further, while you know that building standards-based/service-oriented applications is clearly the best practice, SOA is probably not an “official” direction. Business users can still complain to their vice presidents that middleware is an impediment. Every day you are either awarded a medal or put in front of a firing squad.

The trend towards “the business” developing and running business process management systems is reflective of this destructive mindset of going around IT. We all know that they can be successful with “happy path” workflow modeling. But do we really want business users, with their own servers, managing and changing mission critical applications? Of course not. Islands of BPMS that exist outside of IT will eventually fail because of all the necessary exception handling, the effort required to get the data and deployment right, system-to-system integration and the lack of rigor around the software development life cycle.

The answer is a BPMS that lets the developer stay in their current tools, lifecycle, etc.  It is a given that, as vendors, we must lower the level of pre-requisites to allow non-programmers to do serious modeling, as well as build, test, deploy and optimize processes. Further, we must use collaboration diagrams to work with the more technical of business analysts so that they can sketch out requirements, modify/edit forms and storyboard. A portion of these analysts may even be able to adapt a process making quick changes to application templates.

As an enterprise architect, start thinking about creating a “federated” BPMS or orchestration layer in your architecture that facilitates the creation of business services. ESBs may be useful but are frequently not necessary and certainly should not be mandated. A BPMS should be able to run anywhere without infrastructure dependencies. The standards are there and becoming well established: BPMN for modeling, BPEL for executing business processes, WSDL for SOA services, WS-HumanTask for task management and XSD for data representation.

Business Process Management and SOA are not precise games. There will always be a balancing act to deliver the benefits. Don’t try to boil the ocean. Pragmatic adoption will allow you to both keep the business happy and support the long term goals of your CIO. ActiveVOS makes it easy. You can download a free, 30-day trial.  We have a rich set of content on our website that will quickly get you started but if you need help, our technical support people are standing by.

Don’t wake up a year or two from now only to find the company’s core applications running under desks in every fifth office.  You will never get them out!

I’ve just run across a blog I wanted to give a “shout out” to. On Vijay’s Narayanan’s Software Use in the Real World blog, there’s a variety of good technical info, an interesting podcast and some good advice for making some of the more complicated concepts in software resuse comprehensible.

It looks like Vijay only started blogging in March. I hope he finds the time to keep it up. As anyone who’s blogged consistently can tell you, it takes a lot of work and dedication to keep a blog “alive” and interesting.

With 90 days or so under his belt, Vijay might be wondering if it’s worth it. So, head on over to his blog, check out his posts and podcast and help convince him to stick with it. We can all benefit from more voices on good software design, especially from people who are consuming BPM systems in applications they develop in their daily work.

We are very pleased to include a podcast produced by Peter Schooff of eBizQ in our podcast feed. In this short 6:30 minute podcast, Peter interviews our own Michael Rowley on why a good BPMS (business process management system) needs to include both services and human tasks. When a standards-based way to include people activities in a BPM application is available, developing end-to-end, integrated applications is easier and faster. We believe that every BPMS must deliver both human tasks and machine (or services) integration to be a real solution to the challenge of creating BPM applications.

 

 BPM That Includes Both Services and People: A Talk with Active Endpoints [6:50m]: Play Now | Play in Popup | Download (2207)

Integration developer Adam Swift at Fastenal describes how his team uses ActiveVOS to quickly implement SOA-based applications for vital business processes, including an order management system. Read the article here.

Today, Active Endpoints announced the winners of the Bring SOA Home for the Holidays contest, where entrants were asked to submit something which shows how they used their free, 30-day supported trial of ActiveVOS in the development of their own BPM and SOA applications in exchange for a chance to win one of three Lenovo^® IdeaPad^® netbooks.

Selected from hundreds of entries, the three winners were chosen based on creativity, thoroughness and quality of work:

1st place: Brian Carey, President, Simple Empowerment of BPMS, Inc. (client project: Perot Systems)

2nd place: Ervin Nemesszeghy, Software Architect/Java EE Developer, Hardcomsoft

3rd place: Karl Geppert, CTO, Chemwatch

Wanna win some cool prizes?  Enter our current contest BPM in a Bottle for your chance to win either a T-Mobile® G1™ smart phone with Google™ or a Logitech® Squeezebox™ Boom network music player. Contest ends March 27 so don’t delay!

Ann Thomas Manes, vice president and research director for application platform strategies at Burton Group, has created quite a stir in her recent post where she says that although the term “SOA” is dead, the requirement for service-oriented architecture is stronger than ever. In this lively podcast, Dana Gardner interviews a panel of industry luminaries to help calibrate the life span of SOA and to expand on Ms. Manes’ position on SOA being under significant pressure, in particular due to today’s abysmal economic climate. Panelists include: Anne Thomas Manes; Tony Baer, senior analyst at Ovum; Jim Kobielus, senior analyst at Forrester Research; Joe McKendrick, independent analyst and prolific blogger on ZDNet and ebizQ; Dave Linthicum, founder of Linthicum Group and; JP Morgenthal, senior analyst at Burton Group.

Have a listen to this podcast and determine for yourself whether SOA is dead or alive. Whichever camp you belong to, we hope you’ll agree that ActiveVOS is truly an affordable, 100% standards-based, all-in-one BPMS that delivers “architecturally correct” SOA-based applications easily and quickly, empowering you to achieve your services goals today.

 

 BriefingsDirect Analyst Insights Podcast #36: SOA - dead or alive? [58:34m]: Play Now | Play in Popup | Download (290)
 BriefingsDirect Analyst Insights Podcast #36: SOA - dead or alive? (transcript): Download (361)