Enterprise awareness

This article extends the thinking outlined in Enterprise Development which encompasses those
capabilities required by an enterprise to support its adaptation, development, or transformation towards its
intended future state. It explores enterprise awareness as a key capability within the enterprise
development domain, and considers enterprise awareness in terms similar to those of individual selfawareness.
This is the first real expression and articulation of the thinking around enterprise awareness. I expect that
further discussion and exploration will lead to progressive refinement and expansion of the thinking around
this concept and its application to enterprises and their development. I would like to acknowledge Doug
McDavid who prompted this thinking through his long-standing advocacy for the value of establishing
and maintaining a repository of the architecture of enterprises.

Concept
When we are more self-aware as an individual, we are able to act in more effective ways in challenging
situations. In this regard, I am suggesting that when enterprises are more self-aware, they are more able to
recognise and respond appropriately to situations they encounter, whether these be threats or opportunities.
In effect, an enterprise is more able to sense, respond, adapt, transform or develop:

than it would with lesser awareness

then other enterprises in the environment in which it is
operating.

Application
What is required to be more enterprise-self-aware? In its most simplest form, it is to be aware of its
existing and potential capability.
How often do we encounter:

The left hand does not know what the right hand is doing.
The divisions are silos with no collaboration between them.

 Duplicated capabilities in different parts of the organisation

These and other similar situations are symptoms of an insufficiently self-aware enterprise.
What does it take to redress this situation?

Some minimal diligence in maintaining models and views which

reflect the way in which the enterprise is organised and operates
A place where these models are visible across the enterprise and
able to be explained and shared as part of the enterprise
narrative
An assurance mechanism which monitors the maintenance of
the models and views and the quality, integrity and usability of
their representation
Appropriate skills and experience to provide support for this
activity to occur in a sustained manner

Implementation
If this makes sense to you, you might be asking how you might explore and apply this concept to your
enterprise? There are a number of minimum essential elements to consider and pursue:

Leadership
Learning and development
Scalability
Leadership
Developing enterprise awareness requires leadership to effect a cultural change which creates an
environment in which enterprise awareness can develop and thrive.
An effective starting point is simply for the Executive team to test their own shared awareness and
consistency in understanding and expressing:

the business model(s) underpinning their enterprise

 the operating model for their enterprise

the desired culture and values for their enterprise
the means by which the performance of the enterprise should be
assessed
Failure to be able to do this in a consistent and coherent fashion prompts serious questions as to how well
others in the enterprise understand these fundamentals about the enterprise.
Exploration of the differences and development of a consistent expression with a shared narrative will then
enable the Executive team to undertake this process with their direct reports. There will need to be, in
conjunction with this activity, an organised way of recording the shared expression of the business model,
operating model, values and principles, which can be used in common by all who engage in the progressive
development of greater enterprise awareness.

Learning and Development

As the enterprise leadership engages in establishing greater enterprise awareness and greater enterprise
alignment, the recognition of differences in understanding and practice are part of learning about the reality
of the enterprise, and about deficiencies in its current organisation to achieve its desired goals and
aspirations.
This is part of a self-discovery and learning journey. It should be treated as an open enquiry process where
no participant is "wrong" and where no "blame" is attached to the existence of differences. These value
arises in appreciating the differences and being able to attend to them, as they are, in part, one of the
fundamental reasons that the enterprise is unable to realise its aspirations and its full potential.
Deficiencies in the current business model(s) and operating model will prompt revisiting of business
strategy, which in turn will require the development and transformation of the enterprise to realise revised
business strategies, business model(s) and the associated operating model.

Scalability
The approach which have been outlined can be applied to any "enterprise". This means that it can be
applied to:

an entire organisation
a division within an organisation
a team

 a cross divisional function (eg. people management system)

a cross organisational system (eg. criminal justice system)
For each, it is entirely appropriate to consider:

business model (customers, services, channels, value

proposition, capabilities)
operating model (operations, development, resources and
governance)
culture, value and principles
For enterprises that are part of an organisation, there will be a need to determine the manner in which the
enterprise integrates with other parts of the organisation. This may prompt a broader approach being taken,
having determined that value has been derived in considering a smaller part of the organisation.

Facilitation
How might you facilitate the exploration of your enterprise and its self-awareness?
There are often a range of people within enterprises who are well placed to support such an activity. These
include staff in the following functions:

Business strategy
Organisation development
Quality management
Business architecture
If your enterprise is not of sufficient size to have these positions, then a consultant with appropriate
understanding of the architecture of enterprises could facilitate such an activity.

Enterprise architecting
If enterprise architecture is about developing descriptions of the architecture of an enterprise, then what is
involved in the practice of architecting an enterprise? You may be surprised to learn that architecting an
enterprise is not simply a case of creating descriptions of the architecture of an enterprise!
But then, you knew that there was more to architecting than creating architectural drawings, so perhaps you
weren't surprised, after all?
Creating architecture descriptions of an enterprise is the work of an enterprise draftsperson, not an
enterprise architect

So what should we expect an enterprise architect to do? How might we assess the work of an enterprise
architect?
As with all architectural disciplines, there are a number of common themes or dimensions that we can
explore:

Managing complexity
Realising intended outcomes
Ensuring integrity and coherence

Managing complexity
In common with all other entities that are architected, enterprises are complex. This has a number of
implications:

The design of an enterprise will necessarily involve more than

one person
The realisation of the enterprise design will necessarily involve
more than one person
The design and realisation of the design will most likely take a
significant amount of time
The design and realisation of the enterprise will require a variety
of people, bringing different design and realisation skills.

Given these factors, we need an approach to the design and realisation of the enterprise which best
addresses:

The ongoing integrity and coherence of the enterprise design

across the myriad of players involved in the planning and
delivery of the intended enterprise
The management of the design and realisation in a manner
which can accommodate changes to the design in the course of
its realisation
The execution of this activity in a timely and cost-effective
manner, avoiding the delivery of design decisions too late or at a
cost which makes the enterprise non-viable
Architecting involves partitioning the enterprise into interconnected subsystems such that:

the enterprise has greater flexibility and capacity to adapt in the

face on changes in its external environment
the need for subsequent re-partitioning is minimised, reducing
the need for significant rework, additional cost and increased
delay
the subsystems can be more independently designed with
greater likelihood of achieving integrity and coherence of the
realised enterprise

Realising intended outcomes

In designing enterprises and complex systems, the early design stages have significant implications for the
final cost of the enterprise or system. The longer it takes to determine that design faults exist, the higher
the cost of rectifying the fault and achieving the intended outcomes.
Architecting entails an understanding of the relationship between structure and behaviour, between design
and outcomes.
Just as a building architect establishes a vision of the owner and occupant experience, so the enterprise
architect starts with understanding the enterprise outcomes, the customer experience, the stakeholder
outcomes, the employee experience.

Just as a building architect establishes structures to create the spaces most appropriate to occupant use, so
the enterprise architect establishes the appropriate combination of values, principles, culture and structure
to create the stakeholder experience and outcomes envisaged by the enterprise.
Understanding these relationships enables the design and realisation of enterprises at lower cost and risk,
with higher likelihood of realising their enterprise goals and aspirations.
The critical design decisions are the real work of the enterprise architect, ensuring that the intended
enterprise design is affordable, achievable and capable of realising its goals and aspirations.

Ensuring integrity and coherence

The creation of the initial design is not the end of the job.
Circumstances change. Assumptions are proven not to hold. Humans make mistakes. Enterprise
transformation programs require adjustments to the enterprise design. The enterprise design is
misunderstood, intentionally or unintentionally changed. New stakeholders emerge. Multiple people are
involved.
Ongoing attention is required to the architecture and design of the enterprise to ensure the optimum
integrity and coherence of the realised enterprise. Enterprise architecting involves the design decisions and
the creation of descriptions of the architecture of the enterprise such that all involved best understand their
contribution and that of others towards realising the intended enterprise.

Enterprise architecture principles

This is part of a series about Enterprise Architecture - plain and simple. One of the questions that I posed in
the opening posting was:
What principles underpin the thinking and practice of describing the architecture of enterprises?

You might recall that the definition of architecture provided within ISO 42010 is:
Architecture = fundamental concepts or properties of a system in its environment embodied in its
elements, relationships and in the principles of its design and evolution

This points to one of the valuable elements of an enterprise architecture description being the articulation
of the principles underpinning the enterprise and its design. Such statements are the essence of "plain and

