services – Page 17

Hey, you’ve got SOA in my BPM! No, you’ve got BPM in my SOA!

BPTrends has a newly-published article by a new author, Mike Rosen, on BPM and SOA. He makes the distinction between BPM and SOA, then wraps up with why they’re so complementary:

Together, BPM and SOA provide a perfect combination for enterprise computing. BPM provides the higher-level abstraction for defining businesses processes, as well as other important capabilities of monitoring and managing those processes. Services provide the functions that support those processes. SOA provides the capabilities for services to be combined together and to support and create an agile, flexible enterprise. BPM without SOA is useful for building applications, but difficult to extend to the enterprise. SOA without BPM is useful for creating reusable and consistent services, but lacks the ability to turn those services into an agile, competitive enterprise.

In other words, SOA provides the design philosophy and enterprise context for building services, and BPM orchestrates those services. Two great tastes, together at last.

He also discusses the practice of creating relevant services based on the required functionality of the enterprise, rather than just putting lipstick on the pig by developing a pass-through wrapper around each legacy application. There’s a good diagram in the article (it’s a PDF, so I can’t link to it directly) showing the layers and linkages involved.

Integration Trends 2006 webinar

Catching up on a few webinars that I missed live, I just reviewed the replay of ebizQ’s Integration Trends 2006. There’s a nice summary slide up front by David Kelly, an ebizQ analyst, where he talks about the current focus of most businesses (reducing costs, increasing flexibilty, becoming process-driven) and most IT departments (composite applications, modernizing legacy systems, moving to SOA and event-driven architecture). Certainly true for all of my customers.

The webinar was sponsored by PolarLake, makers of an ESB product, and it turns out that the CEO, Ronan Bradley, has a blog that includes some interesting stuff, such as his recent post that “exposes the myth” of run-time discovery of web services (he quotes and comments on a post on the same subject by Brenda Michelson). Alas, I’m unlikely to read his blog much since he chooses not to publish full feeds, and I find it too much of a hassle to click through to every blog on my list of daily reads.

Anyway, back in the webinar, Ronan Bradley made a huge point about how ESB is not EAI, but I’m not sure that the lines are that clearly drawn. David Kelly later asked how he made that distinction, and it seems to be based on attributes such as “distributed, standards-based, extensible” and providing “productivity and agility”, but I don’t think that the lines are that clearly drawn between ESB and EAI: it’s more of a spectrum of capabilities than the black-and-white picture that Ronan puts forward. He depicts EAI as having functionality without these attributes, “lightweight ESB” as having the attributes but little functionality, and (of course) PolarLake as having both the functionality and the attributes.

Of course, what vendor doesn’t find a graph to publish where they’re in the upper-right quadrant? Gartner probably just calls it all integration-focused BPM anyway.

Regardless of any distinction between EAI and ESB, he does make an interesting point about how orchestration isn’t so simple as it is often portrayed, but requires “mediation” around the orchestration that may be many times larger and more complex than the orchestration itself: things such as complex data manipulation and translation beyond simple XSLT transformation, interaction with existing infrastructure and applications, and complex and recursive data transformation, enrichment and management.

More on the Proforma webinar

I found an answer to EA wanna be!’s comment on my post about the Proforma EA webinar last week: David Ritter responded that the webinar was not recorded, but he’ll be presenting the same webinar again on December 9th at 2pm Eastern. You can sign up for it here. He also said that he’s reworking the material and will be doing a version in January that will be recorded, so if you miss it on the 9th you can still catch it then or (presumably) watch the recorded version on their site.

There’s a couple of other interesting-looking webinars that they’re offering; I’ve signed up for “Accelerated Process Improvement” on December 8th.

Bits and pieces

I’m heads-down on a project this week so not much time for catching up on the news and blogging. However, interesting things keep happening whether I’m watching or not…

