Introducing the complete view on the framework

Re cap on Part I – Building your individual strategic framework

You likely remember the left part of below picture, that introduced in part I/II how to bridge the gap between business and Enterprise/IT architecture, gain a joint perspective and language between leadership domains.

Furthermore, we linked why your organisation and its processes and policies need to be addressed by business it systems to build a solid and relevant foundation for your individual organisation. The four quadrants – depended on depth of needed process integration and cross process coordination – helped us to categorise and identify growth strategies.

And due to high dynamics due to current 3rd wave of Covid 19, we explained the relevance to consider those in the context of potential mergers & acquisition strategies.

Besides on the logic of the framework itself, we provided you tools to use to achieve alignment and joint understanding across relevant leadership roles.
The tools to build such alignment and common understanding are:

Organisations operational model,
One page enterprise architecture overview
Guidelines to prepare in case of merger & acquisition scenarios
Awareness to identify good balance between standardisation and autonomy
Gathering of pitfalls and loss of effectivity a poor balanced standardisation organisation has
Emphasis why a strong strategy needs a solid and matching foundation of underlying structures and processes to play out

Besides tooling, we raised two main concerns:

Leadership must not delegate the strategic thinking to sherpas, but need to be involved in the discussions, thought processes and alignment
All work on the left side done by leadership is helping to achieve basic steps prior to potential change, according to Kotter’s well known, eight staged change model
- Stage 1: Create sense of urgency
- Stage 2: Create a guiding coalition
- And prepping for stage eight already: Anchoring new approaches (within the culture).

Visualising the framework eases also communicating throughout the organisation, as you need to align your staff to understand and implement the details in programs, projects and daily operations.

Extend and build on top of the strategic framework

And that is what we want to focus in part II – extend the strategic framework into more detail.
Our extended framework interlinks the four core areas in context to each other:

On the very left: Grand strategy, operational model and the foundation for execution.
On the middle left: Layered structure of the Enterprise, IT business and technical infrastructure
On middle right: Approach and organisation of your collaborative, interdisciplinary teams
On the very right side: Organisational and technical platform to support your organisation

To complete above areas, we continue to embrace the

interdisciplinary perspective, collaboration and the
objection to optimise the over all situation and
to avoid “siloed” optimisation.

Let’s use an artificial scenario, to put some flavour to the ideas.

Walk through scenario

For our walk through, we use the unification quadrant, that is leveraging the potential of standardisation at it’s max. We want to show you the benefits, but want to remember that it is you to adopt the framework, conclusion and to take the efforts to refine your own situation.

Now, I want you to re-consider the one page architecture airline example discussed in part I.

For me, not being a specialist in airline and airport systems at all, the example allows to include perception, assumptions and interpretation in that scenario, to make it fit to my stories. Apologies to all airline and airport experts.
But it seams easy for me to take my thoughts and transfer it to other domains like banking or insurance and their core systems, and your individual set up.

I see above architecture as highly complex, many integration points into airport and baggage, ticket, air travel security, border management systems and much more, differing due to national regulations, yet standardised at international level at other parts.

Assuming the CEO, COO, CFO and CIO/CTO to focus of strategically manage a huge, distributed portfolio of planes, staff, routes and hence slots and destinations, as well as cooperations with other airlines. Optimisation and growth of market share as most critical day to day issue.

Assuming that the airline created a new destination at a new continent, certainly you need to extend your operational and hence, IT systems accordingly. You need data center capacity, integrate safe networking with your existing core data centres. Deploy your operational infrastructure on top and then role out your core business systems needed, that then need to be integrated in whatever systems. You need to test, train new staff and then operate airline and IT operations reliable and resilient to the many factors that can affect your airline business.

It is likely, that this is happening quite frequently – frequently related to the complexity of what has been described as problem space in the previous paragraph.

At the same time, your team at home is working on the next evolution cycle of your architecture, and one thing your organisation learned is, that business systems benefit in operations a lot from close cooperation with operations.

In the past, operations and IT architects have been included into the interdisciplinary teams that are implementing and operating the business it systems. The teams learned that the many technologies and frameworks used in the past hinder them from collaboration and exchange of specialists to gain more flexibility.