simple". They convey powerful guidance to any subsequent design activity with assurance that their
adoption will contribute to realising the goals and aspirations of the enterprise.
To that end, it became evident to me that any attempt at conveying "Enterprise architecture - plain and
simple" should encompass suggested principles by which the activities involved in developing and
sustaining the descriptions of enterprise architecture should operate.
The following is very much a first draft. They are presented in an accepted format which entails:

Statement (of principle)

Rationale (for principle)
Implications (of principle)
I expect challenges, discussion, debate. I expect to refine these principles. I expect to add other principles.
I expect that these may provide a simpler way of conveying some of the essence of architecting
enterprises.

Architecture is an act of organisation / management

Rationale
Management are responsible for establishing the structure of an
organisation to most effectively realise their goals and
aspirations
Organising includes establishing structures, allocating
responsibilities, monitoring performance
Implications
Enterprise architecture "services" must never be seen to be
taking over the responsibilities of management.
Enterprise architecture "services" must engage Executive and
management as owners and those accountable for the
enterprise architecture

Enterprises may be viewed as systems which exhibit

architecture
Rationale
Enterprises may be viewed as systems since enterprises satisfy
the description and minimum conditions for a system
All systems exhibit an architecture
Implications
Enterprise architecture must not be positioned as the sole means
by which an enterprise can be understood, designed and
managed
Enterprises may be viewed, designed and managed through the
lens of systems and architecture (as one amongst a number of
lines of thinking)

Enterprises are social systems

Rationale
Enterprises are purposeful systems composed of purposeful
parts (a purposeful entity has the capacity to change both
means and ends)
Implications
Enterprises are dynamic with distinct differences from
deterministic systems which are non-purposeful systems
composed on non-purposeful parts
Enterprises are self-organising, self-architecting, self-designing,
requiring engagement and ownership by managers

 Social systems entail significant flexibility for response in an

operational mode without the need for changing the design /
architecture
Social systems entail other dimensions in relation to culture and
communication

Enterprises are commonly socio-technical systems

Rationale
The vast majority of enterprises use a range of technical systems
/ technology to enable them to more cost-effectively deliver their
products / services
The operation of socio-technical systems constitutes a mixed
operation of social and deterministic systems
Implications
Architecture and design activities must be clear as to the
system-of-interest being architected / designed
Determination of the boundary between social and deterministic
systems requires consideration of:
the degree of autonomy / control required
the degree of flexibility / certainty
the nature of the solution as technical / adaptive

Enterprises can be viewed as systems of systems

Rationale

 A systems view encompasses parts, some of which (even for an

enterprise of one person), are systems in their own right
A system of systems is also a natural consequence of hierarchy
which is commonly observed in systems
Implications
Systems and architecture views are not the only school of
thinking which informs the organisation and management of
enterprises
Architecture and design activities must be clear as to the
system-of-interest being architected / designed
Any system of interest can be viewed as a part of the containing
system which requires attention as changes in the containing
system can have implications for the viability of the "contained"
system

Structure influences behaviour

Rationale
Structure and behaviour are inter-related dimensions of a
system, structure reflecting system parts and their relationships,
behaviour reflecting properties of a system
Implications
This principle has implications at many different levels
Language is a structure which has implications for how we
think and how we communicate - it can be an unrecognised
constraint on our perceptions, understanding, thinking,
communication and behaviour

 Strategies and policies create structures within which we

expect enterprises to operate -they can range from
enabling to disabling in their effects
Processes are established to achieve improved outcomes
through more consistent behaviour
Optimising one part of a system does not necessarily lead to
optimal outcomes - improved performance requires attention to
an appropriate structure to realise the intended outcomes.
Changes to systems may have unintended consequences, either
due to unexpected outcomes from internal changes or external
interactions
Balance and feedback
Rationale
The viability of a system requires information flows which enable
an appropriate balance to be maintained
Implications
Enterprises require an effective balancing mechanism to address
demands for change arising externally and internally
Enterprises require an effective balancing mechanism in relation
to resources and performance
Enterprises require an effective balancing mechanism in relation
to reliability and resilience vs agility and adaptability
Enterprises require an effective balancing mechanism in relation
to autonomy and control

Architecture in the Boardroom

explore some of the challenges facing Directors and to explore how the development and maintenance of
an architectural representation of an enterprise might contribute to better dealing with these challenges.

Issues facing enterprises

Different enterprises face different issues. However, some issues faced in common by enterprises where
systems and architectural thinking can offer value include:

The increasing amount of time which seems to be consumed in

dealing with compliance, taking time and attention away from
more strategic issues
The increasing degree of market disruption which requires more
frequent attention to strategic directions and strategic
capabilities, but also highlights capability gaps in effecting
change in a timely and effective manner
The increasing need for holistic responses in government and
across sectors (public, private, community) to local and global
issues, requiring a capacity to integrate and collaborate with
other enterprises
The inadequacies within enterprises in readily and rapidly
assessing and mitigating enterprise and change maturity gaps
as the enterprise seeks to execute business strategy and
manage change risks
The low maturity within their enterprises in effectively
integrating business and technology based change, and in
addressing impacts of volatility, uncertainty, complexity,
ambiguity

Issues for Directors

These enterprise issues have implications for Directors' responsibilities in the areas of:

 Strategy
Risk
Monitoring
Strategy
Change in the market / environment in which enterprises operate requires attention to business strategy.
The rate of change means that the traditional approaches of articulating visions and missions are no longer
suitable. The notion of a destination (vision) and a journey to this destination is no longer viable because
the world has radically changed by the time the enterprise arrives.
Market strategy is often better addressed through ongoing attention to the business model(s) which the
enterprise pursues. The discipline of attending to the business model keeps the enterprise focused on
product / service offerings which offer a compelling value proposition to the target customers, and
exploring the most effective channels for delivery of the products and services.
Attention to the business model also prompts enterprises to consider the manner in which technology may:

disrupt existing business models or open up new business

models
allow disaggregation of the value chain for the product and
services, focusing on those elements which exploit the capability
strengths within the enterprise
enable provision of complementary digital products / services
which enhance the value proposition for customers
Risk
There seem to be countless stories of failure in relation to:

business strategy execution

business transformation
project delivery (ie. the effecting of change)
Failure in business strategy execution can either mean deficiencies in business strategy development or
strategy execution. This may also indicate low maturity in the change management capabilities of many

enterprises. The increasing degree of change means that enterprises have no choice but to devote more
resources to effecting change, yet the low maturity of change capabilities does not seem to feature in
corporate risk registers. This, perhaps, is a blind spot for many enterprises.

Monitoring
How often do Boards develop or approve business strategies, without establishing the means for assessing:

strategy execution performance

enterprise development and adaptation performance
Development of business strategies incorporating expression of the intended:

business model
operating model
enables the identification of appropriate indicators for monitoring the degree to which:

intended outcomes are being realised

expected capability performance is being achieved
transformation risks are being managed

Architectural representations
Two of the most valuable architectural models:

business model
operating model
can be applied to undertaking enterprise transformation, whether a part of an organisation, an entire
organisation, or across multiple organisations. Each of these models are outlined in more detail in the
associated link.
These tools bring a discipline to the transformation which reduces the risk of failure and enhances the
likelihood of realising the desired outcomes. These are exercised by an emerging cadre of enterprise
change professionals with experience in architecting enterprises.

This is the first in a series of articles for Directors, Boards and governing bodies.

Exploring business models

This article extends on my first article about business models, where I outlined the key elements of
such models and the value in developing such models. This article explores:

the use of business model thinking for any system within an

organisation
the relationship of the business model to other familiar
techniques
the different considerations that arise in different enterprise
contexts, with some specific examples

Systems within the enterprise

Traditionally, the concept of developing a business model has been applied at the enterprise level, inviting
exploration of customers, products/services, value propositions, channels (on the output side of the
business) and suppliers, partners, activities / capabilities (on the input and production side of the business)
and developing a financial model that reflects an appropriate outcome (break-even or profit, depending on
the type of enterprise).
These concepts can just as legitimately be considered for any system within the enterprise, whether that is
an enterprise capability or an organisational unit. It might be a particular "line of business", a "shared
service", or a support function. Taking people (or human resource) management as an example, it is
feasible to consider:

the HR Branch (or organisational unit) providing products and

services to the enterprise as customers with appropriate
consideration of value propositions and channels, etc
the people management capability as a whole across the entire
enterprise providing products and services to employees and to
managers as customers with appropriate consideration of value
propositions and channels, etc

