Business Architecture Quantified - Assessing the ... · Business Architecture Quantified –...

Business Architecture Quantified –

Assessing the Complexity of the Business

The Open Group Conference – Edinburgh 2015

Dr. Christian Schmidt

Edinburgh, October 20th 2015

Dr. Christian Schmidt | Business Architecture Quantified | The Open Group Conference Edinburgh | October 20th, 2015 2

How to deal with complexity?

The Janus face of complexity R

ed

uce

Co

mp

lexit

y

Incre

as

e C

om

ple

xity

»Our time-to-market is poor

because there are so many

dependencies«

»We need to innovate

and leverage new

technologies«

»Our costs are so high

because of a large

number of redundancies«

»We need to improve

the customer

experience«

»Projects often fail due to

the enormous level of

complexity«

»We need to comply with

increasing regulatory

requirements«


What is complexity

and how can we tell the “good“

from the “bad“?


What is complexity in the context of Enterprise Architecture?

Enterprise Architecture complexity defined

Environment

System

Element

Relationship

Requirement

In the context of enterprise architecture, the system in scope may be the whole enterprise or any

subset of it including (horizontal) architecture layers (e. g., business architecture, application

architecture, technical architecture) and (vertical) architecture domains (e. g., marketing and sales,

financial accounting, human resources).

Definition:

The (structural) complexity

is a quality of a system

(or architecture) referring to

the quantity and variety of

system elements and the

relationships between

these.

[SWK13] [SM03] [Sc15]



Effective and efficient architectures

ineffective effective

but inefficient

effective

and efficient

• environmental requirements

not fully met


fully met

• internal complexity above

minimum


fully met

• internal complexity at minimum

level

Depending on the fulfilment of environmental requirements and the internal complexity used to

achieve this, every system (or architecture) can be classified into one of the following categories:



Minimum complexity and architectural waste

effective

but inefficient

effective

and efficient

It may be assumed that fulfilling the environmental requirements will call for a certain minimum

complexity that cannot be reduced without causing dysfunctional behaviour.

minimum

com-

plexity

com-

plexity

surplus

Any complexity exceeding the minimum level may be considered architectural waste (also known as the

complexity surplus). Successful complexity management is about minimizing the complexity surplus.

co

mp

lexity


The complexity continuum

The right amount of complexity in the right place

Depending on the specific requirements, the optimal level of complexity may vary across architec-

ture layers and domains (with the upper layers defining the minimum complexity for the lower layers).

Technical

Architecture

Application

Architecture

Business

Architecture

lower operating

costs

lower maintenance

costs

lower procurement

costs

higher agility /

reduced change

efforts

etc.

higher customer

value

higher business

value

higher

robustness

reduced vendor

dependency

etc.

Therefore, effective complexity management is not simply about reducing complexity throughout the

landscape but rather about creating the right level of complexity in the right place.

low complexity high complexity

TD1 TD2

AD1 AD2

BD1 BD2

TD3 TD4

AD3

BD3 BD4

AD4

BD = Business Domain AD = Application Domain TD = Technical Domain

[Sc13a] [Sc15]


The role of business complexity

Why architects should care about business complexity

Business complexity needs to be assessed for two reasons: 1. as a reference to judge the level of IT

complexity and 2. to identify and manage a complexity surplus in the business architecture itself.

BD = Business Domain AD = Application Domain TD = Technical Domain

Business

Architecture BD1 BD2 BD3 BD4

assess and optimize

business complexity

(in relation to other parts

of business complexity) assess and optimize

IT complexity

(in relation to

business complexity)

Requirements

Application

Architecture AD1 AD2 AD3 AD4

Technical

Architecture TD1 TD2 TD3 TD4

Requirements

IT Architect

Business

Architect

1 2


How can complexity

be assessed

and measured?


Assessing complexity

The need for quantitative models

Stakeholder

Concern

Qualitative

View Quantitative

View

Architecture

Data

𝐸𝑀 = 𝑓𝑖 𝑙𝑛1

𝑓𝑖

𝑛

𝑖=1

Traditional (qualitative) EA models fall short in assessing and aggregating complexity on a global scale.

They hence need be complemented by quantitative views and KPIs.

Quantitative Enterprise

Architecture (QEA)

Problems

• models are getting

very complex

• handling is very

time-consuming

• information is

difficult to

aggregate


