Taming the Beast of Complexity

This article looks forward from the conclusion of our previous article, ‘Requirements and the Beast of Complexity’[1], also published on Modern Analyst. In that article we presented our case that the typical approach to business requirements management was fundamentally flawed, with key issues being development of business requirements within a project context, and capture of those requirements using unstructured artifacts, particularly narrative.

In the solution presented in that article, tight structure and testability of requirements was achieved by using decision models and fact models. These models could then be transitioned into a project context when required simply by generating them as source code for use as content by the project.

A year on, requirements management is still an untamed beast. The ‘Top 10 Business Analysis Trends for 2011’ [2] recently published by ESI International alluded to the need for improved requirements management in no less than 3 of its 10 trend projections.

As the BABOK® Guide (Version 2.0) [3] delicately puts it:

“The term “requirement” is one that generates a lot of discussion within the business analysis community.”

During the same period, decision management has grown in both recognition and relevance. IDC has recently published a report[4] that highlights the importance of decision management to general business health:

“Because of the flood of data, the faster cycle times, and the adoption of analytics, the intelligent economy also has a rapidly increasing awareness of the importance of the process of making decisions, which we call decision management. Enterprises succeed or fail based on the decisions made by executives. They compete effectively or lose market share based on the operational decisions made by their managers. And they are more or less profitable based on the day-to-day decisions of various knowledge and line workers who make up most of the workforce.”

“Our goal in presenting IDC’s view of decision management is first and foremost to highlight the value of using appropriate process models and technology to support all decision-making processes as well as the value of systematic approaches to managing decision-making processes, especially at large and medium-sized organizations.”

This article builds on our previous article and proposes an exciting new use for decision models that extends the scope of requirements management to help ‘tame the beast’.

Requirements Revisited

Business analysis as described by BABOK describes a relatively seamless scope of activity that starts with the high level needs of an organization and transitions through requirements to address specific solutions, with an emphasis on IT solutions.

“Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”

“In particular, business analysts often play a central role in aligning the needs of business units with the capabilities delivered by information technology, and may serve as a ‘translator’ between those groups.”

It is interesting to note that the BABOK definition above originates closer to the business strategy than the Wikipedia version, which is more tactical:

“. . a requirement is a singular documented need of what a particular product or service should be or do."[5]

This highlights a move by business analysis disciplines to embrace the strategic core of the business, in addition to its products and services. This article now proposes the next logical extension – to address the requirements posed by the ‘business of the business’.

The business of the business

The business of the business is managing the past, present, and future obligations, revenues, and costs associated with the supply of the goods and services provided by the business.

Much of the ‘business of the business’ is defined by contracts - contracts are the ultimate definition of the obligations, revenues and costs of the business. Contracts (including by extension, relevant legislation and regulation) prescribe the rules to which the parties to the contract must adhere. Every operational decision made by the business must be in accordance with these rules, so that contracts are an important prescription for decision making behavior in the organization.

The following are some useful categorizations of contracts:

• Negotiated contracts are complex one-of-a-kind contracts. Examples: large scale telco or utility supply contracts, complex insurance policies, financial contracts (e.g. CDO’s), long term service or supply contracts, superannuation fund prospectuses, etc.

• Standard contracts are simpler many-of-a-kind contracts, often using a published set of terms and conditions for the offer, which is joined by multiple counterparties using supplied application forms and a formal acceptance process. Examples: standardized insurance policies, retail telco and utility contracts, simple financial agreements (hire purchase etc), airline tickets, one time service or supply agreements.

• Performance based contracts vary according to demand variables. Negotiated or standard contracts may be performance based. Examples: insurance policies charging per event (e.g. cargo, travel), volume based telco and utility contracts, performance based financial agreements, on demand service or supply agreements.

• Government funding and payments usually follow the form of standard contracts - a statement of public policy (often changing annually) and a matching application that complies with that policy. The more complex contracts are often performance based. Examples: Taxes and fees, hospital and school funding, grants, individual entitlements.

The business enters into these contracts, and manages itself to ensure the provision of the relevant goods and services, according to a set of business policies. These policies are developed in response to the highest aspirations of the business (as described by its mission, goals, etc) to govern the behavior of the business when both entering into and fulfilling its contracts – business policy is the master of both contract existence and contract execution. Ultimately, the decision making originating within business policies governs the entire business of the business.

These definitions emphasize the strong link between policy and decision making:

“A policy is typically described as a principle or rule to guide decisions and achieve rational outcome(s).” Wikipedia[6]

“A plan or course of action . . . intended to influence and determine decisions, actions, and other matters”. The Free Dictionary[7]

When we combine the jurisdictional, policy, and contract prescribed decision making, we have synthesized the ultimate requirements specification of both the business and the business of the business. By capturing these requirements within decision models, we can control and automate them.

Contract and Policy Automation

Is automation of contracts and policies a reality? Absolutely – we have real decision models in production use today that implement the active components of policies and contracts for all four of our example categories of contract described above. Readers of our previous article will recall that a decision model[8] is a structured and unambiguous specification of the prescribed decision making, and that it can be empirically tested for correctness, completeness, and consistency.

The many passive contract or policy statements that do not describe day-to-day decision making (e.g. , relationships, warranties, penalties, confidentiality, etc) do not affect the operational decision making within the business and can be ignored from a decision management perspective. In a well written contract, the elements that prescribe day-to-day behavior are often isolated into a schedule – at least one customer has taken this to its logical conclusion and attached the decision model itself (in business readable form) as the schedule.

The sum of the decision models within an organization constitutes a precise, living model of the ‘business of the business’. These decision models are the heart of any systemized approach, and when used to drive systems development, can deliver significant improvements in development performance.

Who is better to develop and own these models than the business analyst – who in fact would have the skills to do so? When the business analyst plays in this space, there is a subtle transition of knowledge and eventually, authority – the business analyst who ‘owns’ the decision model increasingly becomes the subject matter expert with respect to the subject covered by the model.

And there is more. According to the ESI[9] report:

“Business analysts will step up their game with increased focus on graphical modeling, cost estimates, risk analysis and other measurements that quantifiably prove RMD’s value to the organization”

Decision modeling encompasses:

1. Contract and policy definition (auditable, flexible, efficient - capable of handling high complexity);

2. Contract and policy evaluation ( “what ifs” for assessing both operational impacts and strategic alternatives);

3. Deployment (as operational code to automate day-to-day decision making).

Definition and evaluation empower the business analyst to “step up” as the ESI report suggests. Automated deployment ‘without fingerprints’ is an added bonus – and a huge added bonus at that.

Here are some real world examples where contracts or business policies have been captured as decision models and used for ‘what if’ evaluations using historical and/or forward looking data as the case requires:

1. A telco contract for a company incurring $300,000 of charges/month. Use the model to:

   • Verify hundreds of thousands of charges spread across thousands of staff monthly;

   • Assess the impact of organizational changes (e.g. increasing cell phone use vs fixed lines) on the charges;

   • Actively manage the use of plan options each month for each individual;

   • Compare competitor offerings;

   • Evaluate proposed contract conditions during renewal negotiations.

2. A costing model for a rail operator including 300 individual customer contracts delivering $500m annual revenue across thousands of routing segments:

   • Model new pricing schemes to replace one-off or outdated contracts;

   • Assess the impact on these on individual contracts using operational data;

   • Support new customer negotiations;

   • Assess the impact of changes in freight volumes, types, and routes;

   • Optimize freight aggregation and movements.

3. A clinical case management pathway:

   • Assess how changes in pathway decisions would affect individuals in the pathway;

   • Assess the likely increase or decrease in doctor visits and other follow on costs;

   • Test the pathway against unusual or hypothetical cases.

4. An insurer’s entire underwriting policy manual for mortgage insurance:

   • Underwriting policy captured, tested, and wrapped in distributable components;

   • Assess the profile of partner mortgages in terms of underwriting revenue and acceptance rate;

   • Distributed to banks for inclusion in real-time lending processes.

Conclusion

In ‘Requirements and the Beast of Complexity’ we described a world where the core artefacts that define the ‘business of the business’ are captured as decision models. When these decision models are tested and shown to be correct, complete, and consistent, they represent the business itself in model form – its legal environment, its internal policies, its products and services, and its contracts. The models can be published directly to business users for audit and reference purposes. And they can be published to systems in the form of computer code, where they form definitive core components for any system in which they participate, reducing systems development cost, time and risk, and at the same time increasing business and systems alignment and overall business agility.

And now we have further extended the value of these models. By explicitly automating contracts and business policy, we can build ‘what if’ workbenches for empirical evaluation of changes in contract or policy terms and conditions; of changes in operating conditions; of changes in market conditions; and of new and changed market offerings.

We think that decision management and its derivative approaches will help ‘tame the beast of complexity’. And we think that the global community of business analysts will be the ones most likely to drive it.

Author: Mark Norton has more than 30 years development experience, mostly on enterprise scale, mission critical systems in finance, insurance, government and health administration. In 2001 Mark established Idiom Ltd. to develop and market tools and techniques in support of the decisioning concept. Through joint project participation with integration partners, these tools and techniques have been personally developed and tested on dozens of projects to deliver the pragmatic and conceptually sound decision management approaches described in this article.
Contact: +64 21 434669
[email protected]
www.idiomsoftware.com

¹ Requirements and the Beast of Complexity, 5th May 2010
² http://www.esi-intl.com/Corporate-Links/Newsroom/News-Releases-2011/top-10-ba-trends-in-2011.aspx?ExtSrc=280
³ http://www.theiiba.org/AM/Template.cfm?Section=Body_of_Knowledge
⁴ Worldwide Decision Management Software 2010–2014 Forecast: A Fast-Growing Opportunity to Drive the Intelligent Economy, http://www.idc.com/research/viewdocsynopsis.jsp?containerId=226244&sectionId=null&elementId=null&pageType=SYNOPSIS
⁵ http://en.wikipedia.org/wiki/Requirement
⁶ http://en.wikipedia.org/wiki/Policy
⁷ http://www.thefreedictionary.com/policy
⁸ For a definition and extended discussion about decision models see http://www.idiomsoftware.com/pdfs/IDIOM%20Decisioning.pdf and Requirements and the Beast of Complexity
⁹ http://www.esi-intl.com/Corporate-Links/Newsroom/News-Releases-2011/top-10-ba-trends-in-2011.aspx?ExtSrc=280