Care needs to be taken in such treatments. For the HR Branch, there is the risk of assuming its continued
existence, whereas the people management capability model allows consideration of alternate sources for
products and services. A genuine exploration of services and value propositions should test these against
competitors (or other options) in either scenario.
This is not novel. The application of customer service thinking to corporate services occurred several
decades ago now. For those with experience in such initiatives, it should be easy to recognise the focus as
having been the "enterprise" or "system of interest", to which the business model can be applied. This
demonstrates the value of applying this "business model concept" in a fractal manner to any designated
system-of-interest. As such, it can be applied to any identified system-of-interest or organisational unit.

Relationship to other techniques

Whilst I was familiar with business-model-as-financial-model, I had not encountered the Ostwerwalder
analysis and structure until about two years ago. Prior to that, along with many other architects, I had
applied a range of traditional modeling techniques to the enterprise.
The simplest technique involved the use of a Context Diagram, placing the enterprise as the system-ofinterest, and showing the external relationships to suppliers, partners and customers, each of which are
considered in the business model .
As I started to explore value chains and value streams, it became evident that I could apply models used in
Six Sigma and Lean thinking, in particular SIPOC, by considering the enterprise as a single process (P),
and showing the suppliers (S), inputs (I), outputs (O) and customers (C). This was (and is) a useful tool in
making explicit these elements of the enterprise, as is the case when developing an expression of the
business model. Then, the core value stream could be expressed as a series of inter-connected SIPOC
models as the next level of decomposition.
Another model which I have used is IDEFo, providing a different perspective by treating the enterprise as a
function, and reflecting the inputs, outputs, controls (governance) and mechanisms (processes) which
underpin the function. Again, this model reflects some elements in common with the business model
concept.
Each of these techniques demonstrates how the applicability of a system-related model to the enterprise,
many of them paralleling elements that are included in the business model concept. Analysts familiar with
these techniques will be readily able to apply them to enterprises.

Application in different settings

There are different and distinctive differences in business models applied to different sectors. Some
assume that business models are not applicable to government and community sector organisations. The
following outlines some of the differences and demonstrates that the business model concept offers utility
and value in all enterprise settings.

Public sector enterprises

These enterprises operate in more complex environments, where additional considerations are necessary.
Yet, the same concept and general principles can be applied, and potentially deliver additional value by
establishing greater clarity and understanding of the way in which these enterprises can address the goals
and objectives which communities set and expect of them.
The most obvious differences are that often public sector enterprises:

are not required to make a profit or realise a return on assets or

investment
do not derive their income (revenue) from their customers
do not have choice as to their client / customer base
are measured on outcomes rather than outputs
(I may write a separate article to elaborate on these differences, as they are fundamental to better
understanding the differing management challenges facing public and private sector managers.)
Business models are able to be accommodate these differences, as long as appropriate consideration is
given to distinguishing between:

customers and consumers - customers being those who pay for

products / services and consumers being those who use the
products / services
treatment of income versus revenue, and profit/loss versus
surplus/deficit
outputs and outcomes - the latter arising as an effect of the
existence or use of an output
In order to treat these elements appropriately, greater attention must be given to:

the use of language and terminology

the varying stakeholders who may have interests and be
beneficiaries of the enterprise beyond simply considering
customers

 the varying value propositions and benefits which may be

afforded to the differing stakeholder groups
For example, I find it helpful to consider the following dimensions:

Financial dividends (afforded to owners and shareholders)

Economic, social and environmental dividends (afforded to other
stakeholders)
Balancing of value propositions for owners, customers and
employees (at a minimum)
Each of these can be explored and expressed in an enhanced business model representation.

People management as an enterprise

This provides an example of applying business model analysis to part of an organisation as opposed to an
entire organisation. Whilst it is feasible to consider the HR organisation unit, it is often wiser to consider
the entire people management capability or system, as there are elements of this system within the role of
every manager and executive, in addition to any specialist services which the HR organisation unit may
provide.
In considering this capability or system, the business model concept prompts consideration of:

customers - Executives, managers, employees

services - from workforce planning and industrial relations to
payroll
channels - face to face, phone and online / self-service
suppliers and partners - providing specialist services
capabilities required to deliver the various services
An important element in this process is applying a combination of the business model concept and systems
thinking concepts. It is common in support functions to seek to optimise a particular function, when it is
only part of the whole, and optimising a part may result in sub-optimal outcomes from a broader enterprise
perspective.

This is one of a number of articles in the series "Enterprise architecture - digging deeper".

