Another way to fail at customer relations

It was a windy day in Wellington (120kph forecast) today but Pacific(Virgin) Blue where confidently predicting the early arrival of DJ56 on their animated web page. Just like being in the pilot's seat!
Drive confidently to the airport  and find that DJ56 has been diverted to Auckland and will make another attempt to get to Wellington some time later in the day. Return home.
Wondering when I should return to airport to pick up returning son, I head back to Pacific Blue's site that had impressed me earlier to learn that the 'system' thinks that DJ56 has landed in Wellington on time at 3:15 with a picture of the track to prove it.




This revealed that the system does not report where the plane is, but where it should be . This  is not much use to anyone.
So I had to resort to the dreaded customer assistance phone service. I had to wait over 9 minutes to get a real person, but I had no better plans. What really annoyed me was the music on hold being interrupted every 30 seconds to tell me that I should avoid waiting by going on to the (discredited) website. Eventually, a real person was able to tell me that the plane was due to land in Wellington at 3:05 (the local time was then 4:18). I suppose the call centre was using even more out of date information a few time zones away. I updated the call centre with the news that the plane had been diverted , and was, after another delay, advised that that was correct but they had no further information! Not even when it was due in Auckland.

Keep the coding out of BPM!

Phil Ayres writes on experiences in the refreshingly un-politically-correct world of Mexico City. I particularly liked the learning point:

if you can avoid coding (and in my opinion HTML, Javascript and all that proprietary script inside a BPM tool is code) do so. Code makes BPM solutions brittle, and hard for business users to update in the future.

The developers of BPM solutions have done a good job of providing process design tools and execution engines around the process flow. Unfortunately, the likes of Intalio, clutter their core idea with attempts at being a total application development system and fail. Even HelloWorld examples get cluttered with XPATH, SQL, XFORMS and Javascript.
BPM solutions seem to have been accidentally painted as an alternative to disciplined development and lessons painfully learned in IT-shops are having to be relearned.

It would be nice to see BPM solutions architected with clear separation between presentation, data-handling, business decisions, rules and process flow logic. Coding is required somewhere along the way but we should all understand where and who is responsible for it.

Business Rules Concepts

Business Rules Concepts by Ronald G. Ross (Third Edition)

This is a handy introduction to business rules where it really matters, in the business side of the enterprise.
I read this from two perspectives - as an old-stager in the IT domain and viewing it as a text to recommend from enterprise architect to business decision-makers.

The first pass left me spluttering "well how would this work in practice" at a number of stages. On the second read I was nodding in agreement throughout at the exposition of why expressing Business Rules formally, is a good thing.

What I would like to see is a companion volume "Business Rules Practice Manual" but as Ron Ross says this is probably best provided by some hands-on consultancy.

I did feel that the concept of separation between Business Rules and Business Process could have been pursued more. Certainly you need to avoid coding your business rules within the business process as you would wish to keep them out of the mainline IF-THEN coding of CODOL, JAVA or whatever but some hints about how to integrate the use of BR with BPM would have been useful.

I was glad to see the re-introduction of Decision Tables, familiar from my youth in COBOL and PL/1 programming. However, the examples of decision tables miss explanation of both the basic principles and reasoning. My use of these, from software development, is a bit dated but wikipedia provides a clearer grounding with this example:

A technical support company writes a decision table to diagnose printer problems based upon symptoms described to them over the phone from their clients. The following is a balanced decision table.

Printer troubleshooter

		Rules
Conditions	Printer does not print	Y	Y	Y	Y	N	N	N	N
	A red light is flashing	Y	Y	N	N	Y	Y	N	N
	Printer is unrecognised	Y	N	Y	N	Y	N	Y	N
Actions	Check the power cable			X
	Check the printer-computer cable	X		X
	Ensure printer software is installed	X		X		X		X
	Check/replace ink	X	X			X	X
	Check for paper jam		X		X

With a business rules focus you may object to the expression 'Action' . Replacing 'Action' with 'Assertion' probably meets the intent within Business Rules.
The example on page 111 is particularly difficult to understand.
The use of N-values conditions makes it difficult to rationalise the large number of rules that you get when using many conditions independently to determine what to do. I would replace the N-values with a set of binary values Customer IS 'Silver' etc.
Introducing the 'ELSE' rule feature of classic decision tables at this stage might avoid frightening people with the thought that they are going to have to explicitly deal each of the 192 rules. Yes, 'ELSE' does sound a bit like programming so how about 'Otherwise' or 'Default'

One further niggle - the Table 12.2 is missing in the copy I received -even in the digital age human error can still get you! Ron kindly provided a pdf of this.

That said, if you want to explore the sound basis for Business Rules in your enterprise, start with this entry point.

Beyond the Enterprise

In public sector organisations, I still see architecture efforts being focussed inwards on making the IT shop more effective rather than outwards to serving the public service goals. While reducing costs is laudable, looking at the broader picture in the government/public sector may reap more benefits through common design and implementation. Some obvious examples spring to mind:

• Shared data-centres and infrastructure - the physical components of "IT"
  
• Shared software stack - a managed selection of components on which particular applications can be built
• Shared business services - eg HR, communications, 

These ideas seem attractive but getting sufficient momentum to make effective enterprises at lower cost has been hard. How can we do better?

• 'Benevolent' dictatorship
• Build it, and they will come
• Present idea and everyone will see it your way