They learned that consumption of virtual instances for test and CI/CD servers saved lots of time, and they suggest to extend this flexibly and versatility up to the automated deployment and testing ob businesses core systems. To improve turn around time in development, they started to use this in their individual CI/CD pipelines, to increase time to market and over all quality and stability, they extended it into their overall pre prod and security testing pipeline.

This has put a lot of complexity to the operational team. Like in any other sector, they missed funding and staff capacity, but also some development skills to serve those ideas. But with proven results on the strategy implemented so far, management was open to ideas and supported a refactoring of the setup at the interface between implementation and operation of business IT and operational IT.

Evolution from Operations to a platform team

Operations grew their mission and attracted peers from the larger business IT team. They wanted to change their style of interaction and decided to provide an implementation of above as a platform.

One things was clear to them: Like the airport system itself, with it’s huge and complex infrastructure serving travellers, they want to provide their services and infrastructure at highest level, and they wanted to treat their business IT teams as customers.

Vision and Mission

The intent was to standardise, automate as much as possible, not only in development and testing, but also in operations and maintenance.

The vision was to allow consumption of complex business IT systems around the globe like virtual machines in the past.

To achieve this vision, the business IT and the new platform team agreed to build the capabilities over time, in close collaboration and exchange. Proof of concepts where tried with pilot teams first, then procedures and methods as well as tech stacks, testing etc. where generalised and tested with y broader audience.
Issues and procedures in operations where analysed jointly, using scientific management and amplified learning. Mind set requested from all parties was, to question set up and procedures at all levels within root cause analysis phases.

Over time, standards where implemented and automated to be shared widely across the over all set up, with certain distinctions and dependencies whether it was a customer focus system or backend systems, whether it was a central data center based service or a distributed service and do on.

Resulting effects

The rigorous root analysis, automation of nearly all procedures in development, testing, quality assurance and operations, as well in the business processes on top of IT leads to confidence in the over all staff, and resilient operations with the flexibility provided as needed.
Confidence was sourced my the experience that:

Stability and safeguarding tooling instead of a governance that focussed on effortful control of contributors, that slowed down progress and time to market
Change and evolution was possible, based on joint analysis and evaluation
Platform team provided mechanisms that helped to distribute experience and best practises across the organisation
Increased trust and cooperation at interdisciplinary teams from leadership to individual contributors due to increased transparency, communication and process & service quality
Less complains from customers
Gain of new customers building new services on top of the platform build, what led to a broader eco system

Human centric, Business driven

Two things are at the core of the frameworks value system, that we are calling out here:

The framework is human centric
Leadership and management focussed on giving orientation, foster trust, transparency and to establish a positive error and risk management culture, deeply woven in daily work.
Alignment and purpose are business driven
Complexity needs orchestration and alignment. As much as orchestration should be organised by learning, the much purpose and alignment needs to be fostered by good leadership

Our values do not ignore the pressure leadership roles are in, and we are not neglecting that some set ups can be toxic or at least difficult.
We trust that the frameworks and methods will help to understand the current situation with it’s problems and that it provides measures that help you to improve your and your organisations situation.

And we hope that our ideas are, in case, a motivation for you not to accept an unsatisfying status quo.

If you like to dive deeper in ideas behind, let’s continue.

Basic Strategy: Management with scientific methods

The following picture has a grey box below, requesting to “Manage with scientific methods”.
It is a phrase taken from “Lean Enterprise” published by O’Reilly, and it motivates to embraces the complexity in current businesses and organisational and technical systems accordingly.

It requests approaches that emancipate themselves from methods used in early industrialisation and mass production. Henry Ford’s assembly line to build Model T is such an example, when a a small group of experts envisioned the whole set up from ideation, design to steered and control the operational phase. This is what can be called Scientific Management. A small group of experts managing – the scientists, and staff to follow fine granular governance and strict procedures.

It is easy to assume that you, the reader, are in a business context that is rather complex, embedded in a fast moving, competitive landscape, frequent changes in regulative constraints.

