I recently saw a piece by Ken Vollmer and Colin Teubner of Forrester called "Increase Business Agility with BPM Suites". There's a lot of good commentary in the report but I have to take issue with the approach it takes regarding business rules.

"Forrester believes that the reality of the digital age is that your business is embodied in your technology, and your business can change only as fast as your technology can. Forrester's Digital Business Architecture is designed with this new reality in mind and includes business process management (BPM) capabilities as one of its core components."

All well and good, however Forrester has previously said that a Digital Business Architecture requires policies as metadata AND the ability to use this metadata across a heterogeneous environment. But:

• BPMS don't really manage business rules or decisions properly - they manage process orchestration and process flow design but not rules/policies. Where they have some support for rules it is really only as part of the definition of orchestration or composition.
• Most BPMS don't capture rules well or manage them well and even when they try to. Even if they were extended to do so, by and large the rules would then be limited to the specific BPMS being considered and so would fail Forrester's own Digital Business Architecture test of being able to reuse this metadata across a heterogeneous environment.
• This is particularly problematic if a company needs both an integration-centric and a human-centric BPMS - something Forrester recognizes as realistic - as embedding policy rules into each BPMS means duplicating them and failing to manage them as an asset.
• While I agree that there is value in adding BI capabilities within a process I think there is also value, and potentially more value, in adding analytic models to aid automated decisioning within the process. This means having a platform for decision automation as I argued in this article on using business rules as a platform for bringing analytics into a process.
• Lastly, and most importantly, routing rules are not business rules. The examples of rules in the report are really routing rules, not decision-centric business rules and these kinds of rules are different as Bruce Silver argues in this post.

So I don't believe having rules in a BPMS is enough - you must be able to externalize rules/policies and manage the decisions powered by these using a business rules management system. I have talked before about the value of business rules in implementing a digital business architecture such as Forrester describes as well as on how business rules can enable business/IT collaboration or "concurrent business engineering". In addition Bruce Silver wrote a nice piece on this for Intelligent Enterprise recently and I have posted on why I think BPMS and BRMS are complimentary and should be separate to avoid over-synchronization.

Technorati Tags: agility, BPM, BPMS, BRE, BRMS, Business Process Management, Business Rules, digital business architecture, SOA, concurrent business engineering

Posted by jtaylor in Business Agility • Business Process Management • Business Rules | Permalink | Comments (0) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Next session was Tom Debevoise on BPM/BR Method: Critical Success Factor for the Agile Enterprise. Tom is the author of book on Business Process Management with a Business Rules Approach and has a blog. Much of Tom's talk was pretty similar to stuff about which I blog as he tackled what rules and processes offer in terms of agility and what are the characteristics of business agility.

He argued that agility is driven by a need to save time (the scarcest resource), new economic forces such as globalization and outsourcing, Tom discussed how one can measure one's agility by mapping to several areas in a business and describing them in terms of the time from instantiation through recognition, solution development to actual implementation.

Tom discussed how both the management theory of BPM and the technology of BPM affect agility and he described business rules as a way to mediate the information in the process flows and then walked through how this would improve your agility e.g. by eliminating the need to train someone in something by using rules to automate it. How much agility would this add to an organization that had to hire and train people often? He argued further that more atomic process definitions will help with agility, moving towards an SOA-based approach to designing an organization where rules-based services are orchestrated to deliver processes that were needed.

Tom asked the audience the question if they were using new technology to generate old-style stovepipes and silos? He suggested building rules for scenarios like catastrophes and "rainy days", designing for more configurable processes and building rulesets ready for change over etc. He also discussed the lack of a good metric for agility and that only subjective analysis, such as that used in manufacturing is currently available. Focuses on these metrics of agility should inform the way you approach BPM and rules.

Technorati Tags: agility, BPM, BPMS, BRE, BRMS, Business Process Management, Business Rules

Posted by jtaylor in Business Agility • Business Process Management • Business Rules | Permalink | Comments (0) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

The folks from InScope and SAIC presented next on Business Rules and Requirements Management at the IRS. Now the IRS' rationale for change involved a number of things, all pretty typical except perhaps for the rule engine one.

• Cost and schedule overruns
• Inconsistency
• Decreasing maintenance budget (by 80%)
• "rule engine frenzy" - used the technology without understanding rules
• Communication problems, often very late in the schedule

Technorati Tags: BRE, Business Rules, government, legacy modernization

To make this work they created an office, methods, standards, tools etc. Did they have any experience first? They tried some pilots to show success and tried to learn themselves also not just use consultants. Also set up a requirements management office but merged them into one as there was too much overlap. The separation between them did not help and having one office, taking a holistic approach and maintain common models and traceability. They had to help the IRSunderstand difference between business rules and requirements. This is something about which I have blogged repeatedly. The presenters argued that there is similarity - both trying to extract business knowledge to help build the right system. That said, they are quite different, and the presenters two key differences seem right:

• Requirements describe the system required where business rules declare the approach the business should take.
• Business rules live based on cause - regulation, policy etc. Requirements live with the system.

They decided that to make this work at IRS they needed to adapt the existing methodology to handle business rules, something I think is a best practice. Business rules still need a proper project and systems framework. They also focused on organizational, location, process and rule models as a set. On the rules side they built a hierarchical model (not sure that works but it is probably OK for a logical model), dependencies (although this is mostly documentation as rules are declarative so modeling dependencies can be redundant), conceptual terms etc. They then linked to the process model but this seems to make the dependencies redundant. They also needed to put out a Requirement Statement so figured out how to produce one.

