Categories
00 - Next-Gen Architecture, Culture & Processes

From Enterprise Architecture as a Strategy to Business Infrastructure as a Platform – Part I of II

This is about you: How you can ensure that you establish a good, long term strategy for your business. How that helps to build a solid foundation of business execution and how to invest in the right level of standardisation and underlying Enterprise and IT architecture.

We introduce Enterprise as a Strategy and add insights in whether and what to consider to enable your individual Enterprise Architecture on state of the art technology.”

The issue with Business and IT Leadership speaking different languages

A framework to build confidence

As stated in my previous article in the section about Architecture, Culture & Processes, one key focus is to find and present tools that foster a strategic alignment from leadership to execution and from business strategy to organisational execution.

I see that precise alignment to be a  key ingredient in a matching market offering and to streamline business efforts with IT strategy at all layers.

You will find that in this part, I am mainly giving a condensed and opinionated introduction in the valuable book  “Enterprise as a Strategy – Creating a foundation for business execution” (Jeanne W. Ross, Peter Weill and David C. Robertson) published at Harvard Business School Press.

In part II, we will build on top of the foundation described in this article, which will help you to prepare for a sound digitalisation strategy. And I’ll advise as to how IT can create a unique and best fitting cloud and edge setup for your business case.

Back to Ross, Weill and Robertson and their book: The core problem they have identified is that business and its leadership live under different constraints, speak different languages and have different thought models. his fits our observation, that planning, forecasting and strategy development happens in many organisations disjunct from considerations within IT.

In this respect, I would like  to provide you with a framework that I use to map my understanding of things such as a “Digitalisation Strategy”.

Many organisations are stuck in meaningless initiatives

With some years of consulting background or the like, most of us have seen organisations that are stuck in initiatives that seem meaningless. It might be that an organization cannot answer a strategic change on the market place, because the back office is freezed in status quo. Or maybe due to a data center consolidation oran IT  outsourcing is taking place.
Or the market dynamics are stable for years and budget is spent for marketing efforts whilst the operational efficiency needs such consolidations in back office and IT.

If you are not in that situation, but carry the burden to make long term strategic decisions or to advise decision making, you surely are aware that you can only spend ressources once, and that whatever path you choose, it will impact the future of the success of your company or organisation.

You, and the folks responsible to detail, plan, implement and execute against those strategic decisions are also aware, how difficult alignment will be amongst the various peers at exec level, mid management and the various experts, consultants, partners etc. involved.

You hope that everyone will understand the context and rationale behind the decision and the impact that you want to make.

Habits of outperformers

Outperformers have the same concerns that you are facing. It might be that they are in a better market situation than you are. But long term outperformers follow some core principles that are relevant ot understand the reason behind todays article.

I guess they have a good purpose and vision and they link their strategy against, but I want to focus on another layer of behaviour.

It is when and how you come to decision making, who is getting involved and what are tools and frameworks that support you doing so.

The framework discussed is called “Enterprise as a Strategy”, but before we get into details, I want to tell you why and how it unfolds its true positive energy.

It is about when you invest time to gain speed in your overall timeline, and it is about when you invest in communication, and with whom.

The suggestion is, that you struggle yourself as executives, leadership and an interdisciplinary team of managers through that exercise. That you use that framework to understand the various perspectives, gain from knowledge from others and that you are – at the end of the approach a better, a focused and an aligned team, ready to lead the organisation through the execution.

Kotter’s leading change book introduces an eight stage process, and calls out stage 1, 2 and 8 to be the most underestimated and critical stages.

  • Stage 1: Create a sense of urgency
  • Stage 2: Create the Guiding Coalition
    – and the latest stage in his process: 
  • Stage 8: Anchoring new approaches (in the Culture)

In simpler words: The time you invest in aligning a group of leaders across your organisation, and giving them time to identify the situation and context and plan jointly what to do, that is the best investment you can do.

And if you fail to achieve this, you have identified clarity on another, potential more substantial problem.

The idea behind “Enterprise as a Strategy”

The “EaaS” framework suggests such a collaborative, structured approach to gain a joint understanding. It has a clear purpose – and that is to save you from running into false areas of optimisation, and to support your efforts with the individually right level of standardisation of policies, business rules and underlying IT capabilities.

The framework understands how hard business and IT alignment is, and how much pressure is on the business leadership to adopt to circumstances.
Hence, it suggests to take a step back, and focus a model more stable than current business priorities. 

It introduces an approach to  classify the operational model of the company. This alows comparing your business to competitors, but serves additionally as a joint thought model across leadership levels from exec to business departments “down” to IT.

Let’s dive into details:
It starts simple, by taking two dimensions to understand the situation of the business better, with

  • dimension A as the level integration of business processes
  • dimension B as the level of standardisation of the business processes.

The dimensions allow to differentiate the four quadrants. And those quadrants help us to understand how far alignment of business processes and the complexity of integration across the organisation needs to be. 

Many organisations are stuck in meaningless initiatives

With some years of consulting background or the like, most of us have seen organisations that are stuck in initiatives that seem meaningless. It might be that an organization cannot answer a strategic change on the market place, because the back office is freezed in status quo. Or maybe due to a data center consolidation oran IT  outsourcing is taking place.
Or the market dynamics are stable for years and budget is spent for marketing efforts whilst the operational efficiency needs such consolidations in back office and IT.

Lets stay on an abstract business level before we get into how that affects IT:
The four quadrants of the operational model help you to identify your status quo from a business model and give hints on where you can look for gaps in your execution, growth or efficiency strategy, because your level of standardisation or integration is designed as a fit for another business.

The relevance is best seen if you try to understand how your business model scales best from a growth perspective.
Ross, Weill and Robertson structure the options according to above model:

We see a major effort from an integration point of view if we consider acquisitions in quadrant on the right side: Unification and replication side ask for a “Rip and Replace” of the org structure and related IT systems.

First personal checkpoint for you: Do you feel that your current or past workplace organisation suffer(ed) from half baked mergers and acquisitions in the past?

As this is about learning, you might take mental nodes on your past observations and what potential root causes you consider can consider?

How is that relevant to the industry in (post) Covid-19 times?

As said above: The quadrants are extremely helpful to consider mergers and acquisitions, at business level but also at a personal level.

First you can understand the business model of your own and current organisation. Then on situation of merging with other organisations, both as acquired or acquiring party:
You can judge efforts and complexity, and core areas to be most careful of in the transition.

In a diversified model, a somehow “peaceful coexistence” of both organisations will happen, synergies will not be high and your business is not at much risk from a process and IT view. Maybe you want to consolidate basic IT infrastructure and some systems like HR or payroll, but none of the core business systems in your value chain need to change with urgency.

The other extreme is the Unified quadrant: Totally integrated business processes and systems to support them. From a business view this looks like an area where synergy effects are as interesting as growth perspectives, what urges an aggressive transition leads into an organisational and IT “rip and replace” job.

A one page architecture overview of your business is crucial

It is true, the quadrants give a good initial orientation, but it’s not enough to plan ahead. Some more alignment is needed. The authors are strongly suggesting to invest in creating a joint 1 page architecture overview of your business. 

Before going into examples, let’s talk about common pitfalls:

  • As executives and leaders: Do not delegate that work to others. You need to invest and commit to work through this in an interdisciplinary workshop.
  • Invest enough time and energy to make this sound and solid
  • Expect various perspectives and be open to understand your peers – their view may give you insights you are lacking off
  • It is not about IT architecture. It is about the architecture of the business, its value streams, policies etc.
  • Control granularity: Focus on  a one page, visual representation so that you can use it as a poster.

Let me provide ideas how this can look like. To do so, I’ve taken two examples from the book. It’s meant to inspire you doing it and to demonstrate how valuable such a representation can be.

Example 1 – The anatomy of an inspiring, unified operational model

Example one is from the Unification quadrant – from a complete standardised and integrated business (Delta Airlines). 

As an anecdote, Delta’s COO used to be Jim Whitehurst, my former CEO at Red Hat. Another book reference is Jim’s book “The Open Organization: Igniting Passion and Performance”, published by Harvard Business Review

Now, back to Delta’s one page enterprise arch poster, as an example of an example for a unified kind of business:

What I like here, from my perspective as a IT Solution Architect, is it clear to understand the base focus of their business model: On top we see that operational efficiency on their key asset – the airplane fleet, can be identified as one cornerstone of their business architecture. And the conversion / sales & value stream is the other one on the bottom.

In between we see what is needed to run the business, and I like the idea of an event driven nervous system that keeps all together.

Furthermore, you can discuss how changes in the setup, issues or events are affecting the business in operations, but from an operational and planning perspective.

Example 2 – Diversified operational mode

Below picture looks much more common to software architects – it might be that a three tier architecture is the highest common divider. 

Above picture demonstrates nicely, that the common denominator is a tech stack focussed standardisation, that includes frameworks for integration, data management and process design at the technical foundation level, and a segmentation of partners, customers and independent business units related.

It might be that tooling for web sites, customer relationship management, human resources and related headquarter processes will be shared amongst the business units, but that is not a necessity from a paramount strategic view.

What we also see is, how generic the architecture is, as diversification and value streams are defined by the purpose of the individual business units.

