Business Software Platforms are not Strategic

I want to share an idea that occurred to me and some of my colleagues, Dave Langer in particular, that was triggered during the work in building our business system architecture to enable our S+S corporate strategy, which is that reusable Business Software Platforms are not Strategic. In fact, if anything they are the opposite of Strategic.

Note: Before you read further, I recommend glancing at the Glossary of Terms at the end of this post to brief yourself on the definitions of Business Strategy, Business Process and Software Platform.

Essentially, the idea is a simple 3-step process which starts with Business Strategy and ends with candidate logical descriptions of Business Software Platform that, interestingly, are deliberately not directly enabling Business Strategy. Here’s the process:

Step 1. Identify the Business Strategy

A business must identify what its Business Strategy is. With methods like Michael Porter’s “Five Forces Concept” and/or Jim Collins’ Hedgehog Analysis, a business can identify its Business Strategy.

Porter’s Five Forces Concept		Collins’ Hedgehog Concept

One output from this activity is a set of Business Strategy Statements where each Business Strategy Statement includes Objective, Scope and Competitive Advantage elements. Here’s a link to HBS article describing this in detail.

Step 2. Identify Context Business Processes

Using Business Processes, often in the format of a Business Process Categorization model, identify Business Processes that do not directly enable Business Strategy. There are many methods out there to help do this such as Geoffrey Moore’s Core versus Context, and your common Enterprise Architecture mapping Business Process to Business Strategy activity.

In the Core versus Context method, I refer to the “Core versus Context” concept developed by Geoffrey Moore. In Moore’s book 'Living on the Fault Line' , Moore described a method for identifying Core and Context Business Processes and Business Process Activities, "For core activities, the goal is to differentiate as much as possible on any variable that impacts customers' purchase decisions and to assign one's best resources to that challenge. By contrast, every other activity in the corporation is not core, it is context. And the winning approach to context tasks is not to differentiate but rather to execute them effectively and efficiently in as standardized a manner as possible."

In the Business Process to Business Strategy Analysis method, one analyzes the Business Strategy Statements and associates Business Processes that directly relate to Business Strategy Statements. I add a little twist here and assert that Business Processes that do not directly enable Business Strategy are considered Context Business Processes.

The assumption at this point is that Business Processes that are strategic should expect change. Those that are not strategic, therefore Context Business Processes, should expect less change. In fact, according to Moore, Context Business Processes should be standardized.

Step 3. Identify Candidate Platforms

We now need to identify Business Software Platforms. There are number of methods out there to help logically group Functions by Information entities to identify candidate Software Platforms. Methods such as Affinity Analysis, Yourdon and Constantine’s Functional Cohesion, and Coplien’s Scope, Commonality, Variability Analysis. All three have a common goal when using Business Process and Data as factors to be analyzed which is to mathematically identify logical groupings of processes based on their relationship to data.

The only addition I make to these methods is to only focus on Context Business Processes in the analysis. The assumption I make is that Software Platforms, by their very nature provide reusable/shared automation of business processes and data, represent standardized processes and data. By focusing on Context Business Processes, we simply realize these as Business Software Platforms as a result of the analysis.

Core Business Processes are left to be supported/automated by the more agile Applications because Applications are not specifically designed to be shared or reused. Applications provide time-to-market agility to the business.

Summary - Nothing new just putting together known concepts

This is an interesting post for me because I haven’t introduced any new concepts to suggest this new process idea for maturing the Enterprise Architecture discipline. Instead, I pulled together known concepts from business and software engineering domain experts to form a simple 3-step process for identifying Business Software Platforms.

I’m an Enterprise Architect so I also wonder if this idea can be broadened beyond S+S to across the Microsoft’s enterprise and, potentially, for any enterprise so I thought I’d publish this idea and share it. Thoughts?

By the way, I realize that this simple process is far from easy as there are lots of prerequisites to complete it such as; Defined Business Strategies exist, an inventory of business processes, an inventory of Business Data, and a mapping from Business Process to Business Data. Sorry if I’ve presented it in a way that appears way too easy. :)

Glossary of Terms: