The acquisition of webMethods by Software AG that I wrote about in April has finally come to fruition, although the planned press/analyst web conference on Friday somehow managed to crash the hosting provider's servers so I didn't get all the gory details. From their press release, however, it appears that the webMethods brand will be retained, and Software AG's current Crossvision business will be renamed as webMethods.

Posted by Sandy Kemsley at 05:32 PM in BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

There's a webinar going on right now (12 Eastern) on ebizQ about which comes first, BPM or SOA, featuring Colin Teubner of Forrester. I like his agenda point: "Why SOA needs BPM (and not vice versa)".

Posted by Sandy Kemsley at 12:06 PM in BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Mariano Benitez of BEA (part of the original Fuego team that built what is now ALBPM) and Bhaskar Rayavaram of Bear Stearns (who was with Fuego before joining Bear Stearns) presented a unified view of BPM and SOA.

Benitez started with some pretty basic stuff about how BPM consumes services, either system-level or presentation-level, and how services can be introspected for easy integration. He then discussed ALBPM as producing services, that is, it can create services that can be consumed by other applications. This was much more interesting and comprehensive; however, overly dense with jargon and acronyms, and obviously dependent on us having attended the session immediately prior in that track (which I didn't). There's a number of mechanisms for producing services using ALBPM:

• Web service front-end to a small set of process API (PAPI) functionality, such as instantiating processes, that's part of Workspace; it appears that all PAPI-based web services use a common WSDL that expose the methods of PAPI.
• Process web services, which are similar to the PAPI web services in functionality, but are implemented in the execution engine rather than Workspace. This can only be used to create instances and send notifications, but is designed as part of the process and provides a unique WSDL for each process.
• Extended web services, which provides a component-level service; obviously I'm missing some key piece of information because I really have no idea what he's talking about here. :)
• HTML API framework (formerly WAPI), which allows for the creation of simple HTML forms that can be called as services in order to call Workspace operations.
• JSR168 portlets, to provide portlet functionality to render Workspace operations.
• And if you really want to beat yourself up, you can create plain Java wrappers for PAPI in order to create custom services, or JMS for asynchronous services.

All of this reinforces my impression that BEA's BPM product focus is still too much on hard-core developers -- the same ones that are writing services at the SOA level -- and not enough on the business side. If I think about this morning's presentation by PG&E, he placed BPM on the IT side of the house, with a process modelling layer as being the business side's participation point. Whatever happened to that lovely zero-code BPM that I saw in Fuego?

Rayavaram talked about how Bear Stearns is using BPM in an SOA environment: how processes identify candidates for service enablement, rather than implementing services then looking for processes that might use them. They're also accessing Fair Isaac's Blaze business rules management system via web services calls from the processes. They have a loose coupling of processes and services, with services deployed separately now but with a view to migrating to an ESB and a full event-driven architecture.

Posted by Sandy Kemsley at 05:43 PM in BEAparticipate • BPM • SOA | Permalink | Comments (2) | TrackBacks (1) | Add to del.icio.us

For the first breakout session, I attended BPM 101 for Portals to hear Jesper Joergensen of BEA's product marketing group and Bob O'Connor of Pratt & Whitney. Jesper started out by giving a brief review of BPM (the usual model/execute/analyze/optimize cycle), since this session is in the portals track and most of the audience is likely much more familiar with portals than with BPM. However, since the description claims that he's also going to discuss how process and portals can work together, I want to hear their message on this since I'll be speaking about BPM at a portals conference in two weeks.

O'Connor then told us about how Pratt & Whitney is using portal technology and -- soon -- ALBPM. They've had a customer portal since 2001, but had a lot of business processes that didn't mesh together very well. In 2002, they added SOA functionality that allowed data to be pulled from multiple systems and presented to the customer, such as all maintenance information for a specific engine based on the serial number. In spite of their advances in their customer portal, however, they still had a number of disparate departments with their own business processes, and no real end-to-end enterprise view of processes. That means that lag time between the separate processes wasn't necessarily logged as part of the end-to-end cycle time for an engine overhaul, for example, but definitely impacted the customer. Since it was between processes, that time was no one's responsibility until they started looking at business processes as they span the enterprise, not just within functional silos.Today, they're doing "manual BPM" for collaboration around engine overhauls, where 1000's of process steps and approvals are logged and uploaded so that customers have a near-real-time view of the overhaul process.

For the past year, they've been working with ALBPM (although they're just starting to roll out BPM applications), and see great potential value from combining ALUI and ALBPM to automate the processes using BPM and provide the necessary visibility into those processes via portals. Their initial processes include line maintenance order-to-cash (where any delays in the process severely impact the customer), quality process clinic management, help center routing, overhaul records coordination, employee awards, engine events management, engine wash, and shop processes. Some of these smaller processes took only a day or two to create in ALBPM, while their internal IT had quoted several months and several hundreds of thousands of dollars to do the same thing. They're pulling data from SAP and other enterprise applications into ALBPM at the start of the process, then feeding back any updates at the end; I would have thought that they'd use web services for at least SAP in order to do interactive updates rather than have to deal with the potential for mis-synchronization between BPM and the back-end systems.

They're doing some pretty innovative combinations of technologies to shorten maintenance cycle times, for example, RFID and other sensors to detect any engine problems while a plane is still in the air allow dispatching of maintenance personnel to be at the site when the plane lands. The time to service the engine may be the same, but the down-time for the aircraft is greatly reduced, which shows a commitment to their customers' concerns.

O'Connor, as a BPM department of one person, is part evangelist and part BPM developer (without having much of an IT background), helping to figure out how BPM can be used across Pratt & Whitney and help implement the solutions.

Although this presentation was really about BPM, I can understand why it's in the portals track: since Pratt & Whitney was a big portals customer first, this shows how you can successfully add BPM to a portal environment.

Posted by Sandy Kemsley at 05:41 PM in BEAparticipate • BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Last up before the morning break was Brian Abrahamson, Director of Enterprise Architecture at PG&E; although I've been interested in the portal presentations prior to this, I was relieved to finally get some BPM/SOA content. They started on a huge business transformation strategy two years ago due to various factors such as deregulation and changing legislation that are impacting the competitive landscape in the utility industry, forcing them to become more competitive. Price is certainly a point of competition, but they also have customer service issues such as managing unexpected outages (e.g., what Abrahamson referred to as a "car-pole incident"), installing new residential service, and managing regular maintenance and work orders.