Thinking one step further: Of course, each business unit can then define their own operational model and repeat the exercise on defining their “quadrant” and their unique one page architecture to align within the individual business unit. (I would recommend so)

How to balance your differentiation capabilities versus standardization needs

Standardisation can add an unnecessary corset if you overdo it

Above thoughts are essential to foster a joint understanding & language. This can benefit in smoother budgeting, strategy alignment, trust and teamwork.

But the real power of what we get out of things discussed is, that we understand to what extend and to what level an investment in standardisation is reasonable.

The identification of the optimum level is key to spend money, efforts and spare human capacities available wisely. Remember my rant on organisations that are stuck in meaningless initiatives? 

This is not only true for mergers and acquisitions, but also to have a general judgement on what would be a good investment into standardisation. To identify the right level is key to create a maximum of synergies but being able to differentiate and react to market dynamics.

It’s obvious that standardisation leverages positive scaling effects, but if you overdo, you create an eventually painful and unnecessary corset on your organisation. This has a negative and growing impact on staff motivation, partners across your value chain and so on. This can lead  to demotivation or loss of brand recognition in the worst case.

Finding the best level of standardisation

With all work done so far and this reflexion on balancing standardisation and differentiation, let’s go one step further and find the area to consider the perfect level of standardisation from a strategy point of view.

First, we extend our viusal model andneeds to detail the Enterprise and IT Architecture box and expand them. 


In the next step we’ll link our perviously achieved and joint understanding of the Operational Model and the one page architecture to those boxes:

Lets go through the extension of the model with focus on the right side of the picture:
First, on the green Enterprise Architecture we need to understand that the upper box is initially the architecture of the organisation and related business rules – but as IT people we can easily relate business applications accordingly.

It continues with an architecture for processes, data & information handling and application architecture. 

Below we see the blue IT Architecture box, that contains runtime, network, storage, orchestration, repositories, logging, monitoring and the like.

Most efficient way to identify the fitting level of standardisation

With the input from the the steps done so far, we are well alignment in an interdisciplinary team, we have a good awareness on our situation and had hopefully some good but may be surprising insights on what we did not consider in the past.

To not get stuck in meaningless initiatives, we now need to identify on what level of the organsational structure we need to focus to have the greatest impact from effects of scale, on where IT systems need to support the businesses we’re running – and where we need to keep room for individual autonomy for the individual lines of business. 

This step is rather mechanical, and the picture below points it out quite nicely:

  • In case our operational model is classified “Unified”, then it is good to consider standardisation on the highest level of our model – and to standardise not only IT but also our business processes, policies and structure as much as possible.
  • If we have a model classified as “Coordinated”, it seems right to standardise the IT Business Architecture at the level of business process-, data and information-, and application architecture.
  • On a diversified model, it might make sense to standardise basic hosting, networking and workplace setup but keep all the rest to the lines of businesses.
  • I let you figure out how replication is done best. As a hint: We had a matrix above, related to growth strategies – and both Unification and Replication model state that rip and replace is the way to handle growth via acquisition.

If you consider the habits of outperformers we discussed at the beginning, you now have created hopefully a strong alliance of people that are well aligned on all we have discussed so far.

You used a framework that has a good visualisation and that is simple enough to explain staff, stakeholders at all levels and specially the usually critical mid management layer in your organisation what the mid level strategy will lead to – and more important – why the strategy has the focus it has.

What you can expect in part II

That is what I intended to introduce and discuss in part I. 

In my next article I will continue with thoughts on how to organise development and operations. And to extend on what we are missing so far is: How can we implement such a strategy and what might be a model to structure our organisation accordingly?

This is what you can expect in part II, that we’ll publish soon.

With all my thoughts shared, I want to close with a disclaimer as I heard it from Alistair Cockburn, one cool agile coach as I need to state. Alistair said how agile is a framework that needs to be adopted to your individual setting and constraints. He said: “Agile is a powerful framework that I explained. But you need to know your own swamp”. The same applies for my thoughts in this article.

Like with all models: Trust your own professional experience and take doubts seriously to adopt the framework to your individual situation and context.

This said, I hope we’re both on the safe side 😉 Hope to see you again on part II.

By Michael Leibfried

Michael Leibfried is an experienced IT professional with experience as project manager, lead architect, team lead, developer and consultant. He has delivered solutions for market leading brands, managed distributed, large scale teams, also in distributed offshore delivering.
At Red Hat, Michael consults customers as Solution Architect in the context of complex digitalisation projects and leads related strategic engagements.

One reply on “From Enterprise Architecture as a Strategy to Business Infrastructure as a Platform – Part I of II”