Technological developments occur that you need to investigate, analyse and and adopt.
This complexity needs more but a small group of experts (The leadership team) but needs inclusion of experts, consulting roles and delegation into specialised teams across your organisation.

You can compete only if you leverage the full potential, skills, the good education and training of your staff. Complexity needs to allow errors and risks taking – in a controllable and manageable way. Continuous, observable but smaller and controllable change promises you to balance stability versus innovation and evolution – at any level you need to consider.

Approaches need to delegate trust and problem solving towards your staff. To solve problems, understand context and constraints, interdisciplinary teams are needed, for coaching, learning and risk management, a clear framework on how to communicate is needed. Because it is a cross team, cross organisation alignment and balancing of interests and responsibilities needed.
Simple, yet sufficient core management artefacts need to be defined, as well as a repeating meeting rhythm that amplifies self learning at all scales.

It’s the base idea behind Lean and Agile

It is a paradigm change introduced by outperforming tech companies. Toyota’s lean management is one implementation, but approaches have been adopted to match perfectly tech, platform and software companies’ domains.

If you have not guessed already, agile implementation like scaled scrum or kanban is what we have in mind.

There is lots of literature out there, and we recommend Scrum@Scale for an advanced entry point, as well as Henrik Kniberg’s you tube video “Product Owner in a Nutshell”.

Three ideas to orchestrate Scope, Work and Competencies

First idea is the Enterprise Backlog as base for planning and execution

that all requirements derived from the detailing of left sided Tech- and Enterprise architecture is gathered, planned and executed against a joint Enterprise Backlog.
Basic requirements can be noted in user stories like:

I as a (User Role)
want to (activity)
on (problem/document etc.)
so that (result planned)
in the context of (business process / situation etc.)

You can order those use cases by the layers according the left sided model. Key is, that you need the inter disciplined team from the middle part of the picture, to judge business value, efforts for implementation, scope details and dependencies from business, tech and approach point of view, what allows prioritisation and ordering of the backlog with all of the known requirements.

Hence, your teams are ideally always working on what provides highest value at a given time.

Second idea is amplified learning

The scientific notion in agile suggests to consider the backlog entries with all details to be seen as hypothesises. User stories, priorities based on business value versus implementation efforts are based on ideas and current understanding. Only implementation proves accuracy.

Hence, disciplined and periodic retrospectives and reviews help to improve accuracy of judgements, detailing. Amplified learning will be accomplished over time, allowing that according organisational setup, individual roles and responsibilities will be sharpened – based on better and joint understanding.

Literature related explains how experts keep and grow their knowledge in “chapters” and how cross cutting concerns are collaborating in “tribes”.
We recommend to consider the vivid and exhaustive literature that is present on the market if you like to extend your knowledge.

Third idea is to standardise what is not needed for market differentiation

The third and hopefully new idea is, that the level of abstraction that we identified (symbolised by the coloured arrows at the far left of the picture) helps to understand what processes, standards, tools and systems are commonly used and where you need to invest to differentiate from competition – and to structure your organisation accordingly.

What we discussed in part I was merely on how to find that fine line where the optimum level between standardisation and autonomy, effects of scale and standardisation costs are.

And we emphasised that this view affects all three layers of your foundation: The enterprises organisational architecture, IT business architecture and the technical architecture, all linked together.

If you take a step back, look at the airline example and complex, unified quadrant business models, you might see a link to the hyper scalers’ success stories.

Instead of seeing the technology, scaled data center capacity you might see now, how that capabilities have grown out of different business models: Advertisement, e commerce, media and so on.

For me this is a core question for IT leadership: Is your companies business model fitting into the eco systems existing, so that you want to buy into an eco system of specific hyperscalers?

Or are you rather interested in flexible compute, network and storage capacity to build upon, may be as a hybrid between usage of hyper scaler and on premise infrastructure?

Strategies allow to use hyper scalers infrastructure and to abstract infrastructure, either on prem or on public clouds.

Kubernetes, S3 storage protocol and your own dev ops tool chain on top are entry points to consider such a strategy.