How can complexity be measured?

The search for the “one” complexity figure

Today, it is widely acknowledged, that complexity is a multi-dimensional concept that needs to be

measured and assessed along its various dimensions.

Our complexity is

42

? ! ?

In the past, many organizations (and researchers) have been looking for a single measure to describe

the complexity of their enterprise or IT architecture.


Measuring complexity

A generic complexity model

Quantity

(Q)

Heterogeneity

(H)

Elements

(E)

Relationships

(R)

QE QR

HE HR

Business Architecture

Application Architecture

Technical Architecture

Generally, the (structural) complexity of a system can be described along four aspects: the number (or

quantity) and heterogeneity (or variety, also concentration) of system elements and relations [SWK13].

[SWK13] [SM03]

This approach is generic in the sense that it can be applied to any type of system and architecture

including technical architecture, application architecture and business architecture.


Measuring complexity

Framework of standard complexity measures

For each aspect, a number of standard measures have been identified. In principle, these can be

applied to any existing architecture model and layer (independent of the respective metamodel).

Number (𝑵𝑬) Number (𝑵𝑹)

Relative Number (𝑵𝑹 𝑵𝑬 )

Entropy (𝑬𝑴𝑬;𝑨∗ ) Entropy (𝑬𝑴𝑹;𝑬;𝑨

∗ )

Modularity (𝑴𝑹;𝑬)

Relative Number (𝑵𝑬𝟏 𝑵𝑬𝟐 )

Quantity

Heterogeneity /

Variety /

Concentation

Elements Relations / Paths

Rel. Entropy (𝑬𝑴𝑬𝟏;𝑨𝟏 𝑬𝑴𝑬𝟐;𝑨𝟐 )

[Sc15] 𝐸𝑀 ∗ = numbers-equivalent entropy measure


What measures could

be used to assess

business complexity?


What is Business Architecture all about?

Integrated Business Architecture framework

Business Execution

Business Model Business Motivation

[Si15]


How to measure business complexity

Measure candidates for business execution complexity

Business Execution


Number of Capabilities Capability Dependencies

Capability Redundancy

Organizational Modularity

Process Concentration

Number of External Drivers

Number of Goals

Number of Customer Segments

Product Variety

Distribution Relations

… …

…

Goal Relations


Capability redundancy

KPI fact sheet

ID Type

Q

V

E R

Name

BA-05 Capability redundancy

Required Metamodel Elements

Description

The average number of busi-

ness capability realizations

per number of (logical)

business capabilities. 𝑁𝐶𝑎𝑝𝑎𝑏𝑖𝑙𝑖𝑡𝑦 𝑅𝑒𝑎𝑙𝑖𝑧𝑎𝑡𝑖𝑜𝑛

𝑁𝐶𝑎𝑝𝑎𝑏𝑖𝑙𝑖𝑡𝑦

Layer

Rationale / Interpretation

The KPI measures the redundancy of a

business entity with respect to capability

implementation and is an indicator for the

business execution complexity surplus.

Example

A pharmaceutical group, whose procurement capability is implemented

multiple times across different countries and deploying different variations of

the same process type has a higher business execution complexity than a

competitor with a global shared service organization providing this centrally.

• ensure the efficiency and focus of the

organization by minimizing

redundancies at the level of business

capabilities

Adressed Concerns Primary Stakeholders

Calculation

Range Breakdown

0;∞

Optimum: 1

• by Entity

• by Capability

• by Capability

Group

realizes

Capability

Cap. Realization

Board Member

Executive Manager

Business Strategist


Capability redundancy

Example: procurement capability

Capability

Procurement

Cap. Realization

Procurem. Austria

Cap. Realization

Procurem. UK

Cap. Realization

Procurem. Germany

Process

Procurem. Proc. GAS

Process

Procurem. Proc. UK

Org. Unit

ABC Germany AG

Org. Unit

ABC Austria GmbH

Org. Unit

ABC UK Ltd.

𝑁𝐶𝑎𝑝𝑎𝑏𝑖𝑙𝑖𝑡𝑦 𝑅𝑒𝑎𝑙𝑖𝑧𝑎𝑡𝑖𝑜𝑛

𝑁𝐶𝑎𝑝𝑎𝑏𝑖𝑙𝑖𝑡𝑦= 3

Capability

Procurement

Cap. Realization