They made an explicit decision to create an SOA layer that would leverage their SAP and Oracle systems in order to provide a more agile development environment. They've been using EAI technologies for a number of years to create integration between enterprise applications, but most of the business processes were embedded in these applications rather than being explicitly defined and executed. Their current direction, therefore, is moving from application-centric to process-centric by allowing the construction of composite applications and business processes from the services provided by the enterprise applications. They consider BPM to be a strategic enabler of their future vision.

What they've done so far is to expose services from the enterprise applications, and used ALSB as an enterprise service bus. ALBPM then allows those services to be used, via the bus, to create executable business processes using those services. As soon as they started exposing BPM to their internal clients, however, there was an immediate demand for modelling, simulation and analytics; now, they're planning for a business process modelling layer that allows their business analysts to do all of these with some type of more comprehensive BPA tool, with round-tripping as a key requirement. Above all of layers is a process architecture and governance layer that, like the modelling layer below it, is business-driven, whereas they see the BPM, ESB and SOA layers as being IT's domain.

They have realized a couple of key points: from the IT side, SOA provides a service layer than greatly expedites BPM; from the business side, cross-departmental process optimization is key to future growth. They have a business process competency centre that does mainly paper-based and manual modelling and analysis, which is a big driver for getting the business process modelling layer in place in their BPM stack.

They learned some valuable lessons along the way: put SOA principles and practices in place early; get executive sponsorship of BPM initiatives; business process modelling, management and governance is more of a business issue than a technology tool issue; and lastly, the market is still maturing and requires partnering with some key technology partners.

Posted by Sandy Kemsley at 10:28 AM in BEAparticipate • BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Thursday morning, and it seems like a few of us survived last night's baseball game (and the after-parties) to make it here for the first session of the day. This will be my last session of the conference, since I have a noon flight in order to get back to Toronto tonight.

Tim Stephenson and Mark Elder from TIBCO talked about Business Studio, carrying on from Tim's somewhat shortened bit on Business Studio on Tuesday when I took up too much of our joint presentation time. The vision for the new release coming this quarter is that one tool can be used by business analysts, graphical tools developers and operational administrators by allowing for different perspectives, or personas. There's 9 key functions from business process analysis and modelling to WYSIWYG forms design to service implementation.

The idea of the personas within the product are similar to what I've seen in the modelling tool of other BPMS vendors: each has a different set of functions available and has some different views onto the process being modelled. Tim gave some great insight into how they considered the motivations and requirements of each of the types of people that might use the product in order to develop the personas, and showed how they mapped out the user experience flow with the personas overlaid to show the interfaces and overlaps in functionality. This shows very clearly the overlap between the business analyst and developer functionality, which is intentional: who does what in the overlap depends on the skills of the particular people involved.

As we heard in prior sessions, Business Studio provides process modelling using BPMN, plus concept modelling (business domain data modelling) using UML to complement the process model. There's a strong focus on how BPM can consume web services and BusinessWorks services, because much of the audience is likely developers who use TIBCO's other products like BusinessWorks to create service wrappers around legacy applications. At one point between sessions yesterday, I had an attendee approach me and thank me for the point that I made in my presentation on Tuesday about how BPM is the killer app for SOA (a point that I stole outright from Ismael Ghalimi -- thanks, Ismael!), because it helped him to understand how BPM creates the ROI for SOA: without a consumer of services, the services themselves are difficult to justify.

We saw a (canned) demo of how to create a simple process flow that called a number of services that included a human-facing step, a database call to a stored procedure, a web service call based on introspecting the WSDL and performing some data mapping/transformation, a script task that uses JavaScript to perform some parameter manipulation, and an email task that allows the runtime process instance parameters to be mapped to the email fields. Then, the process definition is exported to XPDL, and imported into the iProcess Modeler in order to get it into the repository that's shared with the execution engine. Once that's done, the process is executable: it can be started using the standard interface (which is built in General Interface), and the human-facing steps have a basic form UI auto-generated.

It is possible to generate an HTML document that describes a process definition, including a graphical view of the process map and tabular representations of the process description.

As I mentioned in other posts, and in many posts that I've made about BPA tools, is that there's no shared model between the process modeller, which is a serious issue for process agility and round-tripping unless you do absolutely nothing to the process in the iProcess Modeler except to use it as a portal to the execution repository. TIBCO has brought a lot (although not all) of the functionality of the Modeler into Studio, and are working towards a shared model between analysts and developers; they believe that they can remove the need for Modeler altogether over time. There's no support at this time, however, to being able to deploy directly from Studio, that is, Studio won't plug directly into the execution engine environment. Other vendors who have gone the route of a downloadable disconnected process modeller or a separate process discovery tool are dealing with the same issue; ultimately, they all need to make this new generation of modelling tools have the capability to be as integrated with the execution environment as those that they're replacing in order to eliminate the requirement for round-tripping.

Posted by Sandy Kemsley at 12:59 PM in BPM • BPM standards • SOA • TUCON | Permalink | TrackBacks (0) | Add to del.icio.us

Last in the morning's general session was Tom Laffey, TIBCO's EVP of products and technologies, and Matt Quinn, VP of product management and strategy. Like Ranadivé's talk earlier, they're talking about enterprise virtualization: positioning messaging, for example, as virtualizing the network layer, and BPM as enterprise process virtualization. I'm not completely clear if virtualization is just the current analyst-created buzzword in this context.

Laffey and Quinn tag-teamed quite a bit during the talk, so I won't attribute specific comments to either. TIBCO products cover a much broader spectrum that I do, so I'll focus just on the comments about BPM and SOA.

