Search Results for: business model

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.

 

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:

Term	Definition	Source
Competitive Business Strategy (aka Business strategy)	Business Strategy refers to how a company competes in a particular business (note: overall strategy for diversified firms is referred to as corporate strategy). Competitive strategy is concerned with how a company can gain a competitive advantage through a distinctive way of competing. Competitive Business Strategy refers to the aggregated strategies of single business firm or a business unit that incorporates either cost leadership, differentiation or focus in order to achieve a sustainable competitive advantage and long-term success in its chosen arenas or industries. The essence of strategy is choosing a unique and valuable position rooted in systems of activities that are much more difficult to match.	Michael Porter, Harvard Business School
Business Process	A business process is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. It often can be visualized with a flowchart as a sequence of activities.	Harvard Business School
	A business process is a series of interrelated activities that convert inputs into results (outputs); processes consume resources and require standards for repeatable performance; processes respond to control systems that direct the quality, rate, and cost of performance.	APQC
Business Process Categorization	A reference framework for categorizing all the business activities used by an enterprise involved in delivering products and services. This is done through the definition of each area of business activity, in the form of process components or Process Elements that can be decomposed to expose progressive detail. These process elements can then be positioned within a model to show organizational, functional and other relationships, and can be combined within process flows that trace activity paths through the business. Business Process Categorization can serve as the blueprint for standardizing and categorizing business activities (or process elements) that will help set direction.	TMForum.org
Business Software Platform	Standardized business software engineered for reuse. Often Business Software Platforms are responsible for mechanizing standard business processes and managing standard data. Note: I couldn’t easily find a non-bias definition so I researched and aggregated definitions from several credible sources, then simplified to avoid too much criticism while maintaining the sources intent.	Gabriel Morgan 🙂

We all agree now that Adoption is key for Enterprise Architects. And the trick to adoption is resonating with those that make change and influence them to make the change that is best for the enterprise. In a previous blog post, I introduced the Solution Model concept. In this post, I want to talk about the concept of the Traceability Critical Path, which is the portion of the Solution Model necessary to trace from Strategy to Code.

Support for Solution Architects is good

As Solution Architects, we have the ability to understand a business problem and be able to derive a software solution to meet the business problem. We have lots of process tools to help us such as software development lifecycles like Microsoft Solutions Framework (MSF), Extreme Programming (XP), Rational Unified Process (RUP) to describe who does what and when. We have methods such as Object-oriented Design (OOD) and Attribute-based Design (ADD) to help use design software components. We have vibrant software engineering organizations and user groups like IEEE, OASIS and Software Engineering Institute (SEI) to leverage. We have knowledge bases to leverage such as the Software Engineering Book of Knowledge (SWEBOK). We have system design tools such as Visual Studio to design, develop and deploy software. Pretty good.

Support for Enterprise Architects is good

As Enterprise Architects, we have the ability to understand all of our business organizations and derive IT architecture for the entire enterprise. We have lots of tools to help us such as Enterprise Architecture Frameworks (EAF) like Gartner’s EAF, TOGAF, Federal Enterprise Architecture (FEAF). We have industry organizations and user groups to leverage such as ISACA/COBiT, ITIL and TMForum. We have methods to identify and focus on individual business pain points like MSBA’s Business Capability Analysis and Six Sigma/Lean to avoid analysis paralysis. We have tools to help manage enterprise information such as business processes, project and application portfolios from Microsoft, Troux, MetaStorm and Sparx Systems.

We need a way to connect Enterprise Architecture to Solution Architecture

So, here’s the problem, the outputs of all the tools and methods need to be connected so that we can trace from “strategy to code”. You may have heard other catch phrases trying to say the same thing such as “connect planning and implementation”, “deliver to the plan” or the phrase “help an organization determine the right things to do and ensure that project teams do them right”. Isn’t it funny how there are so many catch phrases out there trying to describe the concept of Model Traceability?

Model Traceability connects Enterprise Architecture and Solution Architecture

