Tracing Corporate Strategy to a Line of Code

One of the issues high on the agenda of many CIOs is to align IT efforts with the company’s strategic goals. But how you do trace a line of code back to the strategic goal that caused it to be written? If we’re able to do this then, and only then, can it be said that IT is aligned with the business strategy.

In most organisations the strategy usually results in changes to the existing way of doing business, be it for new products or services or for efficiency changes. This will result in an assessment of the processes within the areas affected by the strategy, in order to facilitate the changes required to support the individual goals.

But how do we take the output from the strategic process assessment projects and fit them together with the systems world in a manner that is traceable?

The answer to this question is all in the definitions. The whole thing appears to be complex, as there are many methods used to perform Business Process Analysis. We find Value Chains, BPMN, Swim lanes, Business Analysis with UML, and tool based methods to name but a few. We also find a myriad of methods used by the systems people UML, UML hybrids, IDEF IE, tool based and home grown, etc.

How do you fit this diversity together in a meaningful way?

The critical point is to establish a link that is common to all approaches as well as common to both worlds. To do this let’s start with the Business Process Analysis world first. In the Business Process Analysis world we look at business activities or “what the business does” without any mention of technology in other words, business processes as the name implies. Let’s look at some definitions of a business process:

A definition can be found in Michael Hammer and James Champy’s book Reengineering the Corporation: A Manifesto for Business Revolution (Harper Business 1993):

“A collection of activities that takes one or more kinds of input and creates an output that is of value to the customer.”

And from one of my favourite books on Process Management by Rummler & Brache, Improving Performance: How to manage the white space on the organizational chart:

“A business process is a series of steps designed to produce a product or service.”

These and many other definitions have many things in common but for our purposes there are three important concepts to grasp: 

• Produce something of value (output, product, or service)
• Take something and change it to create the value
• Have a sequence to follow

Let me elaborate on the series of steps or sequences. The sequence of events is a set of predefined rules. These rules are commonly referred to as Business Rules.
Nothing earth shattering here, this is all old hat in the process world.

We need to extend the definition slightly to ensure we find the common unit we are looking for. We need to define the lowest level process. I use the term ‘Elementary Process’. This was a term used in the Information Engineering Methodology by James Martin. I like the term because it says that your process is now at a level that cannot be broken down any further.

So what is an Elementary Process?

An Elementary Process is defined roughly as follows:

An Elementary Process is the lowest level of work that can be performed with business meaning.

The International Function Point User Group (IFPUG) defines it as follows:

“An elementary process is the smallest unit of activity that is meaningful to the user(s). It must be self-contained and leave the business of the application being counted in a consistent state:”

This fits with the definitions above as the business meaning can be translated into business value and the users equate to business.

This implies any further decomposition of the process and we lose the business meaning. (A more lengthy definition can be found in my book “Aligning Business Analysis” Chapter Four “The Lowest Level of Business Process”)

Let’s add the Elementary Process definition to the definition “A business process is a series of steps designed to produce a product or service”.

So if we combine these two definitions we get:

Elementary Process = the smallest business process = is a series of steps designed to produce a result of value to the business.

The significance of the Elementary Process will become evident later.

No matter what methods are used for process analysis they all should be capable of identifying the elementary processes. If they are being used for business process improvement, they should establish the elementary processes. By definition these are the processes where the actual work is being done in the business and so these will be the processes affected by change. In order to perform Business Process Improvement, the elementary processes that are new or need to be changed need to be documented.

So we have a set of elementary processes of which some will change and others will need to be created. Often change will entail changing the Business Rules. For example, if a business needs to lower the number of bad debts, they will need to improve or change the Business Rules they apply in the process “check client credit worthiness”.

So if no changes are required to systems, the analysis process would end here and the changes would be rolled out manually.

But often the changes require system changes. This is where the unit of commonality will be required. As we change from the process world to the systems world, how can we take the analysis we have done and trace it to a line of code?

In most organisations the back bone of the systems world is the Use Case.
(If you are not using Use Cases then read whatever you are using to specs program instead of Use Case).

Let’s have a look at the definition of a Use Case:

“A Use Case is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor”

This is found in both of the following books:

• Kurt Bittner, Ian Spence (2002). Use Case Modeling. Addison Wesley Professional, 2-3. ISBN 0-201-70913-9. Date Published Aug 2002
• The Unified Modeling Language User Guide. Grady Booch James Rumbaugh Ivar Jacobson Addison-Wesley. Date Published Oct 1998

But look at our definition for the process earlier:

Elementary process = the smallest business process = is a series of steps designed to produce a result of value to the business

If we compare the two definitions we find some interesting correlation. This can be seen in the following table:

It becomes evident that the definitions of the Use Case is the same as the definition of the smallest (lowest level) process but with the introduction of the word system.

Based on this, we appear to have found the unit of commonality between the business process world and the systems world.

So what we have is a process block on a business model that equates to a Use Case. What does that mean in our goal of traceability?

In the process world, the business rules are the series of steps. So what do these business rules become in the Use Case world? They must equate to sequences of events in the Use Case.

In the Use Case world the sequence of events are referred to as a Scenario which are found in the Use Case Description. These Scenarios will define the Use Case flow. So Business Rules will form the foundation of the Use Case Scenarios. I say the foundation as the Use Case Scenarios will need to be expanded to support the technology requirement of the system and reflect the user’s interaction with the system.

These Scenarios within the Use Case description will become code in a program.

All of this can now be summed up by the following diagram:
 

It stands to reason the reverse traceability is true:
 

So by finding the link between the Business Process world and the Systems, world we can trace from a line of code back to the strategic goal that gave rise to that line of code.

When users get approval for a system, IT asks what do you want? That’s like asking a four year old standing in a toy store the same question. Often features asked for are nothing more than “nice to haves” that actually have no real business value. These “nice to haves” can be reduced dramatically now, as they will probably have no link to a strategic goal and IT will only put effort into things that are directly linked to a business goal.

This is very powerful, as the CIO can show that every line of code and the system to which they belong are traceable to the high level business strategy.
This can have a dramatic effect, considering that in a study by Standish Group’s Jim Johnson, it was discovered that 45% of features in the software were never used, while another 19% were rarely used. 

That 45% can only be put down to “nice to haves” that were not in support of the company’s goals and strategies. Imagine reducing the whole development effort by say 40% and the remaining effort only being in direct support of the company’s goals. This will have a very dramatic positive effect on the Business IT relationship.

The CIO is now in a position to prove the value of the efforts his department or division is doing in support of the business by adding real business value.

Author: Robin Grace, Principal Consultant BA Practice for IndigoCube in South Africa.
Robin has been involved with Businesses Analysis for nearly twenty years and has used a variety of Methodologies, Modelling techniques, and Tools. He is well known for his presentations on various aspects of Business Analysis.
Robin recently published a book titled “Aligning Business Analysis, Assessing Business Analysis from a Results Focus”.