"Yeah right" but there is an alternative that could be born from the efforts of enterprise architecture professionals to architect the enterprise. If, as the Enterprise Architect, you start from the Business Operating Model of your enterprise, there is a fairly obvious set of divisions that can be made:

• Things that are common to any organisation (accounting, hr, property management ...)
  
• Things that are done because the enterprise is part of central government or simply in the public sector. (Budget cycles, freedom of information, working with elected bodies ...)
• Things that are peculiar to the sector of government the enterprise is working in (education , health, transport ...). All governments seem to sprout specialist agencies in addition to the main portfolio departments/ministries.
• Things that service the relationship of government to sector. For example a common health record is a service across public, private medical services and the individual clients of those services.
• Things that are special to the enterprise - (delivering welfare payments, certifying standards met...)

Part of any strategic review by Enterprise architects in the public sector should be to separate the business goals/functions/processes into the broad categories above. Original thoughts and planning can be reserved for the last class. Items falling into the other sort bins are candidates for shared or common services.

Common to any organisation	Rationalise to standards of business practice Work with "all of government" enterprise architects for strategic direction and implementation roadmap for common solution from readily available components.
Common within government organisations	Work with "all of government" enterprise architects for strategic direction and implementation roadmap.
Sector of government	Work with "sector government" enterprise architects for strategic direction and implementation roadmap.
Sector business services	Note there is not a  common 'head' organisation here. A sector is more of a federation of providers and consumers of services. Ring fence these services for formal definition. Establish lead provider for these within sector.
Special to this enterprise	Internally-focussed business process improvement. Look for business functions that can be generalised (generic application processing rather than application for dog licence)

That is just looking at the business operations ... technology follows! In all cases when considering the technology components, solution architects should be directed towards common services and common behaviours. This is important even for business functions and processes that may be regarded as one-off.

Right answer in selecting a BPMS - three BPMS???

Janelle Hill, Gartner Research VP,  was quoted by Mike Gammage in The BPMS Finds Its Home

'The right answer in selecting a BPMS is often three BPMSs, based on the particular projects' needs.'  

An immediate reaction to this is "what twaddle, doing the same thing 3 ways ..." but this may just be a characteristic of our time.

A need for end to end process definitions  was established (and it would be nice for them to be easily transformed into execution). IT solution vendors are just catching up by delivering products or relabelling earlier ideas as BPMS.

Governance practices over introduction of new technology are heavily weighted to buy rather than build, for very good reasons. Unfortunately, the Business Process and its management is only a component of the solution to any practical business problem.

Pure-play BPMS vendors emerged providing an attractive solution to the technical need for a means of execution of business process specifications but a very sketchy idea of how solutions could be delivered. Grafting on Business Rules Engines, rudimentary web user interfaces and database may make the product look attractive to a small development shop but tends not to tick the boxes for a project focussed on getting the business working quickly. A reasonable judgment call would be to accept the need for standard expressions of business process (BPMN, etc) and simply require the bought solutions to be compliant. This may result in multiple products but at least the short-term needs are being met.

If the BPMS bit of the technology portfolio looks to be an area where rationalisation to a single implementation is a priority, we actually need to be able to design to use BPMS as a component of the total solution and not expect the BPMS component or vendor to be the driver for every solution. As Mike Gammage says,

Out in the real world, business processes are only partly automated, and they need to be made visible and managed and improved end-to-end.  If BPM is seen as being focused on just one part of the CIO's portfolio of automation capabilities, then we've surely lost the plot.

So in our Enterprise Architecture efforts we need the business to be formalised in Business Rules, Business Process, and Decisions as well as having technology pieces that map to these formal constructs of the Business Operating Model.

Do Rules need a Rules Engine?

Do Business Rules need a Rules Engine?

Architectures tend to spring from technical IT types stacking a set of facilities that they have or can buy into a neat PowerPoint picture and centre on the solution execution rather than the long path of getting there. Hence, when Business Rules is thought about, a box is placed centrally labelled Business Rules Engine. A couple of bullet points in the presentation to senior management cover the concept that a clear statement of facts and rules by the business will be transforms magically and with little effort into operating code in the IT domain.
There can be little argument against stating the requirements in a provably consistent form that can readily change with  business change is a good thing.
Mark Myers provides an insight this month. With an example of an organisation that did its rules definition so well that a rules execution engine did not add value.

 As part of our SOA architecture we had specified a rule engine.  We had a vision of "rules as service" and using the rule engine would be the core component.  The job of the rule engine, in part, was to help meet the business goal of "agile rule management."  Our thought at the time was that this kind of interface would aid in rule change and rule management.  As it turned out, the business involvement in maintaining a business-side repository provided a much better interface in managing rules.  The amount of meta-data needed to accompany each rule could not even begin to be captured in the interface offered by the rule engine.  During this process the business became very interested in and knowledgeable about their business and just wanted the rules (logic) implemented.  They didn't want to be involved in the gritty implementation details and really didn't care how the logic was ultimately implemented.

 Mark Myers, "Something Happened on the Way to the Forum:  Did We Really Need a Rules Engine?" Business Rules Journal, Vol. 11, No. 3 (Mar. 2010), URL:  http://www.BRCommunity.com/a2010/b526.html 

So no, you do not need a 'rules engine' bought in to execute rules. If you have a comprehensive development shop working in the SOA style then the implementation of an additional engine in the mix is probably not an effective use of budget.
However, if you are less blessed or want to downsize those pesky developers then there are rules engines out there. BUT the most important thing is to capture the rules, facts, nouns and verbs in a manageable form within the business.