Was the management of requirements and rules a cause of confusion?

The presenters had some good advice for introducing new approaches like this:

• Change management was, of course, a big issue. Need to build relationships, take the time to introduce ideas gradually to key people helped promote the ideas.
• Staged, planned introduction of idea with multiple ways to communicate and included successful projects as part of the communication.
• They also had to handle the "been there done that" mentality that this is just another new idea and will go the way of the last one. Need to show you have learned the lessons and take the time it takes.
• Don't try and make the method/approach perfect before starting to use it

The approach seems to have helped the IRS get a grip on some of the duplicate work, reuse artifacts across projects, improve review quality and done well enough to get new projects to want to take the approach. It is still a very manual process and no automation yet but it seems like they made some good progress.

Posted by jtaylor in Business Rules • Legacy Modernization | Permalink | Comments (0) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Next was Andrew Spanyi on The Central Role of Leadership in BPM. Andrew wrote both"Business Process Management is a team sport" and "More for Less". Andrew described his biases as being enterprise-focused and people (process don't do work, people do). A couple of years ago he did some qualitative research with Babson - his hypotheses about companies doing process improvement were:

• They would have a map of their business process
• They would measure what's important to customers
• They have a plan
• Would have appointed some process owners

Biggest problem is the dominance of the traditional mindset but successful process companies have:

• A receptive culture ready to use a new approach especially a willingness to learn and improve
• A competitive threat forcing change - there needs to be a sense of urgency
• Passionate about customers
• Supportive CEO - did not start the effort but seemed necessary

He identified 5 things that made a difference to becoming process centric.

• Took time to frame and communicate in process terms
  Not just a functional, organizational view of the organization.This can be done with a very simple model or a standard framework e.g. Nokia only had 4, Air Products 15. All very clear, none of the leaders had a confusing framework.
• Measured success
  Must measure the process and focus on the small number of key metrics, including some focused on customers. In successful companies these are used for performance and reward and expressed impact of measures in operational/financial terms.
• Moved the conventional wisdom deliberately
  Added the process dimension to the way people thought - businesses or organization, function and process. Lots of training, explicit focus on process as something to be managed.
• Carefully selected projects and tools
  Leadership engaged in selecting projects, tools, approaches etc. Took a structured approach and had the management team participate in selecting projects. Also used integrated methods -a range of methods, some flexibility so can select what is needed.
• Process Governance
  Various different approaches (matrix, process owners, etc) but invested in getting it right and gave them some bargaining chips (such as the IT budget allocated to processes or discretionary compensation). Most importantly were leadership actions that showed it was important to manage processes. Questions, objectives, sensitivity to dependencies, less finger pointing etc.

Interestingly CIOs never led the initiative, but a good CFO-CIO relationship was key. Successful projects tended to talk about the outcomes not the business/IT divide or about tools and technology. Engagement and collaboration made a big difference. Takes time and effort but in terms of a journey from one-time projects to something enterprise-wide he identified measuring what customers care, link to strategic issuesand collaboration as key actions.

Wish he had longer. Will have to dig up his books.

Technorati Tags: Business Process Management, management, organizational performance

Posted by jtaylor in Business Process Management | Permalink | Comments (1) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Next was a panel on Transforming to a process driven enterprise with Savvion, EMC/Documentum (representative from Proactivity acquisition), Adobe and BEA (someone from the Fuego acquisition)and hosted by Tom Dwyer of Yankee Group. Tom gave a fairly generic but useful definition of a process-driven enterprise as one "Structured, organized, managed and measured in terms of its core business processes" and outlined the consequences of this in terms of being able to execute process models, a managed portfolio of process, a systematic way to conceive and analyze and ultimately introduce new processes.

Interesting thoughts from the panel

• Companies are focusing on fundamentals - to be competitive must be better at fundamental processes than competitors.
• But most discussions start with a hard-dollar problem that has a process problem. Once a process solutions has fixed business problems then can build on this success and go top-down by saying "what else could we fix".
• A focus on customer experience is also driving process-centric thinking as it is processes that drive these interactions.
• Execution focus (especially at the business level) is perhaps a key difference today as thinking about process has a long history but only recently have tools, terminology, experience meshed.
• Some process change comes from mandates (e.g. government agencies being forced to change processes) but still worth having an ROI mind set to generate the successes that will that drive change
• Some interesting discussion about the tendency of process automation to focus on efficiency not effectiveness - this is what drove the creation of decision yield as the same issue comes up in decision automation. You need a broad focus to be sure you get your benefits. Question should be about "how can someone improve the way they operate". Interestingly I would argue that this is one of the reasons that you should think about decisions as well as processes - you might find that improving the decisions in a process is all you need to do, you don't need to (or perhaps cannot) change the process.
• No-one is going to argue that doing processes poorly is a good idea but cultural issues are an issue and people don't feel empowered to make changes. Companies also don't know the process even if they know it does not work well and this creates another problem.
• What causes companies to act? Pain. Hard to generate energy for change without pain awareness
• What can you tell senior management about the consequences of moving to a process-centric view? Try and map to their goals

Technorati Tags: BPM, BPMS, Business Process Management

Posted by jtaylor in Business Process Management | Permalink | Comments (0) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Second on day 2 was Ken Boyd an Enterprise Architect with the FBI with Business Process Management at the FBI. The FBI's approach is to take a systematic, but incremental approach to rethink and redesign business processes within the context of mandates and policies - separate thread to try and change organizations/policies so as not to bog down the process change efforts in the post 9/11 world. FBI also recognized that the Virtual Case File project wasted a ton of money and scrapped the project and is trying to learn from this in its new work. Additionally the FBI is even more regulated and subject to oversight than before and internally it has new needs, especially to prevent not just investigate crime,and has old, legacy, obsolete, siloed and manually intensive systems! When analyzing their processes they found that many of the inefficiencies are policy or oversight driven, making change to these key in their to-be environment where possible.

The initiative is to rethink its business processes to focus on new goals and deliver new approaches, new technologies and new organizations. First steps were to demonstrate executive leadership team/governance and then bring projects together in a business process management office. Focused on the processes that the new case management system (Sentinel) will support. This focus on some of your core processes is a good "best practice", by the way, as these are the process where the ROI comes. Ken presented how the Business Process Management Office worked and clearly the FBI has adopted Gartner/Ken Orr Institute best practices. They had a well defined portfolio approach and have clearly spent some time identifying and streamlining their value chain while fitting it into the architecture approach discussed yesterday. They seem to have done a good job balancing bureaucracy and thoroughness and changing their reputation for "yesterday's technology tomorrow" while, of course, getting less money... Their focus on organizational change, promoting the upside and generally thinking about how to create a willingness to change along with an increased capacity for change acceptance is very appropriate for an organization of their size and complexity.

Interestingly the FBI is using BPMN using System Architect from Telelogic. Mapping this to Business Process Execution Language for Web Services (BPEL4WS) which sounds interesting but worries me slightly on the rules front as BPMN's support for rules is very weak, as noted by Bruce Silver on his blog. He identified Bizflow and Metastorm as BPM software that the FBI is using but the implication of this talk was that this is mostly about coordinating people and legacy systems with little focus on how to automate more of the decisions within the process. He also did not discuss event processing (CEP) although they are focused on activity monitoring (BAM) across their BPM systems. Wish he had talked more about this as this kind of response-oriented processes seem critical to the FBI.

Technorati Tags: BPEL4WS, BPM, BPMN, BPMS, Business Process Management, government

Posted by jtaylor in Business Process Management • SOA | Permalink | Comments (1) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

First session of day 2 was Achieving Operational Excellence with BPM with Jannelle Hill of Gartner. She discussed BPM as a management theory of business process management to use process as an organizing concept in business, not function. Complements functional orientation for operational excellence, increasingly with agility as well as more traditional benefits. She asserted, and I agree, that to some extent everything you have ever done to automate stuff is "process management" but implicit, not explicit. Not visible to business people and they cannot manipulate the transactions flowing through the process. BPM is about making all this explicit. Key issues she identified:

• how can you find the inefficiencies
• how can you achieve sustained operational excellent
• what evidence exists to show BPM works

She went through the steps involved, the roles of business and IT, presented some example results and described what a process-driven management company might look like.

Technorati Tags: agility, BAM, BPM, BPMS, BRE, BRMS, Business Process Management, Business Rules, CEP, Event Processing, services, SOA

So, what are the steps to adopting this that she identified?

1. Use process as an organizational concept to breach silos (organizational and technical/application)
   Business rules and process steps owned by people in the business while hand-offs made explicit and roles aligned and can identify obvious inefficiencies - automation opportunities for example. It seemed to me that this is similar to RMM level 1 where one tries to make rules explicit. Using process modeling helps identify business rules and can help identify shared rules etc.
2. Understand BPM and its related technology
   Need an improvement lifecycle involving analysis, execution, monitor, optimize etc. Given that 80% of steps are automated in the US, IT is deeply involved and old automation does not allow rapid enough change. This means that business people must take control of some automated steps to make sure can change fast enough and this involves simulation and analysis of process and process steps. Gartner calls the technologies for this a Business Process Management Suite with a focus on real-time monitoring and execution of designs. Many IT departments might have pieces of these suites already.
3. Create culture of explicit process management
   Analysis and modeling are key skills as simulation/testing is key (25% adoption so far). Being able to visualize and understand the model will often enable the business to immediately eliminate steps, manage them better or automate them represents the low hanging fruit that generates immediate ROI.
4. Develop culture of re-evaluation
   Let's you iterate and so get started with something quickly and improve it - business cycles are too fast to find a "perfect" process. You don't know the end state so you keep iterating to keep improving.
5. Constantly re-evaluate where you are in the maturity model
   Very similar to RMM for rules from acknowledging that one has processes, through automation and control of processes and then the enterprise to a truly agile business (I have blogged before about Gartner's agility model)

Janelle talked about the roles or business and IT and the impact of regulation(like Sox) which is driving business users to want to control more than the manual 20% of a process. She recommended focusing the business on the modeling of the business and the governance structures (which must be more engaging and less command and control as processes change more often). IT should relax and control the pace of change while enabling business to take control e.g. through business rules. Business people are happy to manage human workflow and forms, happy to take control of rules as long as it's parameterized and managed (see this post on helping business users take control in this way).

The response to business events was something Janelle identified as a key form of business agility. Monitoring events to see which ones are actionable and then do something. I would argue that this requires automating the responses to these events as I have argued before in this post on event monitoring and rules. She discussed the use of Business Activity Monitoring (BAM) technology but she was focused only on displaying the results to people. It was not clear if she regards automated response to events as part of BAM or if she would give it a different name (like Complex Event Processing or CEP).

Some results she presented included:

• Time to deliver result in less than 4 months
• No-one got less than 10% ROI while some got wild numbers (presumably when fixing really inefficient processes)
• More and more companies have multiple projects
• Presented on Sprint/Nextel BPM/CRM project - huge project ($9M initially) but broke-even in just 72 days with $110M in annual savings. Dramatic improvement in time to fix (hours v days) and got better data. Improved customer experience and reduced complaints while improving cycle time in responding to problems (e.g. things that drove lots of returns).

She identified best practices including strong subject mater experts, business driven partnership with IT, trial and error and so on. Pitfalls included lack of executive support; an unclear process or a lack of governance; too much modeling (both as-is and to-be)or a traditional waterfall approach; lack of skills and lack of user validation during the project. All pretty expected and all true with adopting business rules too.

Lastly she talked about a process-driven organization:

• Roles aligned by process
• Business has visibility of whole process
• Business rules and processes changed by business owners
• Cost accounting aligned to process
• Risk analysis/simulation based on current operational conditions

All good stuff.

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Process Management • Business Rules • Event Processing • SOA | Permalink | Comments (0) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Last thing today I participated in a panel - Business Rules and Business Process: Perfect Together or Perfect Apart?It was, as usual, an interesting panel hosted by Barb von Halle. This time it was me, Brian from InScope and Tina from CA. I feel like this is such a regular topic that I don't really have much to add. Check out the BPM section on this blog of the other one.

Technorati Tags: BPM, BPMS, BRE, BRMS, Business Process Management, Business Rules, SOA

Posted by jtaylor in Business Process Management • Business Rules | Permalink | Comments (0) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Next session was Barbara von Halle (who occasionally blogs on my other blog) on The Vision for BRS: What You Need to Know In 2006

Barb starts by pointing out that rules can be developed, even though nothing has been defined by asking about baseball. She points out that a phrase like "3 strikes and your out" implies all sorts of things like what a "strike" is, who this rules applies to etc etc. She then walks through the example to show how you harvest rules e.g. all the rules for a batter being out, and that although baseball has a very complete and consistent rules most businesses will have contradictions and omissions. The end of the process should be a complete understanding of how the business operates.She goes on to talk about a recent KPI study that found 5 motivations for business rules:

• Agility (see the blog section on business agility)
• Knowledge Retention
• Compliance (see the section on compliance)
• Consistent Decisions
• (After the fact) A stronger Business-IT partnership

and four approaches to using business rules which she illustrated with some great examples.

• Business rules harvesting and then input to the SDLC. Often by mapping use cases to business rules as described here
• Business rules harvesting and then input them into a Business Rules Management System
  A case study for the first two of these found that some 70% of the rules were "wrong" - the code ran wrong and was worked around, the code did what was intended but there was a mistake.
• Business rules harvesting from legacy systems for legacy modernization (see this section on legacy modernization)
  She noted here that thousands of rules found in the code for one client mapped to just 150 "real" business rules and that legacy mining is really only a good idea when there is no alternative!
• Business rules harvesting and business transformation by changing just manual processes or by telling IT to make changes
  Can be done very fast to show the value of focusing on rules. The case study for this showed that this worked and helped generate interest in business rules management.

Interestingly some of these involve business and IT and some only require the business. Barb wrapped up this section talking about the Rule Maturity Model and how most companies working towards Agility (level 2) and Consistency (level 3) which require both a focus on business rules and some technology. She also emphasized that rule management can fail on the business side (not the right rules) or technical side (not working right.

Barb has a model of some 10 types of business rules tools. Personally I think this is a little extreme - I would not separate authoring, analysis, testing and execution into 4 tools as I think these are all tightly coupled parts of a real Business Rules Management System. I do think that having a way to manage strategy and map it to rules and a way to map rules back into the requirements process is useful. Rule Mining is clearly a separate tool, as are analytic tools for deriving rules. I might say then that there are four:

• Business rules management system with authoring and repository
• Strategy and process management tool
• Rule Mining tools (code and data mining)
• Rules as requirements management tool

Barb went on to talk a little about how decisions, and rules, can and should be mapped to multiple processes and use cases to emphasize the importance of traceability.

Technorati Tags: agility, BRE, BRMS, Business Rules, legacy modernization, rule maturity model, RMM

Posted by jtaylor in Business Agility • Business Rules • Compliance • Legacy Modernization | Permalink | Comments (2) | TrackBacks (1)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Third session was Brett Champlin on Making the Transition to Services Engineering. Brett was contrasting services engineering to industrial engineering as the economy transitions from manufacturing to services-based (note this means services compared with products rather than SOA-type services). A little bit of history first - when manufacturing was key there was rapid growth in research and techniques for improving manufacturing. This led to a reduction from 60% in manufacturing to just 22%. This has been matched by a massive growth in services so the question is how to apply some of the established industrial engineering techniques for productivity to services.

He had great stats on the opportunity for improvement in services - 50% of service work adds no value, 90% of elapsed time is waiting for work to happen, estimates of 30-80% waste. In addition he noted that being world class in services means only being 5x as bad as the theoretical maximum while world class manufacturing is only 2x theoretical maximum! There is lots of opportunity, therefore, to improve service effectiveness just as we improved manufacturing.

Problems with services and improving their efficiency are many and include the fact that they have intangible, time-perishable outputs and that both decision-making processes and customer experience are key to the efficiency of a service. For instance, customers might regard "good service" differently, process are less defined and may differ from customer to customer. Several processes might be required to deliver a service. Services can be hard to measure thanks to intangibility (all services have some degree of this), heterogeneity (as different people do services differently), simultaneity (outputs consumed when produced) and perishability (can't be stored). Do we have to include customer processes when considering services? Probably, and this means a focus on the "moments of truth".

Brett found that traditional classification schemes do not work well but that there is one that seemed better:

• Professional Services (highly customized, lots of discretion, lost of customer contact, process-focused)
• Service Shops
• Mass Services (standard, no discretion, less customer interaction, product-focused)

I think that services and the issues around "automating" them force a focus on the automation, or at least automated support, of decisions within those services. In addition hand-offs and wait times, big issues in services efficiency, can be managed using decisioning technology. Of course, personalization and customization are also going to be big issues. Interestingly I am presenting on a similar topic - Challenges and opportunities in customer-led services- at UC Berkeley in the fall and will post more on this when I have some materials ready. If you are interested, check out the Services: Science, Management & Engineering (SSME) program at UC Berkeley.

Technorati Tags: decision technology, services

Posted by jtaylor in Decision Technologies | Permalink | Comments (0) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Second session was Richard Burk from the OMB (Office Management Budget)on Integrating Architecture Into the Development of Cross-Agency Lines of Business. Dick leads the development of a business and technology framework for e-gov.He is focused on getting different agencies to use common elements of enterprise architecture across the large IT budgets involved in government. He noted that he has a Board of Directors of 535 (House+Senate) which explains a lot :-) Seriously though, he went on to explain how priorities tend to be set politically and how this has implications for architecture as these priorities drive 10,000 programs that can easily be isolated and so create problems. Most current issues in fact cut across agencies and involve cooperation between agencies, state and local government and commercial bodies. Rarely does an initiative or bill manage this, hence the OMB architecture work on Enterprise Architecture to make these things work together. He recommended "Enterprise Architecture as Strategy" by Ross, Weill and Robertson as an overview of this approach.

One of the first issues is one of semantics about what everyone is talking about. He introduced the Federal Enterprise Architecture reference models - Performance Reference Model (what am I trying to achieve), Business Reference Model (what do I do and for whom), Service Component Reference Model (what services do I need), Data Reference Model (what data for these services)and Technical Reference Model (technologies to enable all of this). A functional view of the federal government based around the Zachmann Framework (albeit slightly simpler). He explained some architecture principles that drive overall choices for federal government programs - these were great, nice and high-level but good guidance e.g. "the federal government is a single, unified enterprise" or "the federal government focuses on citizens". Seemed very "well, duh" but I liked them as it amazes me how often this kind of stuff is not written down or agreed. Most companies could take a lesson from the Feds here. Dick gave some great examples of how a simple statement drives behavior by drilling into the "federal architecture is mission-driven" and showing how it leads to things like only monitoring improved (not as-is) processes for instance. He also talked about how architects must focus on the line of business - what is your business?

To "eat the elephant" they drive down into various service areas - business services that support an agency inside and citizen services that face out (each agency is impacted by some citizen services) as well as cross-service facilities like records management or security. These can then be applied iteratively to the agencies and their lines of business and work both top-down (adopting standards) and bottom-up (driven by needs in specific areas) to derive an Architecture Portfolio. Specific investments are made in the context of these architecture outlines to create an Investment Portfolio. Planning results in a Transition Strategy and all of this must have end to end governance. Separating the architecture from the budget process and getting it up front to guide everything and focus investments was key and took a while, especially given the desire to hang on to money allocated to specific initiatives. One of the nice things he talked about was various aspects of initiatives to see how well they are going. They were:

• Completeness (how much of it is done)
• Usage (who uses it, for what, what percentage)
• Results (what return on this investment)

I liked this as it seems to me to be a great set of measures for any initiative. This year he has a lot of cross-agency initiatives (24) and they are developing a catalog to show how these support the services each agency uses while giving each agency 6 months to apply it and figure out how to request the money they want for NEXT year. OMB has to verify that the investments match to the architecture so that the budget process is linked with the architecture. This stops the architecture from becoming an interesting experiment and makes it part of how agencies build and use budgets. Very cool.

This did not really fit with any of my categories but I thought the legacy modernization was the best, given how effective his approach seemed likely to be as a way to manage large scale legacy updates.

Technorati Tags: architecture, government, legacy modernization, portfolio management

Posted by jtaylor in Legacy Modernization | Permalink | Comments (0) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go. I am not sure if the wireless network will allow me to blog "live"but I will at least post them every few hours.

First session was the Master Mind Session: Enabling the Agile Enterprise with a panel of the show speakers. This is always interesting as it brings together the folks who talk about business process, business rules, SOA, enterprise architecture and performance management. Although the topics seem highly related it often amazes me how little overlap there can be.

Anyway, Ken Vollmer starts off by trying to show how the various pieces fit together. The biggest problem with the view he presents is the failure to link SOA with business rules. Personally I think that SOA requires decision services in general, regardless of whether business process management is the objective or not. Brett Champlin went next and discussed how business process management discipline enabled by technology but process-oriented thinking is #1. Interestingly I think that this is true for adopting business rules also- think about the process, think about the decisions the process needs, decide if those decisions should be automated (in parallel with deciding if automating the process is useful or if my existing systems work just fine).

Bill Ulrich gave a nice overview of how rules and processes fit into a Business Architecture and should/do drive the adoption of an SOA IT infrastructure. The need to enable business/IT collaboration is key and a primary objective of business architecture. Tom Dwyer introduced SOA and emphasized its long conceptual history - the need to have more dynamic, more agile infrastructure to allow recombination of software assets.He also discussed the synergies between BPM/rules/process-thinking and so on with SOA and the fact that SOA sits between a bottom-up integration layer and a top-down process-centric decomposition. Tom talked about SOA as a long term objective for companies, not a simple technology adoption project.

Barb talked business rules and used an example of driving rules (as applied to Italian taxis) to illustrate how unwritten rules and local interpretation can make a big difference! She also asserted, and I agree, that the business rules within a process often change more often than anything else in the process. She also outlined KPI's maturity model from level 0 (no idea), through trying to find the rules, through managing and optimizing rules. Alan Ramais discussed organizational performance and the challenges of creating sustainable, high-performance. You must plan for the kind of performance you want, design it and manage it. This applies at the organizational, process, job role and technology levels. To some extent he is emphasizing the "design with the end in mind" approach - design for the performance you want. If you want process agility, design for it. If you want decision agility, design for it and so on.

They were asked where to start and several suggested that understanding your organization and what kind of performance you want is important. Tom tried to show how an overall blueprint for SOA is essential, even if BPM drives the original SOA adoption. Barb's point of view was to make sure someone is thinking about business rules no matter where you start. There was some useful discussion about pulling it all together and about not driving to a complete SOA (as distinct from using some SOA technology) until you have at least started to think about business processes. In general, however, they all said "start with me". Ho hum. These are interesting people as a group but the session seems to lack a scenario that ties them together.

Technorati Tags: architecture, BPM, BPMS, BRE, BRMS, Business Process Management, Business Rules, organizational performance, performance management, SOA

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Process Management • Business Rules • Event Processing • SOA | Permalink | Comments (0) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

The fourth session was Ken Vollmer on BPM Suites and SOA. Ken started by summarizing the impact of BPMS:

• Capturing of process (and rules etc) as metadata
• Connect physical and digital worlds (by generating/managing code)
• Real-time process monitoring becomes practical (as process is automated and integrated)
• Allows for optimization of processes (through event processing and activity monitoring)

All of which should increase business user control and agility. This is all part of the Digital Business Architecture (about which I have blogged before) that Forrester uses. Business impacts include efficiency, reduced cycle time, better customer service and compliance. IT can reduce maintenance costs, make composite applications quicker and easier to build and drive IT agility also. It is also potentially SOA-friendly.

Ken made a good point that not all BPMS come from the same root - some came from imaging/workflow, some from integration background and, although these are converging, there are still some distinctive groups. Interestingly, I think this emphasizes the value of keeping rules and process separate so that you can use the same decisions/rules across both kinds of BPMS.

Ken showed a graphic emphasizing that automation is the base, rapid development and management of processes build on this and represent current best practice while self-healing and optimizing processes build on this and represent the next stage. Ken talks about Business Event Management (others call this Business Activity Monitoring)as using people to do resolution while Complex Event Processing need not. Very similar set of capabilities in my mind, just a question of who does what afterward. That said, there is more pattern matching and interpretation probably in CEP.

Ken gave a summary of SOA (which I won't repeat as it is pretty standard SOA stuff). He did note that it tends to be slower to build the initial version of an application with SOA but this is largely offset by benefits later in the life cycle. Crossover point happens sometimes from 3 months to a year or so.

He then went on and talked about Enterprise Service Bus products and the relationship with BPMS. Essentially his assertion is that the old Enterprise Application Integration (EAI) vendors have had to drive towards full BPMS as the ESB vendors continue to add capacity. This means you end up with ESBs and Integration-Centric BPMS with lots of ESB functionality.

There was also some discussion about how standards and a service repository are key to integrating SOA with BPMS. He ended up talking about composite applications and how these features (BPMS, rules, SOA etc) can support the development of composite applicaitons. The BPMS essentially hooks up the internal applications (integration) and external service providers to deliver the composite applications.

All in all a bit of a high-level fly-by, not much new.

Technorati Tags: agility, BAM, BPM, BPMS, CEP, Event Processing, SOA, enterprise service bus, ESB, composite application

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Process Management • Event Processing • SOA | Permalink | Comments (0) | TrackBacks (0)

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Third session was Brett Champlin on Making the Transition to Services Engineering. Brett was contrasting services engineering to industrial engineering as the economy transitions from manufacturing to services-based (note this means services compared with products rather than SOA-type services). A little bit of history first - when manufacturing was key there was rapid growth in research and techniques for improving manufacturing. This led to a reduction from 60% in manufacturing to just 22%. This has been matched by a massive growth in services so the question is how to apply some of the established industrial engineering techniques for productivity to services.

He had great stats on the opportunity for improvement in services - 50% of service work adds no value, 90% of elapsed time is waiting for work to happen, estimates of 30-80% waste. In addition he noted that being world class in services means only being 5x as bad as the theoretical maximum while world class manufacturing is only 2x theoretical maximum! There is lots of opportunity, therefore, to improve service effectiveness just as we improved manufacturing.

Problems with services and improving their efficiency are many and include the fact that they have intangible, time-perishable outputs and that both decision-making processes and customer experience are key to the efficiency of a service. For instance, customers might regard "good service" differently, process are less defined and may differ from customer to customer. Several processes might be required to deliver a service. Services can be hard to measure thanks to intangibility (all services have some degree of this), heterogeneity (as different people do services differently), simultaneity (outputs consumed when produced) and perishability (can't be stored). Do we have to include customer processes when considering services? Probably, and this means a focus on the "moments of truth".

Brett found that traditional classification schemes do not work well but that there is one that seemed better:

• Professional Services (highly customized, lots of discretion, lost of customer contact, process-focused)
• Service Shops
• Mass Services (standard, no discretion, less customer interaction, product-focused)

I think that services and the issues around "automating" them force a focus on the automation, or at least automated support, of decisions within those services. In addition hand-offs and wait times, big issues in services efficiency, can be managed using decisioning technology. Of course, personalization and customization are also going to be big issues. Interestingly I am presenting on a similar topic - Challenges and opportunities in customer-led services- at UC Berkeley in the fall and will post more on this when I have some materials ready. If you are interested, check out the Services: Science, Management & Engineering (SSME) program at UC Berkeley.

Technorati Tags: decision technology, services

Posted by jtaylor in Decision Technologies | Permalink | Comments (0) | TrackBacks (0)

I saw this post on Jeff Schneider's blog about design-time agility and performance. He talks about working with a client to "define their core architectural principles" and had one that read "Agility over Performance". His post went on to discussing having both Agility and Performance and the fact that it is

"More common is the need to resolve competing interests such as 'agility' or 'performance'"

At some level he is, of course, 100% correct.There is no such thing as a free lunch and almost any benefit (increased agility say) will have implications of increased cost (say performance problems). That said there are approaches that offer a great deal of agility while minimizing performance problems. To the extent to which SOA delivers agility it can be done without a massive performance hit as Jeff discusses. However, making services themselves agile (rather than assemblies of services) requires a different approach to programming them. Using business rules to build decision services can offer a very high degree of agility while still delivering great performance - not only do many business rules management systems offer a compiled-out version for sequential execution, new algorithms for inferencing such as Rete III mean that forward-chaining or inferencing can also deliver high performance when the agility offered by it is essential. Using business rules to develop these decision services offers great agility without having to build clunky database-table driven parameterization or something.

Jeff correctly pointed out that the recent focus in IT development has been to make software more agile from a design perspective and summarized the reason for this nicely as well as pointing out a key issue in some shops:

A fundamental notion that I.T. embraces is that we must increase developer productivity to enable "development at the speed of business"
Many I.T. shops have implicitly embraced the opposite view (Runtime Performance Cost over Design Time Agility).

It does not matter how fast you can process a transaction if the way you are doing it is no longer the way your business wants you to. Sacrificing this kind of agility to maximize runtime performance is not just stupid, in this era of regulation it could be criminally negligent. Modernizing your legacy applications to add this kind of agility might be just what you need.

Technorati Tags: agility, BRE, BRMS, Business Rules, legacy modernization, SOA

Posted by jtaylor in Business Agility • Business Rules • SOA | Permalink | Comments (0) | TrackBacks (0)

I was reading Ronan's blog and saw this post about three styles of SOA. The three styles were:

• SOA based integration
• Modern, composite application development
• Modernizing mainframe and legacy applications

This got me thinking about the styles or patterns of use of business rules in SOA and I came up with 7. These built on the discussions I have been having with various folks about the use of decisioning in Complex Event Processing(CEP), Business Activity Monitoring (BAM) and Business Process Management (BPM) as well as in Service Oriented Architectures (SOA) more generally. So here goes:

1. Decision Components
   A component in a composite application is decision-centric (it has lots of rules, rules that change a lot, rules that interact in complex ways or rules that require business expertise to manage) and so should be designed and built as a decision service. It might also need to be changed often or out of synchronization with the rest of the application. In many ways these are the classic "rule services" people build with business rules.
2. Decision Activities
   An activity in a process is a decision such as assessing credit-worthiness or deciding what cross-sell offer is most appropriate. These should be identified explicitly in the context of a Business Process separately due to synchronization issues and others (see this post for discussion of synchronization). Clearly the difference between this kind of activity and a decision component above is more contextual than real.
3. Event Decisions
   An event requires a decision to be taken. This might be a simple event trigger (see if a particular event should be escalated or not), or tied to Business Activity Monitoring (BAM) or Complex Event Processing (CEP) software that handles much of the initial processing and event handling and only uses a decision service when the remaining decision is a business one. I have had a fairly spirited discussion on CEP and decisions with David Cameron (see this post on different uses of rules in CEP) and have blogged previously about the potential for enhancing BAM with decisions.
4. Complex Routing
   A gateway/branching node within a process might have implied complex decisioning - in this case you are going to get routing rules in the BPMS that use a decision service to do the heavy lifting as otherwise you are going to have hidden decision logic buried in your process which is almost as bad as having it buried in your legacy code. Bruce Silver made a good point on this topic on his blog in the context of rules and BPMN.
5. Legacy Exposure
   Part of a legacy application needs to be serviced enabled and that part is both maintenance-rich and logic-oriented not data-heavy. In practice this means you have some business logic that is part of your mainframe application, you need to re-use that logic but the maintenance burden of keeping that logic up to date is high. In this case it might make the most sense to renovate that part of the application into a rule repository, regenerate the rules into the mainframe environment and expose the rules using a rule service for the rest of your services to access.
6. Intense Transformation
   There are circumstances in which the transformation of information is intense in a business (rather than a technical) sense. For instance, many layers of overlapping financial regulations might make transforming local accounting records into centralized ones both complex and subject to audit and compliance. A decision service to handle these transformations might be more effective than embedding those rules into a more technical environment.
7. Enterprise Decisioning
   A growing number of companies are seeing value in treating all decisions as a corporate asset and in providing an enterprise decisioning backbone or universal decisioning engine that manages all the operational business decisions as services and makes them available to all channels and systems. This last clearly subsumes the others. There's a lot more on this over on my Enterprise Decision Management blog.

Clearly all of these can be handled the same basic way - build a set of rules, manage them and expose them as a service for others to use but it seemed useful to lay out the examples. Also, there are others, but these are the main ones it seemed to me.

Technorati Tags: BAM, BPM, BPMS, BRE, BRMS, Business Process Management, Business Rules, CEP, enterprise decision management, legacy modernization, SOA, EDM

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Process Management • Business Rules • Decision Technologies • Legacy Modernization • SOA | Permalink | Comments (1) | TrackBacks (0)

I have been thinking about the response I got from David Campbell to my posting on his CEP article. In his comment David discussed the difference between using a business rules engine in CEP (Complex Event Processing) and using business rules more generally. He says that CEP uses business rules, but not business rule engines because BREs are "best suited to problems where the process steps are linear and predictable and don’t require contextual information about timing and sequence of event patterns "and goes on to say that "The reason for this is that most rules engines today require all of the data used in the rules, including the contextual data involving timing and sequence arrays, to be built in advance and stored in a database". He goes on to say that CEP solutions maintain this contextual information with the event messages to simplify this problem.

Now, while I don't think the statement about databases and BREs is 100% true (many rules engines allow for call outs to gather additional information as needed by rules while they are executing and allow for this data to come from other components or services, not just databases), it seems to me that this is similar to the arguments about keeping rules in a BRMS/BRE or in a BPMS and about the role of rules inBusiness Activity Monitoring also.

I believe that each of these specialized contexts - business process management, event processing, activity monitoring - can take advantage of a rules-based approach with the technology primarily responsible for it - BPMS, CEP or BAM software - but that this is not the same as using a rules approach to automate business decisions. Nor does using rules for routing, activity monitoring or event processing in anyway replace using business rules for decisioning. Why not? Two reasons - reuse and synchronization.

First reuse. By embedding rules in a CEP/BPMS/BAM solution I make it impossible to reuse those rules across the other members of this family of solutions and across my legacy applications. Rules for what makes a good customer, a fraudulent claim or the right next best action in marketing terms are the same across the enterprise and should be managed as the enterprise asset they are. Managing these decisions this way also allows me to invest in improving them, analytically for instance, while maximizing the return. There are rules that belong in each environment, but the core rules for decisions should not.

Secondly synchronization. Rules for routing and handling processes are synchronized with the process definition in the same way that rules for event handling are synchronized with the event definition. Rules for making business decisions within these processes or as a result of identifying an event are not. It is essential you don't over-synchronize business decisions and processes or business decisions and event identification. I must be able to change the way my business responds to an event separately from how it processes and identifies the event. Similarly I must be able to change how I manage a decision without having to change the process(es) that include it.

I am glad to see that CRM vendors, BPM vendors, CEP vendors and more are seeing the value of the business rules approach to managing business logic. The fact that these applications can and should have business rules in them does not replace the use of a business rules management system to manage core operational business decisions across the enterprise.

Technorati Tags: BPM, BPMS, BRE, BRMS, Business Process Management, Business Rules, CEP, Event Processing

Posted by jtaylor in Business Process Management • Business Rules • Decision Technologies • Event Processing | Permalink | Comments (1) | TrackBacks (1)

Randy Heffner over at Forrester has just published two new pieces - Implementing Your Digital Business Architecture and EDA, SOA 2.0, And Digital Business Architecture. They are both interesting but the first one in particular is great. Here's the summary of the paper from Forrester (my emphasis)

Forrester's Digital Business Architecture vision describes the future of IT architecture: A core of metadata that defines business processes, policies, and rules, and controls business operations across your diverse set of IT applications, computing infrastructure, and collaboration channels. But the vision is not intended and should not be used as the basis of a huge IT architecture conversion effort — a complete implementation with off-the-shelf products is not even practical yet. Instead, Digital Business Architecture provides a framework for planning an incremental evolution toward the future, enabling business technology solutions to deliver more business value today and to hold up better as business and technology evolve. So, the question is not, "How do we build a complete Digital Business Architecture?" but rather "Which pieces of the vision provide the most business value for us now, and how can we use it to prepare for future evolution of our business and our technology?"

I highly recommend the paper - well worth the cover price if you don't have a subscription - and think Randy does a nice job pulling together some key themes. I am not going to quote the paper too extensively (as it is a for-fee piece) but Randy identifies business rules as part of both the metadata core and as a key technology for deliver business services. He is spot on in both cases - metadata must define the business and this means being able to define the rules for how that business operates and decision services are a subset of business services that should be built using business rules for maximum agility. Together these allow decisions to be managed as a corporate asset and deliver real business agility (which also involves some changes to how things are done including one called Concurrent Business Engineering about which I blogged before). I like this concept (see this post also) and consider it highly complementary to both business rules as a technology and to decision management as an approach. As for the things I highlighted - managing rules is crucial to this vision, they offer a great vehicle for incremental change and they will hold up as your business and technology evolves.

His piece on Event Driven Architecture is also good and I don't have much to say except that like Randy I think many of the things you need to handle events well also help you handle processes and services well also - the DBA for example - and that I blogged around event processing here and have a whole section on it on the other blog here.

Enjoy.