Introduction

In the first article of this series, I discussed the current interest in Business Architecture that has been brewing in the last little while and also discussed some of the frameworks that professionals have been looking at for guidance and inspiration.  The first article was intended to provide an overview of the field, and it introduced an overarching set of concepts that we in Process Renewal Group have been successfully using to classify and categorize issues of concern.

The Process Renewal Group model, which is the origin of the BPTrends methodology, was originally formulated in the mid-nineties and has undergone continuing evolution for twenty years to remain a modern way of designing a business.  It incorporates the best practice of a number of approaches combined with other ideas that have stood the test of time as well as some of our own innovations.  Within the past year it has been subject to a significant update to connect traditional and new ideas into a comprehensive Business Architecture framework and methodology, as depicted in the figure below.  The diagram shows the main logic of the discovery and design process.

In future articles in this series I will examine all of these areas plus some others not apparent in the diagram itself, but before I get specific on any one of them we have to look at the question of scope and inclusion of the Business Architecture itself.  This is not such an easy question as it may first appear.

Will we include an entire corporation or a whole government?  Will we only look at a small focussed organizational unit or group?  Will we go outside the bounds of an organization to include others?  It is critical that everyone agrees on what is the scope of inclusion and where is the line of exclusion of the effort and the knowledge to be captured and sustained or the effort is doomed.  What about a Value Chain approach rather than an organizational one, and which value chains are in or out if there are more than one?  There are also many ways to look at value chains.  We will sort through all of these thorny choices in this article.

The Organizational Question

An organization sits within an environmental context outside its direct control.  An organization may have many component organizations, each of which typically manages its own work.  One choice of the business architecture scope-of-inclusion is to use a structural partitioning of the organization.  If this approach is chosen, the question is "What is the scope of 'organization' in play?"

The Business Process Manifesto defines organization as "an entity that pursues collective goals, exercises control over its own performance, has a boundary separating it from its environment, and includes all defined entities participating."

The first question is whether or not all branches of the organization chart will be included in the architectural analysis or change program.  It is possible to take on a whole corporation or to exclude some parts — perhaps only some divisions or departments will participate.  For example, we could choose to architect the core business units but not the IT department.  Or, alternately, we could do the inverse whereby only the IT department is tackled and the rest of the business is seen as a set of external customers, suppliers, and other 'external' stakeholders.

We have conducted several such efforts for the IT department to get its act together to be better able to serve the rest of the company when suffering tremendous credibility issues due to historical perception of non-performance.  We have also taken on the Real Estate division of a major bank since it was well defined, had clear boundaries, and managed as a shared service to all other bank lines of business.  In each case, having done this, the department then provided inspiration for the rest of the business once its performance picked up and its credibility was re-established. So a structural partitioning is one possibility.

The risk with this approach, however, is that we may easily miss the mark by architecting and designing aspects of the business that are integral with other units in terms of value creation and that the true end-to-end is not optimized.  The challenge is that the more fine grained the organizational scope choice, the more likely it is to suboptimize and create siloed solutions that do not serve the value proposition of the larger organization affected. 

The corollary is that the less granular and broadly covered in scope, the more complex, time consuming, and political the architecture and business design becomes.  In this scenario, conflicts easily arise around the required cultural changes associated with managing a new business model, and this can easily sink the effort if we are not careful.  One common criticism of the capability perspective of business architecture is that it often derives functional capabilities rather than cross-functional ones based on functional needs of specific organizational units that are only a part of the overall value creation stream.  This can be mitigated by taking a cross-functional baseline provided by a Value Chain point-of-view as described in the remainder of this article.  Finding the right balance can be tricky.

The Value Chain Argument

Another way to segment and partition the architecture is to take an outside-in, value creation perspective that tackles the organization's value chains.  This view strives to ensure that everything done is focussed on the ultimate value created for customers, owners, and other key outside stakeholders, regardless of internal organizational structure.  As a matter of fact, the organizational structure itself may be on the table for change to improve the value creation abilities of the organization in scope.  In modern businesses this approach is outcome-focussed and requires a strong end-to-end orientation.

Organizations will struggle even to define what is a value chain.  Some will want to use geographical factors, such as regions of the world or countries, as the basis for differentiating value chains.  The argument from each area is typically that 'we are different'.  Their desire is to hang onto as much local control as possible, and their fear is that they will lose the self-determination they feel is important to them, overlooking the benefits of having as much sharing of approach as is possible. 

Others will choose to differentiate value chains based on the channels to market they use.  Often they will see the direct business relationship they have with customers as being quite different from relationships that are intermediated by partners and distributors, who will themselves get to the customers directly.  Web channels are seen quite differently from in-store or branch office ways of working. 

Size of customer also often results in different treatment, following the classic Pareto principa, whereby 20% (or even less) of your customers provide 80% of your revenue and so are considered a separate value chain.  Many organizations are still trapped in the quagmire of seeing each product line as its own value chain, resulting in overlapping relationship management issues from each, with the tendency to hang onto products and services long after they are no longer of optimum value to the customer.  They are slow to change or even terminate themselves when their time is up.  Large banks and insurance organizations have historically been guilty of this and in many places today have not solved the inertia and cultural problem because of it.

Our preference is to take a value-creation approach based on the chosen markets that the business is pursuing.  So rather than having mortgages separate from personal account services from investments, we would prefer to see one value chain for consumer banking and possibly another for business banking.  Each of these could have a different value proposition and would be measured somewhat differently.

One company — one value chain

In many large corporations or government agencies, multiple value chains are in place.  But let's start with the simplest scenario.  That is the case when the entire business has a clear market with a defined set of products and services for that market.

This can be illustrated by a local Thai restaurant that makes and serves Thai dishes in response to on-site diners, either individuals, groups, or families.  It also delivers food to addresses within a defined delivery territory.  We would classify the value chain 'Serve Diners' as being the only value chain this restaurant has, despite having two means of getting meals to customers.  This value chain would comprise everything the restaurant does, including purchasing raw materials, creating recipes, hiring staff, and establishing weekly plans, to name a few things.  The organization is represented wholly by its one and only value chain, which has a clear value proposition for its customers in its market.

One company — multiple distinct value chains

Let's expand our thinking to an organization that has multiple diversified lines of business.  A popular example is Michelin Group, which has several separate businesses under its purview.   It makes tires, produces restaurant and hotel guides, and has a digital mapping business, as well as other ventures.

Clearly, each of these provides a different suite of products and services for a different market and represents a different value chain.  Each is most likely operated by a different division within the corporate organization chart.  The 'Produce Tires' value chain is remarkably different from the 'Produce Guides' value chain.

This one is easy to appreciate.  Trying to have one Business Architecture covering both value chains is unrealistic, so two separate architectures is more appealing.  There may be some internal shared services, but I will come to that a bit later.

One company — multiple overlapping value chains

What about a company that develops and sells software and provides consulting service apropos the application of that software to the market?  On the one hand, it is tempting to go with two value chains.  But it also true that there may be one sales process or team that will call on the same client and sell both in the same proposal.

Now it is a bit more complex because we want the two business services to apply their own best practices but avoid conflicts between the two teams.  Our preference here would be to have two value chains with one shared sales service serving the best combination for the long term interest of supporting the corporate strategy.

This could also be determined to be one value chain since it serves the same customer and markets. If the professional services are very close to the software itself then one chain is appealing.  If they are not much related and we are essentially selling and delivering unrelated consulting, then two chains would be appropriate.

A good example of this is one of the world's largest air travel services providers.  There is a distinct value chain for taking airline, hotel, and train capacity data, seat by seat and room by room, and making it available to its over six hundred customer airlines, hotels, travel agencies — and booking spaces and maintaining real-time updates to customers making such bookings.  In addition, the company also operates an IT outsourcing service for many of the same airlines for their 'internal' IT departments.  These are distinct value chains but in the same corporate structure of the company.