TIBCO's been doing messaging and ESB for a long time, and some amount of the SOA talk is about incremental feature improvements such as easier use of adapters. Apparently, Quinn made a prediction some months ago that SOA would grow so fast that it would swallow up BPM, so that BPM would just be a subset of SOA. Now, he believes (and most of us from the BPM side agree :) ) that BPM and SOA are separate but extremely synergistic practices/technologies, and both need to developed to a position of strength. To quote Ismael Ghalimi, BPM is SOA’s killer application, and SOA is BPM’s enabling infrastructure, a phrase that I've included in my presentation later today; like Ismael, I see BPM as a key consumer of what's produced via SOA, but they're not the same thing.

They touched on the new release of Business Studio, with its support for BPMN, XPDL and BPEL as well as UML for some types of data modelling. There's some new intelligent workforce management features, and some advanced user interface creation functionality using intelligent forms, which I think ties in with their General Interface AJAX toolkit.

Laffey just defined "mashup" as a browser-based event bus, which is an interesting viewpoint, and likely one that resonates better with this audience than the trendier descriptions.

They discussed other functionality, including business rules management, dynamic virtual information spaces (the ability to tap into a real-time event message stream and extract just what you want), and the analytics that will be added with the acquisition of Spotfire. By the way, we now appear to be calling analytics "business insight", which lets us keep the old BI acronym without the stigma of the business intelligence latency legacy. :)

They finished up with a 2-year roadmap of product releases, which I won't reproduce here because I'd hate to have to embarrass them later, and some discussion of changes to their engineering and product development processes.

Posted by Sandy Kemsley at 01:28 PM in BI • BPEL • BPM • BPMN • BRE • SOA • TUCON | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

Bob Glushko, a prof at UC Berkeley, and Shelley Evenson, a prof at CMU, discussed different views on bridging the front stage and back stage in service system design. As a side note, I have to say that it's fun to be back (temporarily) in an academic environment: many of these presentations are much more like grad school lectures than standard conference presentations. And like university lectures, they cover way too much material in a very short time by speaking at light speed and flipping slides so fast that there's no time to even read what's on the slide, much less absorb or document it. If I had a nickel for every time that a presenter today said "I don't have time to go into this but it's an important concept" while flipping past an interesting-looking slide, I could probably buy myself the drink that I need to calm myself after the information overload. :)

Glushko posits that greater predictability produces a better experience, even if the average level of service is lower, using the example of a self-service hotel check-in versus the variability of dealing with a reception clerk. Although he doesn't mention it, this is exactly the point of Six Sigma: reducing variability, not necessarily improving service quality.

He goes on to discuss the front stage of services, which is the interaction of the customer or other services with the services, and the back stage, which is the execution of the underlying services themselves. I love his examples: he uses an analogy of a restaurant, with the front stage being the dining room, and the back stage being the kitchen. Front stage designers focus on usability and other user interface factors, whereas the back stage designers focus on efficiency, standardization, data models and the like. This tends to create a tension between the two design perspectives, and begs the question if these are intrinsic or avoidable.

From a design standpoint, he feels that it's essential to create information flow and process models that span both the back and front stages. The focus of back stage design is to design modular and configurable services that enable flexibility and customization in the front stage, and to determine which back stage services you will perform and which you will outsource/reuse from other service providers. Front stage design, on the other hand, is focussed on designing the level of service intensity (the intensity of information exchange between the customer and the service, whether the service is human or automated), and to implement model-based user interfaces and use these models to generate/configure/specify the APIs of user interfaces for the services. By exposing back stage information in front stage design, more back stage information can improve the immediate experience for a specific customer, and can improve subsequent experiences. Data mining and business intelligence can also improve service for future customers.

Evenson, who specializes in interaction design, has a very different perspective than Glushko, who focusses on the back stage design, but rather than being opposing views, they're just different perspectives on the same issues of designing service systems.

She started out with a hilarious re-rendering of Glushko's restaurant example by making the point that she applied colour to make the division of the co-production between front and back stage more visible.

Her slides really went by so fast that I was only able to capture a few snippets: sensors will improve the degree of interaction and usefulness of web-based services; technology influences our sense of self; services are activities or events that form a product through interaction with a customer; services are performances: choreographed interactions manufactured at the point of delivery; services are the visible front end of a process that co-produces value. A service system is a framework that connects service touchpoints so that they can sense, respond and reinforce one another. The system must be dynamic enough to be able to efficiently reflect the expectations people bring to the experience at any given moment. Service systems enable people to have experiences and achieve goals.

She discussed the difficulties of designing a service system, such as the difficulty of prototyping and the difficulty of representing the experience, and pointed out that it requires combining aspects of business, technology and experience. She feels that it's helpful to create an integrated service design language: systems of elements with meanings (that designers use to communicate and users "read") plus sets of organizing principles.

Posted by Sandy Kemsley at 07:20 PM in NewSoftwareIndustry • SOA • SoftwareDesign | Permalink | TrackBacks (0) | Add to del.icio.us

There's an awful lot of keynotes in this conference: a couple of overall sessions this morning, now "track keynotes" for each of the four tracks within the BPM conference. I'm in Bruce Silver's New Directions in BPM Tools and Technology session, where he started by taking a gentle poke at Gartner, saying that BPM is more than a management discipline (Gartner's most recent definition of BPM).