Operating models
This is an article in the series "Enterprise architecture - plain and simple ".
In the article on elements of the description of current or intended architectures, I referenced a number of
key models that I use. The first and primary model is the business model, described in another
article in the series.
Whereas the description of business models seems to have become more consistent through the application
of the ontology developed by Alex Osterwalder, I am not so confident that there is a clear ontology or
framework for operating models.
There is research and thinking which has occurred in the area of operating model design. Andrew
Campbell of Ashridge Business School runs courses on operating model design and publishes a blog on the
topic - Ashridge on Operating Models. He and I have exchanged views and explored the
relationship between enterprise architecture and operating model design. We have already published one
article on the topic of enterprise architecture - see Why business managers should
understand enterprise architecture. We have only a little further to go before we could
confidently say that we have shared views in this domain. That represents for me, an interesting challenge
and a great learning opportunity!
As I have explored the high level models that different practitioners develop, it has become evident that
different frameworks (whether individual or commercial) adopt different ways of conceiving of the primary
systems of which an enterprise is comprised. The highest level abstraction of the systems of which an
enterprise is comprised, then "sets the tone" for all subsequent elaborations.
In this article, I will simply share some of the patterns and models which I have used quite successfully
with a variety of clients. I do not pretend that the framework that I use is any better than any others. I will
outline the rationale for the framework and leave it to readers to ascertain whether it seems to provide a
satisfactory basis for further development to reflect the operating model for enterprises with which they are
engaged.

Purpose
The primary purpose of an operating model is to express the means by which an organisation:

pursues its enterprise

 realises its goals and aspirations

achieves and sustains viable operation

Enterprise system
There are four key systems forming the expression of any enterprise-as-system that I consider:

1. Operations management system

2. Resource management system
3. Governance and management system
4. Development management system

For
many years, I have only addressed systems 1 to 3. Typically, I have not addressed the development
management system, because:

 I was usually part of this system

the development management system was usually embedded in
the other systems
However, with the increasing degree of change, I am finding that more enterprises are recognising the
development management system as a distinct system. This can be seen in John Kotter's article
- Accelerate! - where he outlines the case for a dual operating system. It can also be seen in the
increasing profile of Program Management in enterprises and in enterprises where they have established a
Chief Operating Officer and a Chief Change Officer.

Operations system
This system is the core system which produces the products and/or services of the enterprise. It is most
commonly represented as a value stream, reflecting the core capabilities by which the enterprise transforms
inputs into outputs and delivers value to its customers and consumers.
This system may also include support systems which are not part of the primary value stream. These may
be systems which require specialist capabilities and are required by different systems in the value stream
and deliver internal products and services beyond those provided as part of resource management.

Resource management system

This system manages each of the resource types required for successful operation of the enterprise. At a
minimum, this will encompass:

Human resource management

Financial management
Information management
It may also include:

IT management
Asset management
Procurement, contract and materials management
Record management

Governance system
All enterprises require governance and management.
With respect to governance, I have drawn on the Tricker Model which is one of the models covered within
the Company Directors Course run by the Australian Institute of Company Directors. By drawing on this
model, I know that there are many Directors and Boards who will be familiar with the model and therefore
comfortable with the subsystems that I include:

Accountability and reporting

Strategy
Policy
Performance reporting
Strategic risk management
To date, I have not modeled the management system. It seems to be adequately covered by the
management embedded in each of the systems that I consider. I have included reference in this area governance and management - to allow for inclusion of additional capabilities that become evident and
require attention beyond those evident in all other areas.

Development system
This system supports the development of an enterprise and effects change in any of the systems. Change
may derive from strategy, as the means by which strategy is executed, or from individual systems as part of
continuous improvement. It includes:

Architecture management
Program management
Project management
Change management
Program and project support
I view change through a lifecycle lens taking change from idea to realisation. Key steps include:

 Initiative formation
Investigation
Acquisition
Design, build and test
Implement
Review and close

Conclusion
Overall, this conceptualisation of an enterprise-as-system has enabled successful:

development of architectural models

formation of program strategies, plans and roadmaps
It seems to prompt reasonable coverage of the activities of any enterprise and it seems to be easily
understood by stakeholders with whom I engage.

Other postings in the series

Enterprise architecture - plain and simple

Why bother with EA?
Value propositions for EA
Enterprise as system
Enterprise architecture principles
Elements of architecture descriptions
Conventional practices

 Architectural sufficiency
