Lightning Talk - Aligning Architecture with Strategy

7th of September 2020

The accompanying slide deck can be found here.

This talk is aimed at clarifying that corporate strategy is not exclusively used at C-level management. Strategy trickles down from this decision-making level to all nooks and crannies of the organization. It should permeate from all decisions and solutions being rolled out. As such, it becomes a context for the architects to design and evaluate their solutions. Although it is clear that strategy is important to the job of enterprise architect, its objectives and goals form a set of requirements that other architects (business, solution, application…) should take into account when positing the context and framework that shapes the development of initiatives. The complete set of requirements are the scales on which the architect weighs the pros and cons of any solution.

The listing and formalization of the strategies set out by the various decision-making levels within the organization can be put to paper in various ways:

  • The Business Motivation Model from OMG
  • The OKR approach from Google
  • The Business Model Canvas of Osterwalder
  • The Balanced Scorecard of Kaplan and Norton
  • The OGSM for strategic planning
  • …

This list can be somewhat overwhelming, and it is hard for those just starting to dip their toes in the strategic waters to grasp the intricate complexities that can be planned. At its core, the business strategy of an enterprise is a definition of the enterprise’s position about what activities it will pursue and what activities it will not pursue, based on the trade-offs incurred from those choices and the fit of the chosen activities towards each other. It will focus on a value proposition, of which the most basic forms were coined by Treacy and Wiersema in their seminal work “The Discipline of Market Leaders” as the following choices:

Corporate Strategies (Treacy & Wiersema)

Applying this to service design we can differentiate between these strategies as they manifest themselves in the various choices that the architects and designers make when determining our service domains. Suppose we have a straightforward value chain (as defined by Michael Porter):

Porter Value Chain

These steps in the value chain process can be translated one-to-one into resulting service domains and is subject to change when applying the strategies chosen by the organization in which these services are to be developed. The standard service would look something like this:

Service Chain Representation

When applying the Operational Excellence approach, the service design will be influenced by the need for cutting costs and applying standardization and/or reuse as much as possible to reduce the maintenance cost of existing services and development cost of new services. Other possibilities for cost reduction are to outsource certain services so that we do not need to develop them ourselves (for example a public Google API to check the weather or a paid for Graydon API for credit history checks), or to acquire Commercial Off-The-Shelf (COTS) components to utilize in our service chain.

Service Chain Representation for Operational Excellence

Customer Intimacy Initiatives take the service design into the realm of maximizing the differentiation of the value chain. We aim to design the results coming from the services in such a way as to accommodate a wide range of customization as if tailored for the consumer. A number of options to this effect are shown in the diagram below. We have added a decorator service after the standard production service in order to match the outcome to what the customer desires. This service orchestrates a number of different decorator services (adding a male or female hat to the product or customizing the accompanying shoes). Another possibility is shown in the customer service where we have context-based routing to send the customer to the proper linguistic channel.

Service Chain Representation for Customer Intimacy

The third strategic flavor, Product Leadership, focuses on being able to modify and extend our value chain with different technologies and options. When living on the cutting edge of your market, the need to be able to gear up and adopt new possibilities and technologies translates into the services needed to make this change possible. We get API gateways to send requests to different versions of the same service, each implemented with different technologies. The gateway can also be used to address the same service via different channels each with their proper SLA and response criteria. RPA bots that alleviate the pressure on our customer service for standard requests is also a valid way to make your value chain more malleable and manageable.

Service Chain Representation for Product Leadership

Keynote SOA EA Business Architecture