He started out discussing process modelling, and how it's inherently a business activity, not an IT activity, which speaks directly to the issue of the tools used for modelling: is there a handoff from a modelling-only tool to an execution environment at the point of business to IT handoff, or is the model actually just a business view of the actual implementation? With all of the vendor demos that I've done lately (I know, I have yet to document many of there here, but I'm getting to it), I've had quite a focus on the distinction between having a model shared between business and IT, and having a separate BPA tool that models much more than just the processes that will be implemented in a BPMS. Bruce positions this as "BPA versus BPMN" views towards describing process modelling, and doesn't see them in conflict; in fact, he thinks that they're ignoring each other, a viewpoint that I'd have to agree with given that BPA initiatives rarely result in any processes being transferred to some sort of execution engine.

Bruce, who often accuses me of being too nice, takes a stab a the vendors in a couple of areas. First is with their BPMN implementations, specifically that of events: he states that many of the execution engines just don't support intermediate events, so that the vendors conveniently forget to include those events in their BPMN modelling tool. Second is with simulation, and looking at whether a vendor's implementation is actually a useful tool, or a "fake" feature that's there to enable it to be checked off on an RFP, but not functional enough to make it worth using.

He has a nice way of categorizing BPMS products: by vendor speciality (e.g., integration, human-centric), by process type/use case (e.g., production workflow) and by business/IT interaction method (collaborative shared model versus handoff). This was interesting, because I wrote almost identical words two days ago in my presentation for the Shared Insights Portals and Collaboration conference that I'll be speaking at next month; great minds must think alike. :)  His point, like the one that I was making in my presentation, is that most BPM products have some strengths and some weaknesses that can make or break some process automation; for example, a product focussed on human-centric workflow probably doesn't do some nice integration tricks like mapping and transformation, or complex data objects.

He also makes a good distinction between business rules (implemented in a BRE) and routing rules (implemented in a BPMS): business rules represent corporate or departmental policies that may need to be shared across business processes, whereas routing rules are the internal logic within a process that's just required to get through the process but don't represent policy in any way.

Bruce thinks that BPM and SOA together is still vapour-ware for the most part: it's what the vendors are selling but not typically what they're delivering. In particular, he thinks that if the BPMS and the ESB are not from the same vendor, then "all bets are off" in terms of whether a BPMS will work with any particular ESB or other services environment.

The session turned out to be too short and Bruce couldn't even finish his materials, much less take questions: it was only 45 minutes to begin with, and shortened at the beginning while Bruce waited for stragglers for the previous session to make their way upstairs.

Posted by Sandy Kemsley at 01:20 PM in BPM • BPM standards • BRE • BrainStorm2007 • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Consolidation in the industry keeps grinding on, with Software AG announcing that they will acquire webMethods for $546M. Last year, when I interviewed webMethods' EVP of Product Development, I wrote that their new BPM launch placed them squarely in competition with IBM and TIBCO. Not surprisingly, today's press release states:

The combined company will create a market leader in the software industry, specifically in the fast growing services oriented architecture, business process management and software application integration markets – just behind IBM and Tibco.

I guess we know who the competition is...

Posted by Sandy Kemsley at 11:24 AM in BPM • SOA | Permalink | TrackBacks (3) | Add to del.icio.us

Three months ago, I wrote about how the free BIJ (Business Integration Journal), formerly EAI Journal, was becoming Business Transformation and Innovation -- available only as a paid subscription. I believe that my comment at the time about paying for mostly vendor-written and vendor-sponsored material was "hahahahaha". And my comment on the new name was "it doesn't actually mean anything".

This week, I received an invitation for a free subscription to Align Journal (their tagline is "Aligning IT and Business Strategy"), and when I went to the site (and the online PDF version of the Jan-Feb issue), it looked familiar, so I dug into their About page:

Align Journal is the next step in the evolution of Business Integration Journal (BIJ). Over the past two years, the focus of BIJ was broadened to bring a business perspective to the use of technology for gaining such benefits as faster time to market, governance, increased agility to pursue new opportunities, improvements in managing business processes, and cost savings through the reuse of application components. Since the editorial focus of BIJ had evolved to no longer be strictly focused on integration topics, it was time to also evolve the magazine's name to Align Journal.

No mention of BTI, although if you go to the BTI URL that was advertised back in December when I wrote my post about it, it redirects to Align Journal.

If this first issue is any indication, it's definitely trending away from purely integration topics: the table of contents divides the articles into Business Strategy (3 articles), Leadership/Communication (3 articles), Technology (2 articles), Innovation (1 article), and Governance/Compliance (1 article). It's not clear to me, however, why "Maximizing IT for Effective Inventory Management" falls under Business Strategy, while "Leverage SOA to Increase Your Revenues" falls under Technology.

The paid subscription model is gone, unless you want the print copy and you're outside the U.S., and the digital copy is provided in a PDF that allows printing, but unfortunately not content extraction (so you won't see me quoting from it here -- I'm too lazy to retype what they've already published). And the name still doesn't actually mean anything.

Posted by Sandy Kemsley at 10:00 AM in BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

We started the last day at the Gartner summit with a keynote by Yvonne Genovese, Business Applications Through 2010: Major Changes Will Affect Your Process Environment. Early in her presentation, she made an important statement: "the technology keeps breaking our processes". Her focus is on business applications, not specifically BPM, but she's looking at trends of what's happening with enterprise applications like ERP and CRM systems. Her point is that these business applications have, in the past, forced businesses to use rigid business processes implemented within those systems.

However, the current trend is towards unbundling some of this functionality, exposing it through services, then consuming those services using a BPMS. This allows you to not only call specific functionality from your business applications at any point in a process that you now control, you can actually replace or augment the functionality of those applications by calling other services. This also provides an opportunity to more easily integrate between business applications if you have multiple ones in your environment. Although the business application vendors have been pushing suites for some time now, that packaging model will be less compelling to their customers as organizations start to slice and dice the atomic functionality of the business applications and compose their own processes using BPM rather than use the suite in its monolithic form.

Business applications aren't going away: there's still a huge amount of good functionality available in them, and as long as that commoditized functionality can be consumed as services, you're not going to be writing a replacement yourself. What I think will happen, however, is that the amount of the functionality used from any given business application platform will begin to erode as other internal or external services replace some of that functionality. This frees organizations from the vendor lock-in that they're subjected to now, and adds a new possibility for creating business applications: instead of just "buy" or "build", you can now also "compose". And if the megavendors in this field are going to stay competitive, they need to embrace and encourage an ecosystem that allows smaller vendors to provide services that can easily be integrated with their larger platform. This isn't going to be the old model of the vendor controlling the ecosystem by anointing their favourite technology partners, however: the customer organizations are going to build their own ecosystem from their preferred vendors in a truly best-of-breed fashion.

At the end of the day, BPM is an essential part of all this, since it will be used as a composition framework for combining functionality from business applications, along with internal and external services, into the processes that the business really needs.

Posted by Sandy Kemsley at 12:26 PM in BPM • GartnerBPM2007 • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

