Tag Archives: BBC2010

Integrating BPM and Enterprise Architecture

Michael zur Muehlen presented this morning on integrating BPM and enterprise architecture, based on work that he’s done with the US Department of Defense. Although they use the DoDAF architecture framework in particular, the concepts are applicable to other similar EA frameworks. Like the Zachman framework, DoDAF prescribes the perspectives that are required, but doesn’t specify the artifacts (models) required for each of those perspectives; this is particularly problematic in DoD EA initiatives where there are likely to be many contractors and subcontractors involved, all of whom may use different model types to represent the same EA perspective.

He talked briefly about what makes a good model: the information must be correct, relevant (and complete) and economical (with respect to level of detail), as well as clear, comparable (linked to reality) and systematic. From there, he moved on to their selection of BPMN as the dominant standard for process modeling, since it has better event handling than UML activity diagrams, better organizational modeling than IDEF0, and better cross-organizational modeling than simple flowcharts. However, many tools support only a subset of BPMN – particularly those intended for process execution rather than just process modeling – and some tools have non-standard enhancements to BPMN that inhibit interoperability. Another issue is that the BPMN specification is enormous, with over 100 elements, with some different constructs that mean the same thing, such as explicit versus implicit gateways.

They set out to design primitives for the use of BPMN: where they “outlawed” the use of certain symbols such as complex gateways, and developed best practices for BPMN usage. They also mapped the frequency of BPMN symbol usage from internal DoD models, those that Michael sees in his practice as a professor of BPM at Stevens Institute of Technology, as well as samples found on the web, and came up with a distribution of the BPMN elements by frequency of usage. This research led to the creation of the subsets that are now part of the BPMN standard, as well as usage guidelines for BPMN in terms of both primitives and patterns.

In addition to the BPMN subsets (e.g., the most commonly implemented Descriptive subclass), they developed naming conventions to use within models, driven by the vocabulary related to their domain content. This idea of separating the control of model structure from the vocabulary makes sense: the first is more targeted at an implementer, while the second is targeted at a domain/business expert; this in turn led to vocabulary-driven development, where the relationship between capabilities, activities, resources and performers (CARP analysis) is established as a starting point for the labels used in process models, data models (or ontologies/taxonomies), security models and more as the enterprise architecture artifacts are built out.

Having defined how to draw the right models and how to select the right words to put in the models, they looked at different levels of models to be used for different purposes: models focused on milestones, handoffs, decisions and procedures. These are not just more detailed versions of the same, but rather different views on the process. The milestones view is a high-level view of the major process phases; handoffs looks at transitions between lanes with all activities with a lane rolled up to single activity, primarily showing the happy path; decisions look at major decision points and exception/escalation paths; and procedures showing a full requirements-level view of the process, i.e., the greatest level of detail that a business analyst is likely to create before involving technical resources to add things such as service calls.

To finish up, he tied this back to the six measures of model quality and how this approach based on primitives conforms to these measures. They’ve achieved a number of benefits, including minimizing modeling errors, ensuring that models are clear and consistent, and ensuring that the models can be converted to an executable form. I’m seeing an increased interest with my clients and in the marketplace on how BPM and EA can work together, so this was a great example of how one large organization manages to do it.

Michael posted earlier this year on the DoDAF subset of BPMN (in response to a review that I wrote of a BPMN update presentation by Robert Shapiro). If we go back a couple of years before that, there was quite a dust-up in the BPMN community when Michael first published the usage distribution statistics – definitely worth following the links to see where all this came from.

The Rules For Process

I’ve been pretty busy here at the Building Business Capability conference the past two days with little time for blogging, and with two presentations to do today, I don’t have much time, but wanted to attend Roger Burlton’s “The Rules For Process” keynote, which he refers to as his business process manifesto. After some terms and meta-rules (e.g., short, jargon-free and methodology-neutral), he got into his eight main principles:

  1. A business process is a unique capability of an organization.
  2. A business process exists within a clearly defined business context.
  3. The name of a business process must be consistently structured, unambiguous and commonly used.
  4. A model of a business process holds knowledge about a business process.
  5. A model of a business process associates a business process with other capabilities of the organization.
  6. A business process is guided by the business’ strategy and its policies.
  7. The performance of a business process is measured and assessed in business terms.
  8. A business process is an essential asset of the organization.

He spent quite a bit of time delving into each of these principles in detail, such as describing a business process as an action, not a policy, business rule or technology application.

I’m not sure if Roger is considering publishing a paper on this; definitely lots of good information about what business processes are and are not, which could help many people with their business process capture efforts. There’s apparently a discussion about this on the BPTrends LinkedIn group where you can find out more and join in the conversation, although I haven’t found it yet.

Building Business Capability Conference: Rules and Process and Analysis, Oh My!

After a welcome by Gladys Lam, the conference kicked off with a keynote by Ron Ross, Kathleen Barret and Roger Burlton, chairs of the three parts of the conference: Business Rules Forum, Business Analysis Forum and Business Process Forum. This is the first time that these three conferences have come together, although last year BPF emerged as more than just a special interest track at BRF, and it makes a lot of sense to see them together when you consider the title of the conference: Business Business Capability.

The keynote was done as a bit of a panel, with each of the three providing a view on the challenges facing organizations today, the capabilities required to tackle these challenges, and how this conference can help you to take these on. Some themes:

  • Lack of agility is a major challenge facing organizations today. To become more agile, design for change, including techniques like externalizing rules from processes and applications for late binding.
  • Consider effectiveness before efficiency, i.e., make sure that you’re doing the right thing before seeking to optimize it. In the vein of “doing the right thing”, we need to change corporate culture to focus on customer service.
  • Structured business vocabularies are important for effectiveness, including things like rules vocabularies and BPMN. Roger pointed out that we need to keep things simple within the usage of these vocabularies, and jokingly challenged us to create a valid process model containing all 100+ BPMN elements.
  • The business analyst’s role will transform in the next five years as process, rules and decision tools converge and business architecture gains more significant. BAs need to step up to the challenge of using these tools and related methodologies, not just write requirements, and need to be able to assess return on investment of previous business decisions to assist with future directions.
  • There is no conflict between the rules and process domains, they’re complementary. I often joke that business process people want to embed all rules into their process maps and just turn them into big decision trees, whereas business rules people want the business process to have a single step that calls a rules system, but the truth is somewhere in between. I’ve written and presented a lot about how rules and process should work together, and know that using them together can significantly increase business process agility.
  • It’s not about aligning business and IT, it’s about aligning business strategy with IT capability. Don’t focus on delivering IT systems, focus on delivering business solutions.

Julian Sammy of IIBA tweeted that he was recording the keynote and will put some of it up on YouTube and the IIBA site, so watch for that if you want to see the highlights on video. You can also follow the conference Twitter stream at #bbc2010.