One company — internal value chains

As mentioned earlier regarding organizations that could be excluded from the architectural scope, there are often one or more sets of value-creating activities that almost stand alone, focussed on their internal customers and operating as a shared service.  This is true of services such as 'Provide IT Services' or 'Support HR Needs' or 'Engineer Facilities and Equipment'.

Often these services correlate closely to the organization units that are the internal lead players in specific professional services, and multiple other internal processes are supported by them.  This provides professional management of the resources and professional practices (i.e., processes) required to assure the core value chain(s) remain most effective.  Their customers are internal to the organization, and it can work well so long as these supporting value chains see the rest of the work being performed as serving their customers, who have their own customers, and they are focussed on making their customers' customers successful. 

The supporting value chain incumbents must resist the temptation of becoming internally focussed on their own professional work and becoming dogmatic due to having a perceived monopoly internally.  As a shared service, it is useful to think about each of these groups responsible for the support value chain as a company in its own right that manages itself as a business with a full set of stakeholders, many of which are internal.

A good example of this type of support value chain could be 'Acquire Goods and Services', which would cover all of the activities required from first identification of needs to the end result of the right goods or services in place.  This could be confused with the Organizational view of the Purchasing department architecture.  The difference is that the Value Chain view will include more than what is occurring just in the Organizational view.

Multiple companies — one value chain

We are starting to see a plethora of innovative business model examples whereby companies and individuals collaborate to provide new and exciting offerings to the marketplace by extending their value chains into and across work performed in multiple independent legal entities.  This can deliver a value-added service not possible by any individual entity alone.

There are many good examples of exploiting an opportunity for new services not available previously, as shown by organizations such as UBER and Airbnb.  In this view the value chain involves several stakeholders as part of service delivery, with the one value proposition, as seen by customers, requiring an architecture for multiple players working together in one logical chain of activities. 

Process Renewal Group has also been involved with the design and architecture of end-to-end value chains that span multiple government agencies across more than one level of government — and sometimes in combination with the private sector — whereby all parties must be involved in the work if it is to be effective for the citizens and other participants in the economy of the jurisdiction.  Led by the government of one of the Canadian provinces we have helped build cross-organization value chains involving the transit agency, municipalities, and transit operating companies to optimize transit ridership.  We have facilitated numerous stakeholders from insurance companies, police agencies, the justice ministry, various cities, and special interest groups who got together to take on the focused mandate of architecting the capability to improve road safety in the province.  We have coordinated the design of a peer-to-peer online dispute service to provide improved access to justice, avoid legal adjudication, and free up court backlogs.  This last example assured a common approach and online service for resolution of civil disputes led by the justice department.  It spans multiple organizations and affects almost twenty agencies that are party to a wide variety of disputes.

A Tricky Yet Critical Choice

Sometimes the choice of the value chains to be the scope of the architecture work is fairly obvious.  Sometimes it can be tricky and possibly require a political negotiation.  It is essential that you have a good idea of where you are trying to take the organization in order to choose.

Selecting something too small may not be sufficient to achieve your aims.  Sometimes taking too big a challenge may be premature for the organization's culture and readiness.  There are many pros and cons associated with each choice, and careful discussion and gaining of commitment with leadership for the choice is essential.

No matter what the choice, this part of the architecture effort needs to happen early to get everyone on the same page and to be able to negotiate and commit the time and appropriate resources for the needed effort.  In our experience, many critical issues get raised even this early, and their resolution up front will guide the rest of the architecture work.  By addressing them here you will avoid messy re-negotiation later, when you are knee-deep in more detailed aspects and when it is more difficult, costly, emotional, and political.

Future Articles

Future articles in this series will further deconstruct the components of the PRG/BPTA model and delve into its various domains.  Stakeholder Analysis and Business Strategy are next up.

That's the way I see it.

# # #