The second day started with a keynote by Daryl Plummer, BPM/SOA Elixir (unfortunately, I missed the breakfast session with Michele Cantara about the BPMS market, but I ended up in a fascinating discussion about requirements collaboration using wikis with Jason Klemow, and the concept of subscribing to processes with specific attributes in a BPM with Dennis Nickel of Telus).

Plummer obviously likes to play with the new technology, which I suppose is a prerequisite for his job: he talks about TiVo and Second Life as things that are fast becoming essential parts of culture, although it's clear that few people in the audience (except maybe me) embrace both the concept of downloading and consuming what I want when I want it, and the importance of online social networks.

He starts with some basic definitions of "service", especially the relationship between processes and services, to drive home the idea that SOA impact people too, not just systems. He also made an excellent distinction between a model-driven (process-centric) view and a typical programmer view of things: a model-driven view describes what a person does (the business process); a programmer view describes what the system does (the code that attempts to implement that process). After having a discussion earlier about defining processes based on the data values that flow through those processes, when I couldn't quite elucidate why that wasn't ultimately the right way to do things, this strikes me as an important distinction.

He summarized the results of Gartner's 2006 CIO survey ("CIOs are programmers that are passin' for normal folk"), where the top business trend is improving business processes: there's a lot of pressure all around to automate processes and improve them along the way, and this is going to happen only with both SOA and BPM. Plummer takes the enterprise architecture view of this, which I really appreciate -- business context and functions driving from the top of the architectural view, and services as a way to fulfill the needs of the business. Processes need services to be implemented quickly and effectively, and services aren't of use unless they are consumed by processes. SOA allows us to build an infrastructure of shared services for ready consumption by processes.

One of the key reasons for SOA and shared services is that legacy apps are still hanging around, in spite of all our efforts to get rid of them. Adding a service layer over the legacy apps allows us to create higher-level services and processes that consume these services without having to know how -- or even what platform -- to access the data directly on its original platform.

SOA, as Plummer reinforces, is an architectural style: not web services (although web services can be used to implement SOA), not a particular product, but encapsulated functionality accessed through a standardized interface that allows for loose coupling of services and applications. He goes through a checklist of how to know SOA when you see it, although some of the items on his list (such as a centrally managed runtime middleware network) are not, strictly speaking, an essential part of SOA.

He continues on with a discussion of event-driven processes (he refers to them as event-driven services in counterpoint to BPM-driven services, which is not necessarily a separation that I agree with). Services, properly implemented, can be combined into event-driven processes rather than structured, pre-defined processes, in order to be able to respond to events that happen in an unexpected order or manner. I did, however, like his view of the "new" application container: UI and navigation via a portal, security and management as part of the network, and logic and data accessed via services from wherever they might exist. Explicit orchestration ties all this together, which provides agility in the process model.

He points out that an SOA is never finished: in fact, it's designed to never be finished. He uses the analogy of the Sagrada Familia in Barcelona, a cathedral that's been under construction for more than 100 years now, and continues to change as it is built. He covers off some things about development techniques to be used when developing services within an SOA infrastructure, and highlights the business service repository as a centrepiece for BPM's use of SOA.

His final recommendation is that the critical path to competitive business advantage goes through SOA and BPM: you need to use SOA as the underlying mechanism, BPM as the methodology for tying things together in order to get the business process improvement that's required to differentiate your organization in the marketplace.

Posted by Sandy Kemsley at 12:30 PM in BPM • EnterpriseArchitecture • GartnerBPM2007 • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Metastorm and Lombardi both did something that I really dislike: instead of running two 30-minute sessions after lunch, as the schedule would indicate, they ran a 1-hour session that spanned the two 30-minute spots. Since I had planned to see one session of each, I ended up feeling a bit unfulfilled by both.

Anyway, I attended the second half of the Lombardi session, Process-Driven: We've Only Just Begun, and heard Tim Barnes of Devon Canada (an oil & gas company) speak about how they were trying to improve communication between data, applications, processes, people and companies. For them, this is all about integration, and in fact started with an EAI team. They've brought in Lombardi TeamWorks, but are still figuring out how to tie that back to their ESB and their previous integration efforts. They've defined their best practices, but are still at the point of developing shared services.

They've done three smallish BPM projects so far, and he spoke about the HR onboarding process that they automated, with some degree of difficulty. One of the big problems was that the people on the project knew how to implement applications, but didn't really get process, which required a complete team refresh -- Janelle Hill spoke about exactly this issue this morning of having people on the team who are process-savvy.

Their next steps are to develop their BPM architecture and develop a formal life cycle around BPM initiatives, as well as enhance their existing BPM centre of excellence.

He was followed by Steve Schade of the Church of Jesus Christ of Latter-Day Saints (a.k.a. Mormons) discussing how they've applied BPM technology to their extensive geneaology project. They have a ton of family history records on microfiche, but if they were to image all of it (as they have done with some of it), there would be 19 PB (that's 19,000 TB) of data, so they're looking for alternatives in the process of putting this data online and searchable on their FamilySearch.org website. They had been doing some ad hoc scanning and indexing of records, but needed a scalable process where they could pinpoint inefficiences and get some control and visibility over the process.

In their first BPM implementation, they took a process that formerly took weeks to execute, and reduced the time to hours, while moving control of the project setup from IT to the business area. Through an obviously good selection of an initial project, plus good training and rollout plans, they had a big success on their hands. On their second project, they took on something that's more complex, and which Schade thought might be a bit more than they could handle, but they're still working away at it. They used Lombardi's professional services and outside consultants on the first project to get them moving, and consider this essential to their success. They also see having business operations invovled in process modelling as key.

Posted by Sandy Kemsley at 06:17 PM in BPM • ESB • GartnerBPM2007 • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

I decided on Benoit Lheureux' session on BPM's role in multi-enterprise commerce, although we're had some technical difficulties and started late. This is much more about B2B and middleware than BPM, so it should be interesting to hear the perspective from the B2B viewpoint. If this turns out to be a dog, I'll be out of here for Process Modelling for Profit, but the slides look interesting and I'm very interested in inter-organization collaboration and process choreography. He just used the word "mashup", so I think that I'm staying, although the slightly smarmy "my friends" method of address did put me off a bit.

By now, the Gartner presentation framework is clear: each has exactly 20 slides; each has a Key Issues (agenda) slide with exactly 3 points (although Lheureux cheated by inserting a few extra slides that weren't in the downloaded version of the presentation). People with 120-slide presentations, take note of how the professionals do it.

Lheureux describes his research as looking at multi-enterprise integration, or how to bind your business processes with the business processes of your trading partners. He opens with the question of how tightly you should be binding your applications and business processes with those of your business partners.

He makes the bold statement "EDI software is dead", having been replaced by B2B gateway software that is more process-aware, and sees B2B projects as proliferating -- doubling in the next five years -- since there is a widespread recognition that organizations realize that their business processes are not just internal any more, and B2B needs to be a strategy rather than a discrete project. It used to be that you had your applications running internally, with some degree (if you're lucky) of internal visibility, but no external integration or visibility: you'd need some sort of manual process for providing both integration and visibility to external business partners. Now, however, you can't be competitive working that way any more. Furthermore, some of the functions done within organizations are being outsourced, further driving B2B requirements.

Gartner predicts that by 2011, 25% of new business software will be delivered as SaaS. Not 25% of what you're running in total, but 25% of the new stuff; still, that's huge. And I drink that particular Kool-Aid: I believe that this shift is happening now, and will continue to grow. SaaS is one form of B2B, in that you're integrating in some way with the SaaS provider, but this also provides the potential to integrate with other trading partners via the SaaS platform itself. In addition to the SaaS model of multi-enterprise integration, there's also the more traditional EDI-style e-commerce, plus integration via portals or mashups.

Lheureux discusses three approaches for implementing these B2B projects: run your own B2B gateway, outsource the B2B infrastructure (previously "EDI VAN"), or outsource the entire B2B project (previously "managed EDI"). He then dug into the issues of the choreography and monitoring of multi-enterprise BPM.

Gartner also predicts that by 2011, at least 40% of all new multi-enterprise integration projects will use BPMS. I can agree with this one too; besides, I figure if it doesn't look like it's going to come true, Gartner will just change the definition of BPM again. :)

He then discussed the four multi-enterprise BPM styles:

1. Blind document/transaction exchange, e.g., exchange purchase orders, to lower transaction cost, latency and errors by increasing automation. No shared process visibility or execution, and the process is difficult to change.
2. Intelligent document/transaction exchange, e.g., shared view of order-to-cash process, to provide some process visibility.
3. Multi-enterprise applications, e.g., shared execution of vendor-managed inventory, to centralize process control. This maximizes process visibility since both trading partners are participating in the same process (not just exposing a limited view of an internal process from one to another), but this is a big thing to do and requires a great deal of trust between the trading partners.
4. Multi-enterprise BPMS and rules, e.g., shared compliance management, in order to centralize the process and rules definition. This increases flexibility considerably, but again requires a great deal of trust and collaboration between the trading partners in order to make this work.

Organizations are going to have to implement more than one of these styles of multi-enterprise integration over the next few years as this field evolves. And if you're already using B2B, B2B-enabled middleware or BPM, portals, SaaS or a variety of other technologies, then you already have some of the infrastructure in place to get started at this. The support for B2B versions of many of the standard BPM functionalities is just not there yet, however: practically no one is doing B2B process simulation, for example.

He ended up with some recommendations for multi-enterprise BPM strategy, such as synchronizing multi-enterprise and internal BPM projects, and developing a shared B2B infrastructure, with a focus on enabling shared process visibility (via BAM) and shared process control (via business rules).

Posted by Sandy Kemsley at 01:59 PM in BPM • GartnerBPM2007 • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Vendor announcements are dropping from the trees around here this week, but I found this one particularly interesting after my trip to the IDS Scheer user conference a few weeks ago: Microsoft has selected IDS Scheer as a preferred business process modelling/monitoring partner in the newly-formed Business Process Alliance. Now, before you get too excited, the press release says "a" preferred partner, not "the one and only", implying that other business process modelling and monitoring companies might also be invited to the dance; right now, the Alliance lists AmberPoint, Ascentn, Fair Isaac, Global 360, InRule, Metastorm, PNMsoft, RuleBurst and K2.net as members, so no other modelling but lots of competing business rules and BPM vendors. (By the way, Microsoft's incorrect use of "is comprised of" on their page -- sloppy editing.)

There's a real-world example of the ARIS UML Designer (now part of ARIS SOA Architect) being used to model business processes for execution in BizTalk at Siemens IT Operations over the past 2 years, so this is built on a pretty strong success story. This provides BizTalk with a fully functional process designer, which was not a strong suit of theirs in the past.

It's not clear to me whether this is anything beyond a co-marketing campaign; presumably, the existing BPEL export from ARIS would serve for import into BizTalk, or IDS Scheer may choose to do a closer "standards-based" (but not standard) integration such as they have done with SAP and Oracle.

I have to say, however, that I had strong negative feelings about the term Alliance since I first watched the TV series Firefly: they're the authoritarian bad guys, right? Or maybe they only look bad from the little guy's viewpoint. :)

Posted by Sandy Kemsley at 10:16 AM in BPA • GartnerBPM2007 • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Dr. Jost started the day with a presentation on "The Basis for Linking BPM & SOA". Someone may have been reading one of my posts from yesterday, because when he put up the obligatory slide of VW, he referred to them as "Volkswagen -- of course, you know who they are". :)

His talk was part ARIS product marketing and part generic material on BPM and SOA.

There was a lot on the separation of modelling and execution environments, or what he characterized as "business BPM" (business process strategy, design, implementation and controlling) and "technical BPM" (define, create, execute, monitor) -- really, it's like layers in a Zachman or other enterprise architecture diagram, although he didn't really make that distinction. ARIS is used in the upper layer of functions/definitions, with links to the technical BPM functions in the lower layer.

He did have some nice slides and explanations of BPM and SOA: BPM as a management discipline involved in strategy, design, implementation and measurement of business processes, with the purpose of continuously improve the productivity and degree of innovation of business processes; SOA as an architectural style of business applications based on distributable, sharable and loosely coupled modules, with the purpose to improve the flexibility of business applications needed to support changes in business processes with less time and effort. He showed a 3-layer model of strategy (business model), BPM (business processes) and SOA (business applications), where there might be changes at any of these levels that would ripple through the others: strategy could change due to market forces; business processes could change due to organizational changes, and applications could change due to technology innovations.

