The Business Model Canvas applied to EA itself

Motivation

Let’s start with some motivation for this blog.
Last year, digitalisation at Ingka (the biggest IKEA franchisee) also led to changes in the organizational setup. Surprisingly for me the (IT-)Enterprise Architects team was closed.
Surprisingly according at least two points:

• I thought that any organisational change on a company level is an area where the Enterprise Architects should be an active part of the change but have at least been consulted
• Why the (IT-)Enterprise Architects team was seen as an organizational unit with no existence in the future setup?

Management decisions are not always explainable without some deeper insights and knowing the context I don’t have in this specific case. Could be that the (IT-)EA-team wasn’t seen as effective and efficient enough, could be that one of the famous consultancy companies has driven the management into a direction to support other ways of working. Or whatever.
All that isn’t my biggest concern as I cannot and want not change this decision.

But there is an important point:
I work as an (IT-)Enterprise Architect. I like the thinking in big structures, in strategies, in capabilities, in roadmaps, in modern technologies. Could it be the case that I have missed some development on the market that the (IT-)Enterprise Architecture is redundant meanwhile? As a discipline? As a job? Or just the ways how to organize their work?

It’s time to reflect. And isn’t there a better way than to apply the Enterprise Architecture methods to the EA as a discipline itself and derive some understanding?
Let’s start with the answering of some formal questions:

• What is the Business model of EA?
• What are the Value Propositions of EA?

In a second step the Enterprise Architects relevance according the Business Model and Value Proposition could be discussed.
As proven methods let’s select the Business Model Canvas and the Value Proposition Canvas (coming in an extra blog)

The Business Model Canvas

The Business Model Canvas is essentially a template to describe business models based on nine building blocks:

See Wikipedia - Business Model Canvas for further reading and explainations.
Normally the BMC is applied to firms and companies but there are some different attempts to use it for other organisational units so as I do now.

(1) What are the typical Customer Segments of Enterprise Architecture?

One of the characteristics of Architecture in general and in EA is the fact that all value from it isn’t seen directly. In the companies selling services and products the EA is mostly invisible.

This means that the ‘customers’ are the decision makers in the company itself.
So a quick answer could be: All stakeholders, having a responsibility or even accountability in business- and process development in medium to large size companies with a complex IT landscape.

But let’s have a closer look. There are two aspects to discuss:
What is the target group of EA? Who will pay for EA?
That’s not the same. Even the service of EA could be well defined, in the real world the ‘customer’ is selecting the service and service provider and not vice versa.

In my experiences the target groups are coming from mainly three areas:

• The ‘business’ (process developers and sponsors from business capability areas/domains)
• The Digital- and IT-management inclusive steering commitees
• The IT Supply Organisations inclusive Product and Platform Owners

The sponsoring is coming from the IT organization as a default pattern in my experience.

There are many speaking partners daily e.g. Business Controlling, Software Architects etc, but I see them more as partners (see (8))

(2) What is the Value Proposition of Enterprise Architecture?

There is a lot of research about the benefits of Enterprise Architecture
see e.g. The need for Enterprise Architecture

Document knowledge on the enterprise	Improve resource quality
Identify resource dependencies	Improve return on investments
Identify resource synergies	Improve situational awareness
Identify suboptimal resource use	Improve solution development
Improve alignment with partners	Improve stability
Improve change management	Increase agility
Improve compliance	Increase economies of scale
Improve customer satisfaction	Increase efficiency
Improve decision-making	Increase growth
Improve employee satisfaction	Increase innovation
Improve enterprise-wide goal attainment	Increase market share
Improve information quality	Increase resource flexibility
Improve investment management	Increase resource reuse
Improve measurement	Increase resource standardization
Improve organizational alignment	Increase revenue
Improve organizational collaboration	Provide a high-level overview
Improve organizational communication	Provide directions for improvement
Improve resource alignment	Provide standards
Improve resource consolidation	Reduce costs
Improve resource integration	Reduce complexity