My team thinks that Model Traceability is very important and we have invested in this area to help us make sense of all the tools and methods out there in an effort to streamline what’s important so that we can honestly and justifiably say we know what are the right things to do and we can trace them to project teams and show how they are doing them right. During this effort, we have discovered some very interesting things.

We evaluate the tools and methods and identify what concepts they produce or mange. We then evaluate these concepts and determine what value they bring to their stakeholders; concepts such as Business Strategy, Business Capability, Use Case, Business Process Activity, Application Interface, System, Code, Test Case. We then determine how they are associated to each other. For example, A Business Process composes Business Process Activities. Automated Business Process Activities use Applications.

Without the metamodel, we might have a mess like the diagram below illustrates.

Disclaimer Note: The diagram above is not representative of my team’s metamodel in order protect Microsoft IP. I deliberately used inappropriate elements, removed several elements, removed all associations between the elements, and spatially organized the elements somewhat randomly.

There are lots of concepts involved, we need the Traceability Critical Path to understand the explicit connection

Our goal is to get to what we are calling the Traceability Critical Path. The Traceability Critical Path (TCP) is the set of lowest-level elements in the metamodel that have an explicit association with each other that are necessary to trace from Strategy to Code. [I know, bad acronym choice. We might later rename it to avoid confusion.] Identifying the TCP elements and how they relate is the goal of this work. Then, connecting the rest of the elements to the TCP elements to understand how they relate.

Along the journey of defining the TCP, we discovered some interesting characteristics of the metamodel elements. We found it useful to differentiate between element types. Here are some examples:

• Traceability Critical Path elements. Elements that have a direct or concrete relationship from planning activities
• Enabling elements. Elements are really only methods or tools to derive critical elements.
• Temporal elements. Elements that act as placeholders for required elements but are needed at a later time in a process.
• Discipline-specific elements. Elements that are useful only to certain disciplines but are somewhat meaningless to others.
• Associations elements. Elements that describe how elements are related/associated with each other.

We had some interesting observations made along the way worth sharing

Along our journey we made a few interesting observations that maybe, at some point, I’ll dig into later because each could take a while to explain. But for now, I’ll just jot them down to share:

1. Complimentary Information Model. In addition to the metamodel, we created an information model to describe the concepts the elements represent because there are times when identifying individual elements, the resulting element’s names don’t easily resemble the original concept being evaluated and causes a bit of confusion. We required an information model to describe aggregations, compositions, generalizations and subtypes to keep the metamodel meaningful by the different audiences.

2. Enabling and Temporal Elements and Abstraction relationship. We observed during the exercise of building our metamodel that the relationship between the Enabling Elements and degree of abstraction. We noticed that many of the Enabling and the majority of the Temporal elements tend to exist at higher abstractions and the TCP elements tend to fall in the lower abstraction. This trend is illustrated in the graph below.

3. Gaps in enterprise planning concepts. When analyzing the trend data, we found gaps in our scatter graph. We are wondering how to explain this and what to do with this observation, but we are leaning to spend a bit of time to apply some engineering rigor and define enterprise planning concepts in more detail. The types of concepts are those that describe Business Strategy and Business Model as examples.

Summary – The TCP brings very interesting benefits

Having the metamodel and clear identification of the TCP within it, we get a lot of benefits such as:

1. Objectivity. Ability to put the tools, methods and concepts from several disciplines into perspective and help us get to the crux of their value proposition to enabling elements in the TCP.
2. Impact Analysis. Ability to traverse the model and do Impact Analysis from any element of concern. For example, one can identify which applications are involved to enable Scenarios. Or, one could identify which System Features impact Customers or Business Partner and so on.
3. Role Clarity. Ability to understand the disciplines and roles that typically create elements fit into the planning and implementation activities.

I would like to share our metamodel, complete with the TCP, as well as the process used to build it. But, to be fair, this is a team effort and I want to give credit where credit is due as well as respect the fact that this is the property of Microsoft that I don’t have approval to publish yet. If you’d like to see our metamodel, let me know and I’ll bring your request to my team.