Another point that he made, and one that I used in my response to Phil Gilbert's comment on one of my posts yesterday, there's value in using modelling tools that are separate from the BPMS themselves, especially if you're creating the business models in advance of technology acquisition, or if you have a variety of process execution environments and want a single modelling environment for your business analysts. Of course, when Jost talks about business models being technology-independent, he's excluding their own technology from that definition.

On the product side, Jost discussed the six solutions that they offer, which appear to be combining/packaging of existing products to address specific markets: Enterprise BPM, Enterprise Architecture, Process-Driven SAP, Business-Driven SOA, Process Intelligence & Performance, and Governance, Risk & Compliance. He also spoke about the new ARIS SOA Architect product, used to translate their "business BPM" into "technical BPM".

The review of their multi-vendor platform strategy showed up some of the weaknesses that Phil Gilbert had mentioned in his comments yesterday: although they use BPEL and UML to interface bi-directionally with Oracle, and BPEL for bi-directionality with TIBCO, they use a much more tightly integrated -- and proprietary -- interface to SAP. Other BPMS products, including IBM WebSphere, Microsoft BizTalk, BEA and Fujitsu only have uni-directional exports, which is pretty useless in practical usage.

Jost finished up his talk with a quick review of the ARIS 2007 product roadmap.

Posted by Sandy Kemsley at 03:56 PM in ARISProcessWorld2007 • BPA • BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

For the first breakout session today, I heard Bill Swanton, who's VP Research at AMR Research. Although the topic was "BPM is the value in SOA", Swanton talked a lot about SOA-ing your ERP. AMR has obviously done a lot of research in this area, and he had some good thoughts on the ERP long-term lifecycle. ERP systems are often monolithic, and therefore not so easily pushed aside or interfaced with services. What ends up happening is "SOA by evolution", where an ERP system (he mentioned SAP ERP and Oracle Fusion in particular) is wrapped to create specific service interfaces, although the  internal processes remain fixed.

He did discuss the use of technology is a catalyst for changes in business, and stated from their research that 66% of organizations implementing SOA are hoping to improve their business processes. I'm not sure that I agreed with his characterization of BPM and BAM as "key components of SOA", but I loved the analogy of SOA as the corporate "patch panel".

He had an interesting chart about how SOA needs vary with the complexity/enterprise spread of existing systems, and degree of customization. If different software is used in different business units and there's a lot of customization, then the goal of SOA is usually to reduce development costs and reuse existing custom software; there will be a tendency to layer custom layers on top of the existing custom development. At the opposite corner of the chart, where an organization has an enterprise-wide ERP with little customization, they're looking to compose unique business processes out of the ERP vendor's provided services that can be a competitive differentiator for them.

Swanton sees a number of short-term challenges -- and therefore slower ROI -- as organizations transition from traditional applications through hybrid solutions to a true SOA, one of these being the showdown between ERP and SOA vendors for same space. He notes that the ERP vendors are not, in general, making radical changes, which seemed to imply that the SOA vendors might pull ahead on this front.

Posted by Sandy Kemsley at 03:50 PM in ARISProcessWorld2007 • BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Great webinar on BPM Basics today, BPM & SOA, where John Lojek gave an "18-Minute BPM and SOA Primer". Definitely a good introduction to the subject, particularly around the differences between BPM and SOA, and how they fit together.

Phil Larson of Appian followed with some practical advice on using SOA and BPM together, such as enforcing SLAs and securing services, with very little blatant plugging of his product -- not bad for a marketing guy! :)

Posted by Sandy Kemsley at 02:47 PM in BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Issue 10 of the Microsoft Architecture Journal is out (direct link to PDF), with a good article on composite applications. Very MS-centric, obviously, but some good explanatory intro stuff on what and how.

Posted by Sandy Kemsley at 02:53 PM in SOA | Permalink | TrackBacks (0) | Add to del.icio.us

If you missed the SOA in Action online conference last week, you can view replays of the presentations on the site.

There's a presentation with Ken Vollmer from Forrester entitled "What is the relationship between BPM and SOA and why should you care?" that starts with the ever-present history of BPM, a topic that I've covered in some detail as well. At the BPM Think Tank in May, I wrote about his colleague at Forrester, Connie Moore, and how she showed a simplistic view of how BPM evolved from workflow, and talked about Vollmer's equally simplistic view that BPM evolved from EAI. Now, at least, he seems to be singing the more comprehensive tune of how it evolved from both workflow and EAI (maybe they were reading my blog? :) ). With the recent convergence of integration-focussed and human-centric BPM tools through corporate acquisitions, it's hard to ignore this bigger picture.

He covers both business and IT drivers for BPM, including how many integration-focussed BPMS have SOA at their core. I have a bit of a problem with his slide #12 that shows a big "SOA" label around workflow, process modelling, BAM, business rules and a number of other things that clearly are not part of SOA, although they are certain to have services somewhere in their underpinnings -- call it integration-focussed BPM, but not SOA. Aside from that, he gives a good overview of both BPM and SOA, and spends a bit of time talking about how SOA can help to facilitate development outsourcing. Of course, I also think that BPM can help to facilitate process outsourcing by removing location dependence at any particular step in a process, but he doesn't mention that.

He then gets down to the meat of it -- BPM and SOA together -- and his key argument is that SOA provides a standards-based approach for implementing BPM. That true, but he totally misses what BPM does for SOA: SOA needs BPM to orchestrate the services into business processes that can include human-facing steps, and also to provide the more robust modelling, simulation and monitoring tools that are available in BPM suites. BPM is SOA's "killer app", the thing that will drive acceptance of SOA in the business areas and open up the business purse-strings needed to support this in the long term.

When it comes down to it, Vollmer is an SOA guy, and this was an SOA conference presentation. However, I think that if you're going to talk about BPM and SOA, you shouldn't just do it from an SOA perspective.

