Category: process

business process management

BPM and Model-Driven Development, SaaS and the economy

It’s been a slow week for blogging due to a lot of billable client work, which takes precedence, and I’ve also missed several webinars that I wanted to attend. However, an article that I wrote for Intelligent Enterprise was picked up on TechWeb and published on the Yahoo! News Tech page (thanks to Bruce Williams of Software AG for tipping me off), which has resulted in quite a bit of traffic this week. I wrote the article at the end of the Gartner BPM summit last month, sifting through the wide variety of information that I saw there and distilling out some common themes: model-driven architecture/development, BPM and software-as-a-service, and the impact of the slowing economy on BPM.

The part on BPM and model-driven development was written prior to the Great BPMN Debate, but there’s an obvious tie-in, since BPMN is the modeling language that’s typically used for MDD in BPM. One of the webinars that I missed, but have just played back, is one from PegaSystems and OMG on Five Principles for Success with Model Driven Development (playback available, registration required), which touches on a number of the ideas of using (usually graphical) models to express artifacts across the entire software development lifecycle. Richard Soley of OMG and Setrag Khoshafian of Pega went through these principles in detail:

  • Directly capture objectives through executable models and avoid complex mappings between tools
  • Make a BPM suite the core layer of your MDD: model-driven development is achieved through BPM
  • Build and manage an enterprise repository of your modeling assets using a complete BPM suite
  • Leverage the platform and architecture pattern independence
  • Adopt a BPM suite methodology, center of excellence, best practices and continuous improvement lifecycle

The principles presented by Khoshafian were rather suspiciously aligned with Pega’s way of doing things — I have the feeling that Soley would have produced a somewhat different list of principles on his own — but the entire webinar is still worth watching, especially if you’re trying to haul your organization out of a waterfall development model or trying to understand how BPM and MDD interrelate.

To my new visitors arriving here because of the TechWeb syndication of the article: browse the archives by month or category (including the conference subcategories), or use the search feature to find topics of interest. I have several mostly-finished blog posts waiting for some final touches, so stay tuned for more content.

BPMN and the Business Process Expert

There’s something funny about chatting via IM with someone as you’re listening to them give a public webinar, even when you do know that the presentation is pre-recorded — I was on Skype with Bruce Silver today during his webinar The Business Process Expert and the Future of BPM on ebizQ, where he was speaking with Marco ten Vaanholt of SAP’s BPX community.

Except for one “happy smiling faces” graphic worthy only of Jim Sinur’s blog pimping marketing team, I really enjoyed Bruce’s presentation, although I’ve heard at least parts of it before. He started with a comprehensive description of BPM and why model-driven design is so critical to process agility, which he segued into a description of BPMN and its importance in making process models executable: the heart of model-driven design. He feels that it’s necessary to define the role of Business Process Expert (BPX): someone that bridges between business and IT, creating executable requirements for BPM solutions. Obviously, BPMN is a critical skill for the BPX, and Bruce offers a number of resources including a free series of articles and e-learning modules that he’s done on the SAP BPX community and the longer paid courses that he offers online and public classes through BPM Institute. No wonder he hasn’t blogged for months: he’s been too busy creating all this.

Marco ten Vaanholt talked about the importance of BPM and SOA — fairly motherhood sort of stuff — then dug into some details of the SAP BPX community, which is an incredibly well-developed resource for anyone involved in BPM, whether you’re an SAP customer or not. The core of the BPX community is collaboration and collective learning on business scenarios, process lifecycles, change leadership, social responsibility, horizontal and vertical practices, modeling tools, methodologies and a variety of other topics. It’s not just a discussion forum, however: there’s a lot of really valuable content, such as Bruce’s articles and e-learning, from both SAP and the community in general.

Marilyn Pratt, the BPX community evangelist, has been keeping me up to date on what’s happening on BPX and the worldwide community events in which she’s been involved, and I’m looking forward to catching up with her and seeing more of BPX in action when I attend SAPPHIRE in May.

There was some good Q&A at the end about process modeling and the BPX community. Definitely worth watching the replay, which should be available online at the original webinar link above.

State of the BPM Market white paper

I’ve been working on a white paper with BEA for the last couple of months, and it’s finally been released for free download.

We dipped into research from the big analyst firms as well as the extensive survey data collected by BEA directly. The result: a comprehensive 36-page white paper covering how and why BPM has taken a position of importance within organizations, the market size and segmentation, and market trends such as SOA and Enterprise 2.0.

A chance encounter with jBPM

In one of those weird coincidences, JBoss World is happening simultaneously in the same conference center as ProcessWorld; Tom Baeyens noticed that I was blogging from ProcessWorld and contacted me, and we had a chance to meet up today.

We had a great discussion about model-driven applications, and finding the dividing line between what works and doesn’t work in a model-driven paradigm. Tom’s premise is that model-driven development can work in simple cases, but that it’s not possible to generalize: at some point, enough technical underpinnings need to be added to the model that it’s no longer understandable by a non-technical business analyst. Although the business analyst can still create a model and pass it for translation to a developer for augmentation, it’s going to be a one-way trip in most cases.

I definitely see some validity to this position; what typically ends up happening in today’s model-driven development in BPM is that either the developers just take over maintenance of the models at some point (even if the tool allows the models to be shared), or the business analysts learn enough of the technical side to be able to understand the fully-executable model which is, unfortunately, no longer really a business model.

jBPM is not at all about model-driven development, but provides a BPM engine that can be embedded directly in your Java code. Tom shared some of his vision of the future for the project with respect to expanding modeling capabilities and other areas; suffice it to say that total BPM world domination is on the plan.

ProcessWorld 2008: Michael Blechar, Gartner

You would think that I had enough of Gartner last week in Las Vegas, but here I am at yet another Gartner presentation.

Although Gartner is a big proponent of buying everything in a BPM suite (including modeling) from one vendor, Michael Blechar is here to play nice and talk about best-of-breed modeling and analysis using tools such as ARIS — even going so far as to refer to it as the “Cadillac of BPA”. They completely underestimated the interest in this track, and the room is standing room only.

He looked at the three major types of BPA tool buyers: business process modelers, (enterprise)architects, and BPMS modelers (who are concerned with the actual implementation within a BPMS execution environment, hence focused on design and construction). BPMS modelers typically start with the modeling tool provided by the BPMS, then may add in a more comprehensive modeling environment after implementing one or two processes and finding that the modeling tool is inadequate, whereas business process modelers are typically creating models independent of any particular execution implementation. In many cases, business process modelers are starting with Microsoft Visio because it’s the most readily available tool, but find that they need something much more robust for modeling, providing functionality such as activity-based costing and simulation.

He reviewed the players in the recently-published BPA magic quadrant, where IDS Scheer sits as the clear top-right leader. This market is undergoing a lot of consolidation, mostly as BPA vendors are being acquired by BPMS vendors; surprisingly, the magic quadrant only has leaders and niche players (bottom left), but nothing in the challengers or visionaries quadrants. Personally, I wouldn’t have put Microsoft (with Visio) in the leaders quadrant; although they are clearly a dominant force in the market, their product is pretty low-end compared to the real contenders: IDS Scheer, Proforma, Mega, iGrapfx, Telelogic and Casewise.

Blechar is talking about how in the future, Microsoft and others will allow you to create models that actually execute without writing code, but isn’t this what almost all BPMS products do now? There’s some confusing stuff going on in this presentation from a BPMS viewpoint, such as talk about the convergence of BPMN and UML, and an over-emphasis on BPEL as a cornerstone.

He finished up with some recommendations:

  • When BPM initiatives reach the point of requiring business architecture definition — or there is a need to visualize, simulate, animate or automate business process as models — BPA tools should be implemented.
  • As business look to implement business processes in a service-oriented architecture, there is an increased urgency to collaborate more closely with IT archtiects and analysts including shared models.
  • Be pragmatic in scoping modeling efforts: do not try to “boil the ocean” in terms of modeling the “as-is” and “to-be” business architecture and processes.
  • Ensure the key business roles of business process owner, architect and analyst are staffed and enabled.
  • Monitor standards efforts and be prepared to use increased model automation tools and techniques.
  • Match BP methods and tools to the primary focus group of usrs – be they BP modelers, architects or BPMS modelers.
  • Monitor opportunities to purchase pre-built models to jump-start your BPI projects.

ProcessWorld 2008: Prof. Dr. August-Wilhelm Scheer Keynote

I had completely forgotten last year’s jazz performance until Dr. Scheer arrived on stage for his keynote toting a saxophone, and had a quick session with bass, keyboard and drums before starting the keynote.

His presentation focus was on a framework for business performance management: a holistic management concept for improving performance and profitability of a company via two BP(e)M [Business Performance Management] wheels. He started with a content wheel that included several of the dimensions along which to consider business performance management initiatives, through three phases of market maturity (roughly, pre-2000, 2000-current, and future). For example, “objects”, or the artifacts captured to drive the frameworks, has shifted from data to processes, and is starting to move to events and rules.

He moved on to a technology wheel model, covering various aspects of application architecture, as they moved from standalone process models to tight integration with ERP packages — which effectively acts as the business process execution layer — to the emerging generation of model-driven business software.

He overlaid these wheels with areas covered by classical BI and BPM to show the gaps between ARIS and other classes of products, and showed how it could be used for evaluating process improvement efforts to date within an organization.

Gartner BPM: The BPM Scenario: A Change from Business as Usual, Janelle Hill