RUNA WFE 1.0.1, an open-source workflow based on JBOSS-JBPM was released. More details here, including a link to an online demo. Open source BPM is going to be a market force in some sectors, so best to be aware of what’s happening there.
Greg Wdowiak published an interesting post on the role of integration brokers within an integration stack. In particular, he discusses what you should expect to get from the integration broker portion of the stack, and where some of the vendors are lacking. If you’re new to EAI, you can read his excellent background post on bus versus broker models. In particular, he talks about how organizations move from a broker to a bus model as their integration needs become larger and more complex.
BEA buying Plumtree has been all over the tech news, with lots of interesting analysis. MWD blog thinks that the purchase may not be about what BEA says that it’s about, but more about moving away from complete Java-centricity and into a more neutral technology territory by supporting .Net. The Butler Group sees this as a better fit than some of the previous portal buy-outs, although an earlier post ponders the fate of the Plumtree-Fuego OEM agreement in light of BEA’s existing BPM strategy.
On the enterprise architecture front, The first issue of the Journal of Enterprise Architecture was published. Via Nick Mudge’s blog.

Lastly, if you’re free today at noon Eastern, there’s a webinar roundtable on Winning at BPM discussing IBM‘s WebSphere process integration products.

Enjoy.

Convergence of BPM and BI

If you’re interested in more about the Forrester report about BPM and BI that I mentioned a couple of weeks ago, but still don’t want to shell out the cash for it, you can find a more complete summary on here on BPM.com (registration required), written by a Forrester VP who was one of the original report authors.

The more that I look at compliance, which I’ve been doing a lot of lately, the more that I understand that BPM needs to feed its performance data into a larger BI infrastructure. And I can buy into what the Forrester report refers to as Process to Data, or P2D (as if we needed another TLA), which is the two-way synergy between BPM and BI: BPM feeds process performance data to BI, and BI invokes processes in BPM in order to gather information. However, I have to draw the line at their statement:

BI and BPM can no longer live without each other, and the time is right for these technologies to merge.

I don’t think so, any more than BPM will merge with any number of other technologies, although obviously there will be closer and closer integration ties in order to make all of this work smoothly. BPM and BI are strong, distinct markets served by a variety of strong vendors, and customers develop quite a bit of loyalty to their BPM and BI vendors because both of these technologies are pervasive in an organization’s IT infrastructure. If BPM vendor A decides to merge with BI vendor B and suggests to their customer that they should change all of their existing BI from vendor C to vendor B, there would be a great deal of rolling around on the floor and laughing. There’s a much stronger argument to be had for merging BPM and BR (business rules), but I don’t think that’s going to happen either, for much the same reasons: both technologies have strong, independent markets (that is, the technologies can exist successfully in organizations without each other) and there is little reason for a customer to want to buy their corporate-wide BR from their BPM vendor, or vice versa.

If the merging that Forrester suggets actually occurs, we’ll end up with monolithic Swiss-Army-knife-like vendor offerings from a few large players — how retro! — and a lot of unhappy customers. What most customers want is the best of both worlds: the best-of-breed technology, and the minimum amount of integration; hence the huge popularity of SOA. In the past, you couldn’t get both: you could buy best-of-breed from different vendors and take a lot of effort to integrate it, or you could buy a fully-integrated suite from a single vendor that included at least one sub-optimal component. Today, however, with the advent of integration standards and SOA, the integration effort for properly-constructed products from different vendors should be no more than that required for products from the same vendor.

My conclusion: as long as the vendors do what they’re supposed to in order to enable easy integration, there’s very few customer drivers for merging BI and BPM.

Agility and BPMS Architecture

Bruce Silver writes about the distinction between workflow architecture and service orchestration architecture, pointing out why it’s important to distinguish between these two process architectures and see how they fit together. If you’re having trouble figuring out the difference between what the former workflow and former EAI vendors are saying, this might help.

He also discusses what’s changed in BPMS to actually make it as agile as the vendors would have you believe that it’s been all along: easier application integration. As he puts in, in the bad old days, when the EAI part of workflow systems didn’t work very well:

If you went to a workflow conference or trade show, any vendor could show you how to build a workflow in 30 minutes using no programming, just graphical drag-and-drop design. So once you bought the technology, why did it take six to twelve months to design and deploy real-world workflows?

There was a huge market for systems integration companies to do all that tricky application integration stuff — I know, because I ran a 40-person version of that model up until 2000, with a crack team that did design, development, testing, documentation, training and installation, all targeted at trying to turn the dream that the workflow vendors sold into a reality. If I hadn’t already got out of that business, I’d certainly be looking to do so now, as the EAI part of BPM gets easier and easier, leaving much less of the complex systems integration that used to drive a huge part of the market.