Procurement Int.

Process

Procurem. Proc. Int.

Org. Unit

Shared Service Ltd.

𝑁𝐶𝑎𝑝𝑎𝑏𝑖𝑙𝑖𝑡𝑦 𝑅𝑒𝑎𝑙𝑖𝑧𝑎𝑡𝑖𝑜𝑛

𝑁𝐶𝑎𝑝𝑎𝑏𝑖𝑙𝑖𝑡𝑦= 1



Measure candidates for the business model

Business Execution




Organizational Modularity



Number of Goals


Product Variety


… …

…

Goal Relations


Product variety

KPI fact sheet

ID Type

Q

V

E R

Name

BA-12 Product variety


Description

The variety of the product

portfolio with respect to

product types.

Layer


The KPI measures the heterogeneity of the

product offering and is an indicator for the

supply side complexity of the business

model.

Example

The business model of an organization with a highly heterogeneous set of

products and services, for example, including mobile devices, displays,

printers, and household appliances may be considered more complex than

that of a company with a very focused offering.

• ensure the focus of the business model

with respect to product segments


Calculation

Range Breakdown

1;∞

• by Entity

+

+ Category

Product

Executive Manager

LoB Manager

Business Strategist

𝐸𝑀𝑃𝑟𝑜𝑑𝑢𝑐𝑡;𝐶𝑎𝑡𝑒𝑔𝑜𝑟𝑦∗


Product variety

Example: product portfolio in consumer electronics

𝑁𝑃𝑟𝑜𝑑𝑢𝑐𝑡 = 19 𝑁𝑃𝑟𝑜𝑑𝑢𝑐𝑡 = 424

𝐸𝑀𝑃𝑟𝑜𝑑𝑢𝑐𝑡;𝐶𝑎𝑡𝑒𝑔𝑜𝑟𝑦∗ = 2.57 𝐸𝑀𝑃𝑟𝑜𝑑𝑢𝑐𝑡;𝐶𝑎𝑡𝑒𝑔𝑜𝑟𝑦

∗ = 4.03

0%

20%

40%

60%

80%

100%

Smartphones / Tablets (7) PC / Notebooks (10)

TV / Audio / Video (2)

0%

20%

40%

60%

80%

100%

Smartphones / Tablets (33) TV / Audio / Video (145)

Displays / Printer (94) Household App. (135)

Foto (17)



Measure candidates for the business motivation

Business Execution




Orgnizational Modularity



Number of Goals


Product Variety


… …

…

Goal Dependencies


Number of goal dependencies

KPI fact sheet

ID Type

Q

V

E R

Name

BA-36 Number of goal dependencies


Description

The total number of

dependencies between

business goals.

Layer


The KPI measures the interdependencies

between business goals and is an indicator

for the inherent complexity of the goal

system of the enterprise.

Example

An insurance company operating under the Solvency II regime will have to

follow a larger number of mutually dependant business goals than it would

have to without the Solvency legislation.

• ensure that the different goals to be

followed and their interdependencies

are clear and adequately adressed by

the underlying business model and

business execution


Calculation

Range Breakdown

0;∞

• by Entity

Goal

Board Member

Executive Manager

Business Strategist

𝑁(𝐺𝑜𝑎𝑙→𝐺𝑜𝑎𝑙)

depends on


Business motivation complexity

Example: regulation of the insurance industry

External Driver

Shareholder expect.

Goal

ROI above average

External Driver

Solvency II regime

𝑁(𝐸𝑥𝑡𝑒𝑟𝑛𝑎𝑙 𝐷𝑟𝑖𝑣𝑒𝑟→𝐺𝑜𝑎𝑙) = 2

𝑁𝐸𝑥𝑡𝑒𝑟𝑛𝑎𝑙 𝐷𝑟𝑖𝑣𝑒𝑟 = 2

𝑁𝐺𝑜𝑎𝑙 = 4

Goal

Min. admin. costs

Goal

Diversified risks

Goal

SCR satisfied

𝑁(𝐺𝑜𝑎𝑙→𝐺𝑜𝑎𝑙) = 4

External Driver

Shareholder expect.

Goal

ROI above average

𝑁(𝐸𝑥𝑡𝑒𝑟𝑛𝑎𝑙 𝐷𝑟𝑖𝑣𝑒𝑟→𝐺𝑜𝑎𝑙) = 1

