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 self-awareness.

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.


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.


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


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


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.


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.


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.

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-of-interest, 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.

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


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.


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.


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


I have elaborated further on business models in a more recent article – Exploring business models.


Quality of business analysis?

It seems (to me) that many enterprises are facing difficulties in successfully planning and conducting business transformation and improvement initiatives due to the poor quality or even absence of fundamental inputs that good business analysis provides into the scoping, designing, developing and adopting of changes intended to improve the performance of these enterprises.

This prompts a range of questions:

  • Is this perception well founded?
  • If so, why is this occurring?
  • What can  be done about this?
  • If there are options, which are likely to be most effective?
  • How do we get started?
  • Who do we need to involve?
  • How do we measure progress or success?

I plan to explore some of these questions, but I am also interested in others’ perceptions:

  • Does this match with your observations and impressions?
  • Are there other related issues which need to be considered?
  • Are there other questions which should be asked?
  • What do you see as the critical elements to making a discernible difference?

I look forward to exploring this question further.



Changing risk profile

It is interesting to look back over nearly forty years of being engaged in business improvement projects with differing roles and responsibilities at different stages.  The profile of the IT elements of projects has changed significantly over this time.  Technology environments have evolved and involved:

  • mainframe
  • client-server
  • web-based
  • service-oriented
  • mobility
  • cloud based

Solution design and development has evolved through:

  • Various generation languages (remember 4GL?)
  • Bespoke software development
  • COTS (commercial-off-the-shelf) software
  • Configurable COTS
  • Cloud hosted configurable COTS

and many other different dimensions and variations!  Each stage of development has built products and capabilities that embed the previous level activities into the platform, moving platforms from operating systems to cloud-based configurable solution platforms such as those offered by Salesforce.com  A recent demonstration of a system for a disability entity indicated how reliable the underlying platform has become, enabling the development to focus much more on business need and business functionality.

The resource and risk profile for projects has changed considerably!  In the early years, the largest resource and risk was the software development activity. Now?  Well, now it’s the business change activity – determining how customers and staff can utilise the new digital service offerings, helping them to develop new skills and capabilities and transitioning to make most effective use of the new, dynamic digital work and customer spaces being created.

And so …  what were once software development projects, progressively became IT projects, and now are business change projects.

I wonder whether program and project risk registers reflect this shift in resource and skill demands?


Enterprise performance, productivity & competitive-ness

I have lost count of the number of times that I have heard people complain about how IT is undervalued, how the CIO deserves a place at the Executive table or at the Board table.  All too often this is because the proponents are unable to clearly and succinctly articulate the value proposition for the CIO function or for the more effective use of IT by an enterprise.

Combined with this, I also have lost count of the number of times that I have seen Board members eyes glaze over as soon as someone mentions that awful word “IT” or any of the associated technobabble.  Yet, these same people are often worried about the future of their enterprise and the impact of significant changes in the markets in which they operate, sometimes due to the capacity of their competitors to make more effective use of IT than they are able to!!

So, I have taken an interest in exploring and discussing these problems from a different angle, such as whether an organisation needs to be more innovative, and if so, how this might be achieved.

And in doing so, I have found that this brings me back to understanding enterprise performance, staff productivity and enterprise competitiveness.  Often times this then leads to thinking about the capabilities required by the enterprise, their adequacy for current and future demands, and ways in which the performance of particular capabilities can be improved.

Enter process innovation!

That is, here is where enterprise modeling comes and adds some value, by enabling an enterprise view of current and future capabilities and identifying the gaps, whether missing entirely or simply not performing adequately, identifying where the performance gap is and determining innovative ways of addressing this gap, sometimes involving process innovation.

And so, it has become increasingly evident to me that process innovation has a place in contributing to improved enterprise performance, improved productivity and increased competitiveness, and enterprise modeling offers tools, techniques, thinking models which enable an enterprise to tackle these sort of questions, these sorts of demands, these sorts of business change and transformation, most often combined with some commensurate systems transformation!

More business, less technical?

Enterprise modeling (or enterprise architecture) started off in the technology world, with the CIO and others needing to make sound investment decisions about enterprise wide infrastructure (such as mainframes, networks, etc).  These decisions involved resources which would support multiple change initiatives and where it would be “unfair” and “unjustifiable” for the initiating project to bear the full cost of the resource.  Equally, there was a need to ensure that these enterprise wide and longer-term investments would prove to be sustainable investments in situations where future project requirements were not well defined or understood.  Hence, the strong technical focus during the “childhood” years of enterprise architecture.

In its adolescent years, enterprise models incorporated business models AND technical models, such that the technical investments were informed by business considerations and were more “business aligned” or “business driven”.

In the early adult years (now), greater attention is being given to modeling business capabilities over technical capabilities.  Further, business architects are being more strongly valued and technical architects are being found  to be deficient in meeting the enterprise modeling needs in rapidly changing times, where businesses need to be able to respond to market disruptions in much shorter timeframes than was previously the case.

In such an environment, questions are starting to arise as to the balance of effort between modeling the business capabilities versus modeling the technical capabilities.   I recently indicated that I expected the demands for technical modeling would reduce due to greater use of “cloud services”, and then was given cause to provide the following explanation for why I thought so.

With the increasing alignment between business and technical capabilities, there will be less need to architect the technical capabilities. These will progressively become tightly defined capabilities which can be easily and effectively used by business capabilities.

Business agility will come through the flexibility to mix and match business and technical capabilities to meet changing market needs. Put a different way – agile businesses will become plug-and-play business capabilities with the supporting technical capabilities being enablers rather than barriers – architecture is needed moreso when there is poor alignment.

What do you think?