It’s seen there is a lot of expectations in such a long collection. It has to be noted that all these are valid points but the Enterprise Architects aren’t realizing it directly, it’s more an enabling function. It’s the management and decision makers take the decisions.
But there is no doubt, that the EA has his value.

From the Business Model Canvas perspective the different deliveries and use cases of EA implies three Value Propositions:

• Enable Change, Growth and Speed
• Ensure Compliance
• Reduce Complexity

Let’s discuss this later on.

(3) What are the Channels Enterprise Architecture is delivering?

Typical channels Enterprise Architects are using:

• Design and Decision Boards on executive level
• Steering commitees for the bigger initiatives and programs
• Regular Report Publication (Audits, Reviews, Health checks)
• Architecture Repositories access
• Internal and external Publications
• Slack and other Chat Channels

(4) What are the Customer Relationships of Enterprise Architecture?

In an selling organisation all is about to get new customers, hold and let grow them. How to treat them in a best way to achieve the business goals?

For the companies decision makers a stakeholder management is a key for success. Management is inviting EA only if they are beneficial for them. It is on the EA organisation to make themseves relevant.

The target groups in the IT organisation will accept all the EA principles and patterns only if they are aligned as a result of an equal partnership.
Nobody likes know-it-alls.

In conclusion the relevant Customer Relationships are:

• Advisory on Strategy Execution
• Internal High Skilled Consultancy
• Co-Creation

(5) What Revenue Stream for the Enterprise Architecture is applicable?

Like the Risk mitigations the revenue isn’t directly but indirectly by

• Saving Cost through efficiency
• Saving Costs through changed business model
• Avoiding Compliance Losts and Penalties

In practise I haven’t seen EA as an own profit centre.

(6) What are the Enterprise Architectures Key Resources

The strategic assets make EA valuable for company decision makers are mainly

• Competencies in Architecture Methods and Processes
• Experience in the Enterprise Business
• Problem Solving Skills
• EA Tools and Repositories, inclusive Principles and Patterns
• Portfolio Structuring and Planning tools and skills

(7) What are the Enterprise Architectures Key Activities

The daily life of the Enterprise Architects is mostly around these key activities

• Conceptual work on Deliveries
• Inhouse Consulting
• Participation in Initiatives and Steering Commitees
• Audits, Reviews, Health Checks, Architecture Assessments
• Own Architecture Consulting Initiatives, e.g. Hackathons, Boods etc.

(8) What are the Key partners of Enterprise Architects?

Key partners are normally used if there is a need for services, the organisation (in our case the EA) cannot deliver for different reasons. Could be EA isn’t able to deliver such services or isn’t willing.

To be successful in their own deliveries EA needs to been updated by mostly all inhouse IT Organisations like Developers and Solution Architects, Data Engineers, Product owners etc.
In addition the EA must have a market overview and therefore stable relationships to external competneces like Research Companies is essential.
The most relevant partners are

• Solution - and IT-Architects
• Business Analysts
• Product owners
• External Research and Consultancy Companies

(9) What is the Cost Structure of Enterprise Architects?

As the charakteristics of the Architecture in general and EA in specific, they aren’t delivering direct results, the cost allocation to business initiatives is often done via normal Full Time Employee (FTE) costs.
Nevertheless to work efficient an own cost centre structure with an own budget is common sense in bigger organisations.

This means that the most applicable costs coming from

• FTE salaries
• Architecture Initiatives costs
• Travel, Education and Training
• Licenses for EA tools

The Final Model

The resulting Business Model Canvas applied to Enterprise Architecture could look like finally

Conclusions

Originally there was my question about the relevance of Enterprise Architecture and Enterprise Architects.

Some of my conclusions:

• Enterprise Architecture as a discipline is relevant as there is at any way an Architecture implemented in the Enterprise. It’s just a question of the management to control it or not and with what of effort
• The relevance of having Enterprise Architects is going in the same direction. Important is to steer the Enterprise Architecture. Enterprise Architects should have the competence and the leadership behaviour to fill the job with life.
• To have an Enterprise Architecture Team depends of course on different influencing factors. For bigger companies I believe it is a must to invest in a separate organization to give them a chance to execute Architecture initiatives.