𝑁𝐸𝑥𝑡𝑒𝑟𝑛𝑎𝑙 𝐷𝑟𝑖𝑣𝑒𝑟 = 1

𝑁𝐺𝑜𝑎𝑙 = 2

Goal

Min. admin. costs

𝑁(𝐺𝑜𝑎𝑙→𝐺𝑜𝑎𝑙) = 1


How can

complexity measures

be put to practice?


Application scenarios

Possible applications for complexity measures

1. Decision support / simulation for (major) architecture decisions

(e. g., mergers and acquisitions, business transformation planning,

target application landscape planning)

2. Comparative analyses within an organization (e. g., to explain

differences in costs and flexibility between domains or business lines,

time series analyses)

3. Cross-organizational architecture benchmarkings (complementing

existing cost benchmarkings, etc.)

4. Systematic planning of target values as part of a continuous

architecture management (e. g., differentiated by architecture layers

and domains)


Implementing a quantitative EA / complexity reporting

Process model and tools (overview)

Identify and

prioritize

stakeholder

concerns

Derive set of

required KPIs

and views

Extend

metamodel and

maintenance

processes

Implement

KPI calculation

and views

Establish

regular

reporting

KPI Calculation

Toolsets

Catalogue

of concerns

Stakeholder

interviews Catalogue

of KPIs

EA repository / tool


Application example

Enterprise IT architecture reporting

Domain Applications Interfaces

Number Risk Class EUC Functional

Redun-

dancy

Platform

Variety

Number Domain

Internal

Technical

Variety

1 2 3

Master Data 8 14% 29% 57% 0% 1.50 5.16 50 6% 1.51

Underwriting 22 60% 0% 40% 50% 2.13 2.78 22 29% 2.01

Client Systems 11 44% 0% 56% 20% 4.76 2.43 13 5% 3.56

Exposure Mgmt. 33 5% 25% 70% 80% 3.52 5.43 45 45% 4.56

Accounting 24 15% 25% 60% 10% 2.23 4.65 46 61% 3.46

Consolidation 8 10% 10% 80% 0% 1.45 2.78 24 27% 3.65

Business Intell. 14 5% 30% 65% 25% 2.45 4.56 42 5% 3.02

Controling 18 25% 25% 50% 43% 1.76 4.24 29 26% 6.76

Investment 6 5% 50% 45% 5% 2.03 4.21 13 56% 4.53

Other 43 33% 34% 33% 23% 2.54 5.43 34 27% 3.45


Application example

EA complexity dashboard (domain view)

37.3

Application Vendor

Variety

Above

Average

3.4

Business Capability

Redundancy

Above

Average

Business Architecture

Application Architecture

Technical Architecture

0.2

Application

Interface Modularity

Below

Average

7.3

Application

Platform Variety

Above

Average

2.1

Functional Infrastructure

Redundancy

Below

Average

3.4

Functional Application

Redundancy

Above

Average

28.7

Business Process

Variety

Above

Average


Conclusion

Summary and outlook

conceptual foundation established

unified measurement model and

set of standard measures provided

measures defined (KPI catalog)

and (partly) validated for the

domain of IT architecture

initial measures defined (KPI

catalog) for the domain of business

architecture

process model developed and

reporting views created

gather more experience on the use

of the defined measures and

determine their practical relevance

develop methods for measure

integration (cross-layer) and

aggregation

define standards to support intra-

and inter-organizational

benchmarkings

What has been achieved What still needs to be done


Recommended reading

Business Architecture Management

An Architectural Approach to

Strategizing: Structure and Orientation

for Developing the Business Motivation

(Daniel Simon)

From Business Motivation to Business

Model and Beyond: A Customer Value-

Driven Approach

(Jörg Heiss)

Business Motivation / Model

Effectively Modeling Your Architecture

(Gerben Wierda)

Business Architecture Quantified:

How to Measure Business Complexity

(Christian Schmidt)

Building Agile Enterprises

(Marc M. Lankhorst / Bas van Gils)

Modeling and Measuring

Bringing Business Architecture to Life:

How to Establish Business Architec-

ture Practices in Your Organization

(Christian Schmidt / Daniel Simon)

Business Architecture for Niche-

Market Enterprises

(Tom S. Graves)

(and others)

Implementation

Using Capability Models for

Strategic Alignment