Posted by Sandy Kemsley at 06:03 PM in BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

I had a chat this morning with Kristin Muhlner, webMethods' EVP of Product Development, and I have to say that it's refreshing to have a discussion with another technical woman for a change, since there's really not enough of us in this industry. :)

The reason for our call was to discuss webMethods' announcement today about their upcoming release of webMethods Fabric 7.0, which will include new BPM functionality that they are using to launch into the BPM suite market -- a move that will place them squarely in competition with TIBCO and IBM (this latter depending on whether someone at IBM wakes up and realizes that the BPM product that they just acquired with FileNet would perfectly round out their WebSphere suite, but that's a topic for another day).

This change in strategic direction for webMethods has been 18 months in the making, and they've released a new Eclipse-based process modelling environment that takes on a different personality depending on whether the user is a business analyst or a developer. Following the direction of other BPM vendors, this can be run as a standalone desktop tool without connection to a server, and although they're not making it a free download like Savvion has done, I have the sense that that's being discussed. One key flaw that I could see is that although they're modelling in BPMN, they're serializing only to BPEL for transfer to an execution environment, not to XPDL; unfortunately, not everything that you can model in BPMN can be saved to BPEL, so I'm not sure what their solution is for this. Obviously, they must be using some other format for transferring to their own execution environment. I've asked for a demo of the product over the next few days, so I hope to be able to resolve this question then.

We had the inevitable discussion about browser-based modelling tools -- I think that offering a modelling tool for business analysts in a browser lowers the bar significantly for adoption across an enterprise, something that modelling vendors like Proforma have already figured out -- but webMethods isn't offering that in the current product release.

The goal of this process modeller, as with many of the other BPM vendors' modellers, is to become so ubiquitous in an organization that the business analysts no longer use Visio to model processes, but use this tool instead. That's quite a different approach from vendors like Fujitsu, who extend Visio using something like Zynium's Byzio, as I've discussed previously. In both cases, however, vendors are looking to eliminate the translation errors that occur now when Visio diagrams are manually re-created in a BPM vendor's modelling tool, by allowing a direct import of the process definition from the modelling environment, whether that's Visio or a proprietary modeller. The advantage of what webMethods provides is all the things that you don't have in an enhanced Visio environment, such as rich documentation capabilities, the ability to design KPIs directly into the process for later linking with BAM, and an environment that allows business analysts and developers to collaborate more easily. I think that they're going to have to make this a free downloadable product in order to really see market penetration, however. They also provide a codeless development environment that allows a developer to just drag and drop services and pre-built AJAX components in order to build a custom application. And, speaking of BAM, they've included BAM, simulation and business rules integration in the BPM suite, too.

An advantage that webMethods will have is that the BPM suite is built directly on top of their existing integration platform, which gives them a way to mine their existing customer base of integration/SOA implementations to expand to include BPM.

Posted by Sandy Kemsley at 02:18 PM in BPM • SOA | Permalink | Comments (4) | TrackBacks (1) | Add to del.icio.us

I wrote back in July about CentraSite, a standards-based SOA forum and a freely-available product for SOA registry, repository and other functions. This week, I received notice that CentraSite is now launched (I guess that I was playing with beta code before), and that there will be a number of blogs hosted on the site to talk more about SOA. It will be interesting to see how this plays out; it has Fujitsu and Software AG behind it, and there's obviously been a lot of work put into the product, but I don't have enough experience with this class of product to tell if it's a potential winner or not.

Posted by Sandy Kemsley at 04:06 PM in SOA | Permalink | TrackBacks (0) | Add to del.icio.us

Reportedly from IBM, although the credits don't state there, there are three short (just over a minute each) videos on SOA here, here and here on YouTube. Pretty simplistic, but a nice animated way to introduce the subject.

Posted by Sandy Kemsley at 03:56 PM in SOA | Permalink | TrackBacks (0) | Add to del.icio.us

The Virtual WebSphere BPM User Group is hosting a 2-day Virtual Jam on the BPM with SOA forum. I heard about this from Bruce, who points to the registration page; note that you have to join the Global WebSphere Users Group Community, then join the Virtual WebSphere BPM User Group (there's a not-so-obvious link to join on the aforementioned registration page). If you survive all of that, hop on over to the forum site and see what's being posted; the jam runs through the end of day tomorrow.

Someone from IBM has appeared to have seeded a bunch of discussion topics, but there's not a lot of participation yet. I'm not sure that a forum is a good place to hold a 2-day jam, since the cycle time of people checking and responding to forum posts can be a bit long for that. That being said, there are a few good topics running.

Posted by Sandy Kemsley at 05:44 PM in BPM • SOA | Permalink | TrackBacks (0) | Add to del.icio.us

My reading is a bit behind due to my recent travel, and with my feed reader sitting at just under 3000 unread items, I tend to ignore the magazine feeds in favour of reading blogs. Today, I went back through the unread Intelligent Enterprise items and found The Bifurcation of Business Process Management, which has very little to do with bifurcation except for one sentence in the summary; probably the editor just likes the word. ;-)

I don't agree with everything in this short report from Ventana Research: they state that BPM is still in its infancy, but suggest creating a 3-year architectural blueprint for BPM; if the technology truly is immature, then a 3-year plan would change so quickly as to be obsolesced within a year, wouldn't it? Also, the phrase in the recommendations, "BPM technology, by failing to maintain pace with Web services technologies, is not ready for prime-time enterprise SOA applications" is a generalization that I just don't believe to be true.

I'm left with the impression that the author is not all that knowledgable about BPM, which doesn't leave a particularly good impression about Ventana.

Posted by Sandy Kemsley at 04:58 PM in BPM • SOA | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us

Catching up on some podcasts today while walking around Toronto, and listened to the June 30th RedMonk Radio that included a section on SOA and mashups. Favourite quotes: "Describing SOA as mashups is insulting to mashups" (Steve O'Grady), plus Coté's analogy "SOA is like religion, and mashups are like science".

As always, worth listening.

Posted by Sandy Kemsley at 02:53 PM in SOA | Permalink | Comments (2) | TrackBacks (0) | Add to del.icio.us