There are some unanswered questions still left if I look in some newer development in IT business like DevOps. Digital Transformation is a signal for a disruption in the whole economy.
I think the Enterprise Architects are excellent capable to been part of the steering of these new processes.

What the hell an IT-Enterprise Architect is doing?

It’s always a challenge to explain to my family and friends what an IT-Architect is doing in his daily business. Even more tricky it’s about an IT-Enterprise Architect and the difference to an IT-Architect.
But even in the IT business it isn’t a matter of course. An IT mangager told me some years ago that he believed Enterprise Architecture was a bit Hocus-pocus.

The usual comparison

In making a better example I often compare the profession with the architecture in construction business.

Quelle Pixabay
Essentially the construction architect serves three parties:

• the client (who wants to have the house and is willing to pay for it)
• the developer (who is building the house and wants to be paid)
• the legal government (not all is allowed, there are some rules of course)

To be successfull he must have a lot of competences. He must know mostly all about the construction of the house. About the bricks, the tubes, statics etc. inclusive a lot of legal rules. That’s the core.
More than that he must understand the wishes of the client and have to bring it in a design that is accepted.
And here we are at the most important spot: It is mostly on him to find the right trade-offs. It’s obvious that the client want to pay as less for as much as possible.
The developer on the other hand wants to be paid fair (at minimum:-). And yes, some desires cannot be fulfilled because there is normally a land-use plan.
Let’s assume the success is defined in a way that all partners are happy but at least satisfied.

How the Architect can contribute in the confusion of the different interests?
He must be an expert in construction of course, but more than that he must:

• speak the languages of the stakeholders (to understand the interests)
• be neutral (to be accepted)
• creative and sometimes innovative (to find the good compromises)

Some of it can be learned with a while. E.g. the Architect is producing a lot of technical drawings. Why he is doing it?
He is documenting the architecture, of course. But he makes some more - he makes the design options explicit to the stakeholders, avoiding mistakes in understandings and ensure transparency in motivations of potential conflict partners.

There are two other aspects make an Architect to an Architect:

• Architects have a specific attitude to look on problems, they like to structure things

Quelle Pixabay

• An Architect must have fun to align the different interests, to explain solutions and be strict in following the compliance rules. With other words he must not only behave as an engineer but as a leader.

Coming back to IT

This in mind let’s talk about an Architect in IT now:

Some essentials are directly comparable. Generalized he serves

• the legislative (the client with the money, the sponsor)
• the executive (the party builds some IT’ish, could be an IT project orga)
• the judiciary (compliance is overall)

Instead concrete and tubes he’s working with other ‘bricks’. What ‘bricks’ exactly, depends on the level of abstraction in the IT business:

• A Software Architect is playing normally with:
  Software (what a surprise), means with concrete software development, user interfaces, software patterns, modules, classes, etc.
• An IT Architect deals with things like
  IT systems, networks, databases, clouds, security, performance etc.

Remark: The description isn’t precise and far away from any completeness. There are a lot of different domains in IT like infrastructure, applications, technolgy, data, governance etc. and so there are specialized Architecture roles for it.

To illustrate the different interests in IT see some viewpoints/scenarios in software development:

Scenario	Winner	Loser (Opponent)
Quick and Dirty	Developer, Sponsor	User
Some Extras and Decorations	Developer, User	Sponsor
Unrealizable Requirements	Sponsor, User	Developer

It can be seen that in different scenarios there are different winners and losers.

And the (IT-)Enterprise Architect?

All what was written above about the competence, the attitude and the behaviour is true for an Enterprise Architect as well because he is an Architect.
Focusing on the differences to the classical IT-Architect there are the usual ITish ‘bricks’ like servers, networks, software, databases and all of that, but there are some more due to the fact that the abstraction level, the context is the Enterprise now:

• Business Capabilities, Processes and Value Chains
• IT Landscapes (IT System portfolios, Inventories, Diagrams)
• Roadmaps, Initiatives, Projects
• Technology Standards (Reference models, IT Principles, EA Patterns)
• Information Models

Or continouing the comparising with the construction business - He isn’t dealing with buildings only but with cities and their specific challenges like urban and regional planning, urban design thinking and sustainable urban development.

In the Architecture community can be found tons of different detailed descriptions.
See e.g.
Wikipedia - Enterprise Architecture
TOGAF Standard V9.2 - Introduction
Gartner Glossary - Enterprise Architecture

In my practical experiences the tasks of an (IT-)Enterprise Architect coming from three main processes:

• Modelling and enforcement of policies and standards
  (that’s what is seen as the core: creation of pre-studies, blueprints, concepts, audit reports, funny landscape pictures and a lot of Excel lists and PowerPoint slides)
• Planning support of initiatives
  (supporting the translation of business strategies in executable IT roadmaps)
• Execution and governance support in initiatives
  (‘making the hands dirty’)

Value Streams and Use Cases

The Enterprise Architecture as a discipline isn’t as old as the traditional Architecture in construction. To meet the business expectations as evolving to an enabler of more profitable and sustainable business outcome was and still is a learning challenge.
From beginning bigger organisations had the need to align the IT portfolio management with the Enterprise business strategy.
In Business Architecture there is a concept of Value Streams to classify all tasks if they give some value according the business value proposition (see Business Model Canvas and Value Proposition Canvas)
Applied to the Enterprise Architects use cases I would identify three main value streams:

• Enable Change, Growth and Speed
• Ensure Compliance
• Reduce Complexity

The use cases per company differ and must developed individually. Some use cases with a wider coverage are:

To illustrate what typical questions an Enterprise Architect is driven by, some example use cases:

Example 1 - Application Portfolio Management

The last decade has shown that the most successful companies were those who know their customers best and were the quickest to convert this knowledge into sellable services and products.
The IT of the company has to do at least two things here: first, to automate a learning process of customer demands as much as possible, and second, to be able to support the changed business model in its implementation.
How the IT in the affected companies is prepared for it if the driven factors are uncertainty and time to market?

What could be a valid strategy to support a moving target and how to measure quality?

From software development of a single applications there are known techniques and structural patterns achieving exactly this. The quality of the software architecture will be measured e.g. by the ability to refactor. Another quality attribute is the degree of decoupling of the essential components. Supporting patterns are e.g. Domain Driven Design.
Valid key figures to measure the quality according the agility of a whole portfolio of applications could be similar: Identify the dependencies of the most important components in the application portfolio and find and apply decoupling patterns.

Such patterns, applicable to an application portfolio are e.g. the coverage in usage of MicroServices.
See Wikipedia - MicroServices

Example 2 - Enterprise Concepts

Add on to the first example there is a need to collect data to be able the customer demands and his behaviour. More than that the learning itself have to be automated. Modern technologies like Artifical Intelligence and Machine Learning is exactly about.
Legacy IT landscapes are very often have grown historically and the data are locked in silos.
A valid task for an (IT-)Enterprise Architect is to find concepts to unlock the data and combine data ingestion with intelligent integration concepts.

Such a concept applicable to the Enterprise could look like:

The basic idea is to combine two things:

• a concept to integrate and decouple systems, inclusive the usage of modern event streaming technologies
• a concept to collect data for further analytics

Conclusions

An Enterprise so a business organisation is a composite of a host of different moving parts. Holding the complexity under control and managing it could be a daunting task, unless you have the right approach. The good news is once can use Enterprise Architecture as the glue that holds the puzzle peaces together.
Adoption is a chance to bring order and structure to the business.

Remarkable:
No, Enterprise Architecture isn’t a silver bullet, but the benefits could be realisticly realized.
One of the most applicable understandings I had in the last years is to leave the ivory tower of pure abstraction and apply the same behaviour to the Enterprise Architecture itself as it’s expected to it’s subject.
This assumes e.g. to invest in learning to be up to date in the relevant disciplines of technology and business trends.