Janelle Hill addressed the issues of what’s really new in BPM and how it can change how you do business. She starts off by discussing how BPM is different from older business process reengineering techniques:

  • Process orientation complements functional organization, along the lines of what Rummler was discussing yesterday: processes overlay functional silos, which drives matrix management so that processes can be managed end to end.
  • Processes must be effective and transparent, not just efficient.
  • Processes must be adjustable (sometimes by process participants), not perfect, in order to adjust to changing customer requirements.
  • Small incremental improvements must be harmonized with larger transformative change.

Gartner defines an explicit process as one that it visible and independent from its implementation; namely, the process has been modeled separate from context manual or automated context. This type of modeling and the management of the explicit processes is essential for effectiveness and innovation; it allows for the establishment of process KPIs and allows you to model potential changes to the process. These process models provide a view of work in progress; as these models are implemented in BPMS, they become the visual metaphor for the work for monitoring and management purposes. They also provide a method of communicating about the process, both between business team members as well as between business and IT.

This also leads to new management techniques. Management becomes more real-time as the process monitoring tools allow for view of what’s happening right now in the business process, instead of managing through the rear-view mirror via historical reports. Typically, a process-centric view encourages collaboration among team members, and also encourages participation by the process workers. Both business and IT workers have different roles: the business user may be assembling their own solutions, while the IT person is designing and building components to be assembled.

She looks at a number of key factors for determining when a BPMS might be used:

  • Strong focus on coordinating multiple resources to create successful work outcomes, including people, systems, information and policies.
  • The process crosses a large number of boundaries.
  • The process is poorly understood.
  • The process is customer-facing or partner-facing.
  • The process is more susceptible to external or internal disruption.
  • Business will be responsible for change management, not IT.

If these factors aren’t present, then a more traditional coding approach might be used.

Hill went through some of the process design patterns — I saw this at the previous summit and really liked it, since I use something quite similar with customers — in order to map process characteristics onto different styles of processes, and therefore onto a subset of the BPMS products that might best suit those needs. The three most common patterns that they see with BPMS are case management, form-driven workflow, and participant-driven workflow.

She finished up with the BPMS magic quadrant, and explained that there are so many vendors in the leaders quadrant because they’ve changed the definition of what’s included in BPMS; I see that as a reason why there’s more vendors in the magic quadrant overall, but not why it’s so heavily weighted to the upper-right quadrant. She believes that consolidation for the purposes of acquiring technology functionality has already mostly occurred. She also sees that the larger platform vendors such as Microsoft are focused on software development as the primary method for BPMS rather than model-driven approaches that limit the amount of code.

She believes that this is not the time (yet) to pick the enterprise-standard composition platform, because no one tool handles all of the six process styles that she showed earlier. This is still not a mature market, in spite of the purchasing activity going on.

Gartner BPM: Weaving BPM into the Fiber of the Enterprise

Elise Olding moderated a panel on weaving BPM into the enterprise, with Eric Abecassis, Architecture and Integration Manager with Schlumberger, Jim Boots, Enterprise Architect at Chevron, and Kevin Morgan, Program Manager at Dolby.

Abecassis started with the process-related problems that they had at Schlumberger: processes had to be standardized in order to effectively manage growth and improve execution, reduce the administrative burden on the field people, and improve alignment between business and IT. Their approach was to focus on three main types of activities:

  • Doing the right things (business)
  • Understand the right things (business/IT)
  • Doing things right (IT)

It appears that their BPM projects are primarily driven by IT (although with heavy involvement by the business), in contrast to Chevron, where grassroots business actions drove the BPM efforts. In their case, a business unit had some amount of success, then a few individuals worked at selling the ideas across the company until it was accepted as a broader platform that can be used elsewhere. They’re still somewhat in stealth mode inside their own organization

At Chevron, they learned how to use the tool, then started to play around with how it could be used: looking for emergent applications of the technology. They showed off BPM to anyone who would listen, particularly trying to link it to existing initiatives, and continued to develop their BPM approach as it become popular in other areas. Overall, the grassroots efforts within the business delivered a proof of concept and a core set of advocates, but eventually key management endorsements and dedicated resources were required to make the transition to an enterprise-wide effort.

Dolby is a sort of 40-year-old startup that just went public two years ago, and is going through some major cultural changes to adapt to the changing world of entertainment technology. A management consulting firm provided them with recommendations for reorganization, then when they started to implement that internally, they discovered that this reorganization — a common issue — actually broke a lot of their business processes. He found an interesting effect: internal audit people have great insight into where problems might exist in business processes, and typically have the attention of management to a greater degree than a BPM team, so he worked closely with them.

It’s good to hear some success stories about how organizations are starting to become more process-centric: these stories aren’t just about how a specific implementation worked, but how the organization started to embrace the benefits that BPM could bring.

It’s a bit distracting that the panel members have obviously been told not to mention their BPM vendor by name; they dance around it by describing the tool, how they selected it and how they use it, but never say what it is.