Enterprise architecting
Business models

Since this completing this series, I have started another series - Enterprise Architecture - Digging Deeper.
This series includes the following articles

Business models
The concept of business model is relatively recent, emerging in the 60's and gaining greater attention in the
90's and succeeding decades. The different lines of thinking were subject of review in 2004 by Alex
Osterwalder, who developed an ontology for understanding and expressing a business model. This
ontology has provided the basis for development of a number of tools for expressing business models, the
most well-known being Business Model Canvas.
This posting explores:

the concept and value of the business model as a key artefact in

describing the architecture of an enterprise (AE)
potential areas for further development of this concept to
provide greater utility

Key elements
Key elements of the business model ontology include:

Value proposition
Target customer
Distribution channel
Relationship

 Value configuration
Capability
Partnership
Cost structure
Revenue model

Drivers
Looking at enterprises over the last 50 years, it is possible to see how their business models have moved
from being quite static to quite dynamic. This has occurred as a result of the increasing rate of change in
the business environment and internal organisation of capabilities.
A significant factor has been the increasing use of ICT in developing digital capabilities, complementary
digital products / services and use of alternate digital channels. This is evidenced in the increased attention
given to business models in the dot.com era where digital channels became available as an alternative
delivery mechanism. It is also evident in the current business model disruption arising from effective use
of ICT within the market in which enterprises operate, where digital services enable disaggregation of the
value chain, opening up new points of competition for an enterprise.

Value
One of the key benefits of the business model is that it presents a model which encompasses both internal
and external elements which underpin the viable operation of the intended enterprise. Consideration of:

value proposition, target customer, channels and relationship

give attention to factors underpinning the revenue / income
model and the balancing of stakeholder value with income
value configuration, capability, and partnership give due
attention to factors underpinning the expenditure / cost structure
Review and validation of the business model gives attention to the viability of the enterprise and provides a
suitable foundation for development of the supporting operating model.
I am encountering an increasing number of situations where enterprises are finding it necessary and
valuable to revisit the viability of their current business model(s), demanding that they change in order to
remain viable. In one case, a review of a transformation program led to identifying deficiencies in their
intended operating model, which led to identifying deficiencies in their intended business model. Their

failure to recognise and address the business model issues has led to the failure of the enterprise (going into
administration last year).
Attention to the business model gives cause to consider the fundamentals underlying the market strategy
for an enterprise and the corporate / development strategy for an enterprise. Developing a transformation
program for a flawed business model is a recipe for disaster and for wasting valuable change investment,
both personal effort, energy and enthusiasm as well as financial. Attention to the business model also gives
cause to consider the balance between changes to the market strategy versus development strategy.

Developments
There are two areas of development that I see occurring:

viewing the external environment in systems terms ie as an

ecosystem
viewing the internal elements in systems terms
In the past, there has been a tendency to consider entities in the external environment relatively
independently. With increasing market disruption, viewing the market as the containing system gives
recognition to interactions occurring in the market that have implications for an enterprise that were not
previously considered because the interactions were not directly with the enterprise.
From what I have seen, the use of tools such as Business Model Canvas prompt consideration of the
various internal elements of an enterprise, but this does not require the elements to be considered through a
systems view, recognising that there are interactions which require consideration of the "whole" and not
just the parts.
In bringing a systems perspective, this also introduces the opportunity to apply:

elements of systems thinking to the enterprise

the Viable Systems Model to the enterprise
business model thinking in a fractal manner to subsystems
within the enterprise

Practical application
It is probably worth adding that I have found that thinking about and exploring the business model of
various enterprises has been helpful, whether or not I am engaged in developing the architecture of the
enterprise. Cases in point include:

 LinkedIn Groups - considering the business model for LinkedIn to

provide context and understanding of the role and contribution
of LinkedIn Groups when it is not a direct part of the revenue
model for LinkedIn
My state of South Australia and nation of Australia - thinking
about how we are positioned in the global context, what
capabilities we have or need, etc, including contribution to a
group which considered the "innovation system" within our
nation, and another interested in "reinventing our nation"
Voluntary collaborations in which I have been a member and
contributor, helping the group to think about its goals and
aspirations, the outcomes it is seeking (value propositions), the
capabilities the collaboration needs and the areas to which we
need to give priority