(Wolfgang Keller)

Can Culture Be Designed?

(David W. Gray)

Business Architecture for Change

Program Design and Planning

(Adrian P. Apthorp)

Business Execution

2015, XII, 304 p.,

84 iIllustrations

Springer

Management for

Professionals


References

[IEE11] IEEE Computer Society (Eds.): Systems and Software Engineering — Architecture Description

(ISO/IEC/IEEE 42010:2011). IEEE Computer Society, New York, 2011.

[JB79] Jacquemin, A. P.; Berry, C. H.: Entropy Measure of Diversification and Corporate Growth. The Journal of

Industrial Economics (27:4), 1979; S. 359-369.

[Le97] Lehman, M. M.: Laws of software evolution revisited. In: (Montangero, C. Eds.): Software Process

Technology – Proceedings of the 5th European Workshop on Software Process Technology (EWSPT ‘96),

Nancy, 1996. Springer, Berlin; S. 108–124.

[Ne06] Newman, M. E. J.: Modularity and Community Structure in Networks. Proceedings of the National Academy

of Sciences of the United States of America (PNAS), Vol. 103 No. 23, 2006.

[SB11] Schmidt, C.; Buxmann, P.: Outcomes and Success Factors of Enterprise IT Architecture Management:

Empirical Insight from the International Financial Services Industry. European Journal of Information

Systems (20), 2011; S. 168-185.

[Sc13a] Schmidt, C.: Measuring and Managing Enterprise Architecture Complexity. Sebis Workshop on the

Complexity of Application Landscapes – Models, Measures, Management (CALM3). Technical University

Munich, 17.01.2013.

[Sc13b] Schmidt, C.: How to Measure Enterprise Architecture Complexity: A Generic Approach, Practical

Applications, and Lessons Learned. The Open Group Conference, London, 21.10.2013.

[Sc15] Schmidt, C.: Business Architecture Quantified – How to Measure Business Complexity. In: Simon, D.;

Schmidt, C. (Eds.) (2015): Business Architecture Management – Architecting the Business for Consistency

and Alignment. Springer, Berlin.


References

[Sh48] Shannon, C. E.: A Mathematical Theory of Communication. Bell System Technical Journal, 27, 1948; 379-

423 und 623-656.

[Si15] Simon, D.: Demystifying Business Architecture. In: Simon, D.; Schmidt, C. (Eds.) (2015): Business

Architecture Management – Architecting the Business for Consistency and Alignment. Springer, Berlin.

[SM03] Schneberger, S. L.; McLean, E. R.: The Complexity Cross: Implications for Practice. Communications of the

ACM, 46 (9), 2003; S. 216-225.

[SF12] Simon, D.; Fischbach, K.: IT Landscape Management Using Network Analysis. In: (Poels, G. Ed.):

Enterprise Information Systems of the Future, 6th IFIP WG 8.9 Working Conference, CONFENIS 2012,

Springer, 2012; S. 18-34.

[SWS13] Schmidt, C.; Widjaja, T.; Schütz, A.: Messung der Komplexität von IT-Landschaften auf der Basis von

Architektur-Metamodellen: Ein generischer Ansatz und dessen Anwendung im Rahmen der Architektur-

Transformation. Informatik 2013 – Beiträge der 43. Jahrestagung der Gesellschaft für Informatik. Köllen

Verlag, Bonn (in German).

[SWK13] Schütz, A.; Widjaja, T.; Kaiser, J.: Complexity in Enterprise Architectures – Conceptualization and

Introduction of a Measure from a System Theoretic Perspective. European Conference on Information

Systems (ECIS), Utrecht, 2013.

[TOG13] The Open Group (Ed.): TOGAF (The Open Group Architecture Framework) V. 9.1.

http://www.opengroup.org/togaf, 2013.

[Wi12] Widjaja, T.; Kaiser, J.; Tepel, D.; Buxmann, P.: Heterogeneity in IT Landscapes and Monopoly Power of

Firms: A Model to Quantify Heterogeneity. International Conference on Information Systems (ICIS),

Orlando, 2012.

Thank you for your attention

Follow us on www.linkedin.com/company/scape-consulting-gmbh

Business Architecture Quantified - Assessing the ... · Business Architecture Quantified –...

Documents

Transcript of Business Architecture Quantified - Assessing the ... · Business Architecture Quantified –...