What I find amazing is that some of the large systems integrators continue to stick their heads in the sand and refuse to buy into the new way of doing things. Even though capabilities exist for much simpler (and therefore faster and less expensive) integration of BPMS with other technologies, the SIs have too much of a vested interest in selling huge pieces of custom code that they’ve written to augment previous versions of various vendor products, and the associated 1000’s of hours of customization that they can sell to the unsuspecting customer. They actually win work based on the premise that if it takes that long and costs that much, it must be good.

Back to the Silver article that started this thought, I also find it amazing when vendors (and therefore, by extension, their clients) don’t make the distinction between the two types of process architectures, and try to sell their legacy technology (usually either workflow or EAI) as if it spanned the entire space. Since most former workflow vendors have hopped on the EAI bandwagon by buying in that capability early, I see the problem more often with the former EAI vendors trying to sell service orchestration as if it were workflow, with only the barest of long-running process and human-facing capabilities. I remember leading a discussion on exactly this topic with a client’s IT group who had selected an EAI product as their BPM corporate standard, and never being able to get through to them that there are really two major classes of process functionality and architectures, only one of which was addressed by the product that they selected. Silver’s article may have helped.

SOA and banking

I viewed a webinar today featuring a senior integration architect at Bank of America talking about how they use webMethods to facilitate their massive integration efforts, apparently with some degree of success. I liked the admission by both the customer and vendor that SOA is an architectural design approach of loosely-coupled components, not a particular technology or product, although products can obviously help you to build a service-oriented architecture faster, cheaper and in a more standardized manner.

This definitely put me in mind of a recent engagement where I spent a year as the acting application architect for one business silo within a financial institution, facing many of the same business and technology challenges as BofA. I also sat on the architectural review board, so had a view of the common challenges across the entire organization and the technology infrastructure being deployed to address them. Almost all large financial institutions got big through a combination of acquisition and growth, and both of those growth methods can lead to disparate systems in the back office — even within one silo — that don’t intercommunicate well (if at all), which in turn leads to a lot of internal inefficiencies and a less-than-optimal customer experience. Furthermore, most organizations are not set up to share across the business silos, so attempts to create common infrastructure such as those that support SOA can be tricky unless an architect is empowered to work across the silos.

As you move up the services stack, the focus changes from the base services and registry layers (where webMethods plays) to orchestration, where services are assembled into processes that relate to actual business processes (you knew that I’d get around to process eventually, right?): the task flow and BPM layers in the integration stack that I referenced previously, although the lower levels of that particular stack are MOM (“first generation SOA”) rather than XML-based web services (“second generation SOA”). As you bring these concepts together, and especially when you start looking at the technology stacks, it becomes obvious that you can’t have an effective BPM strategy without SOA. You can implement BPM without SOA, but it won’t have the ability to become the strategic orchestration layer that’s required to pull together disparate systems and provide new integration functionality in the future.

The value of vendor white papers

Every vendor writes white papers that try to appear vendor-neutral (in an effort to build their street cred), but which have subtle — or not-so-subtle — hidden agendas. That doesn’t mean that you shouldn’t read them, just don’t take them as the whole truth and nothing but the truth. The best approach is to read a variety of sources on a subject from both vendors’ white papers and “independent” analysts (who, of course, have their own agendas as well) and start looking at the common themes and messages across all of them. If a vendor doesn’t mention something that is considered important by several others, that could highlight a missing functionality or flaw in their system. However, when one vendor offers an opinion that is vastly different from all the others, then either they’re trying to justify a flaw, or they’ve really discovered a better way of doing things and are the first to flaunt it. Don’t discount the latter possibility out of hand, because a vendor is much more likely to be silent about their flaws rather than try to justify them, so if they’re talking about it in a white paper, then they may have something to say.

I read a lot of vendor white papers and analyst reports because it’s my job to stay on top of what’s happening in the BPM and related spaces, and it’s nice to run across one that I can recommend every once in a while. Last week, I saw this report from Metastorm published on TechRepublic (TechRepublic free registration required to view) about choosing a BPMS. It includes five very valid steps along the selection path:

Consider the vendor’s core competence.
Consider the vendor’s reputation and position in the market.
Validate the essentials.
Evaluate implementation & maintenance requirements.
Ensure the solution can support your unique process needs.

and provides a checklist of activities as well as a description for each of these activities. In the first step, they take a direct shot at EAI vendors who have grown into the BPM space: a hidden agenda of sorts, since Metastorm built their product as BPM from the start, but one that I don’t necessarily disagree with:

Many of the solutions marketed for BPM today were not actually developed for BPM — for example, EAI may be great for data to data integration and automation of system flows, but because it was not developed to address human interaction, it is unlikely to be the ideal solution for human-intensive process management, where human involvement and decision making is key.

I’ve run into situations in the past where an EAI vendor has positioned themselves as BPM and made large (and inappropriate) sales because of it. At some point, however, an EAI vendor will presumabely have built sufficient BPM functionality and expertise to be allowed into the club. Furthermore, it’s fair to say that the line between EAI and BPM is sufficient vague that there will be many vendors who play in both arenas instead of being in one and interfacing to the other: check out my post last week on integration stacks as well as Gartner’s emerging view of what’s in a BPMS.

All in all, there’s very little in the Metastorm white paper that most other BPM vendors would disagree with. At only 2-1/2 pages of real content, it’s a somewhat superficial look at the vendor evaluation process, but a good starting point.

What’s in a name?

Just discovered mwd blog through their post about BPEL; they believe that the “business process” part of BPEL is a bit of a misnomer, and that “at the very best what vendors are really representing are definitions of integration processing.” I knew that I was in tune with these guys when I read their earlier post on ESB, which tears a strip off technical marketing types that invent new terms for existing concepts in order to attempt to achieve some sort of marketing advantage.

Their BPEL post also includes a link to a Bruce Silver article about BPM standards that’s definitely worth reading.

Integration stacks explained and compared

A good explanation of integration stacks (including EAI and BPM) by Greg Wdowiak. He makes a nice distinction between task flow management in the EAI layer and business process management in the BPM layer:

The Task Flow Management function of the broker coordinates relatively simple, short time activities amongst the integrated systems… The Task Flow Management function service translates the business task into a set of lower-level (often application specific) technical tasks.The Business Process Management function (BPM) coordinates long-running business processes. In many aspects, BPMS resembles Task Flow Management function. BPM differs from Task Flow Management in that:

It is geared towards managing tasks that may range from hours to months in duration. BPM persists its state in a database.

BPM focuses on business-level tasks, frequently tasks that are performed by humans. To support such tasks, BPM support sophisticates access control and authorization models, escalation procedures, task delegation, etc.

He goes on to compare the integration stacks of TIBCO and IBM, including the history of what was developed internally versus what was acquired, although he’s missing a few details about the BPM side of things since his expertise appears to lie at the EAI end of the spectrum (for example, the InConcert BPM product, now owned by TIBCO and probably soon to be discontinued, was originally developed by XSoft, a division of Xerox), but I think that this is a work in progress.

I really like that way that he overlays the five technology layers (connectivity, MOM, transformation & routing, task flow, and BPM) with the various products from both vendors so that you can see what’s what: something that most vendors don’t do, so it’s very hard to tell what portion of the stack that a product covers.

TIBCO and IBM definitely compete head-to-head technically at the MOM layer: I’ve seen a lot of holy wars about TIB/Rendezvous versus MQ Series in my financial services customers, and usually they end up with some of each, although MQ has a large enough market share to be considered a de facto standard. At the BPM layer, however, it’s hardly a fair fight: Staffware is recognized by Gartner as one of the top two or three pure-play BPM products, whereas MQ Workflow doesn’t even make it onto the chart. I wouldn’t be surprised to see IBM replacing MQ Workflow, or radically overhauling it, in the near future in order to remain competitive and get on Gartner’s pure-play BPM radar.

Greg’s impressions of the vendor smoke screens are bang-on:

IBM constantly re-brands products (most recently, pre-pending all names brands ‘WebSphere’) making it difficult to understand… Both [TIBCO and IBM] stacks include products with overlapping functionality. It is not clear from the vendor which product should be used under what circumstances; rather, both vendors attempt to create an impression of perfectly coexisting and augmenting each other components.

Some things never change.