Enterprise Design, or Architecture, is both a method and discipline, for describing (or modelling) a business from various perspectives and at various levels of detail – both strategic and operational.

All the other methods that will be covered here are intended to be used within this overall descriptive framework and approach.

Enterprise Design, as a discipline, shares some of the same language as other architectural disciplines.  Enterprise Architects and Designers talk a lot about ‘blueprints’, ‘perspectives’, ‘views’ and ‘models’.  As with buildings, we are as much concerned about the ‘setting’ of the organisation, as we are about the design of the organisation itself, i.e. the nature of the environment it operates within.

Before I move on to describe the various building blocks of an Enterprise Design, a word about “IT Enterprise Architecture” and associated methods such as TOGAF.  Although these seek to describe the architecture of the enterprise or business, this is very much from the perspective of the IT domain.  Anything within the Business domain that is not directly related to IT tends to get ignored.  So if schooled in these methods, please be prepared to be ‘reframed’ by what follows.  Enterprise Design is about a lot more than IT.

Business Model

The business model (or ‘strategic architecture’) is the strategic view of the business – the value it is seeking to create; its target customers and the nature of the relationship with these customers; the delivery capabilities and resources required; and the cost and funding models for the business.

There are various business modelling techniques, all seeking to define and better understand the business or service that is being created, or changed.

In terms of an overall design framework, I would recommend adopting the Resource-Based View (RBV) of the firm and the Business Model Canvas.  Below this, there is a host of other business modelling techniques available for looking at a particular aspect of the business model, e.g. markets, Value Propositions, Business Capabilities and value creation.

Conceptual Model

The conceptual model is a high level visualisation of the business or business area; and how it will operate.

Typically, it takes the form of a ‘rich picture view’ – a visual representation of the vision, business model and primary flows and activities; supported by a short narrative describing its key features.  Here is a good example, produced by Dion Hinchcliffe, for the App Store:

The key thing about rich pictures is that they are unstructured forms of representation – they should take whatever form that best connects with those involved in the business modelling process.

They are particularly useful for those of us who’s preferred ‘representational system’ is visual – which is most of us.  In creating a shared vision for the business, their effect can be very powerful.

Operating Model

The Operating Model is a holistic, systemic model of how the business is currently being delivered (the ‘present state’), and how it will be delivered in the future – the ‘future state’, or Target Operating Model (also referred to as a ‘Target, End State Architecture’, or ‘Blueprint’).  It can cover a single service, multiple services, a single business area, or the business operation as a whole, including strategic partners and the extended enterprise.  It is for you to define the ‘system of interest’.

The Operating Model is derived through a set of architecture perspectives or ‘Views’; and the all important relationships between them.  These perspectives are typically grouped under Business, Data and the IT domains of Application and Technology (BDAT).

The design process is driven from the Business domain, with the Data and IT Architecture domains acting as enablers, e.g. as you design the Business domain, you PULL enabling IT into this domain, seeking the optimum use of technology for your business.

The Business design domain has a number of sub-domain views.  The primary ones are: Business Capabilities; Value Streams, or Business Services; Customer and Employee Experience; Business Processes; Business Objects (the real world things used within the business); Policies; People (Organisation) and Location.

Against these design domains, various ‘Viewpoints’, can be produced, including viewpoints that define the relationships between each of the domains, e.g. Business Capability to Process (‘realised by’), Process to Business Object (‘created/used by’).

More specific viewpoints can also be produced, that focus on a particular aspect of the design, e.g. you might choose to view the system from a Environmental Impact, Health and Safety, Security or a regulatory perspective.

An important characteristic is that viewpoints are a 360 degrees view of the enterprise – outside-in and inside out; and covers the extended enterprise, i.e. the organisation and its strategic partners.

The Operating Model is first developed as a high level design; and then taken forward through successive phases of logical, detailed and physical design and implementation, through a set of individual service designs.

An obvious question is where do you start?  Traditionally, a process-driven approach was adopted.  In more recent years, with the development of the Business Capability view of an organisation, this has been replaced by a Capability-driven approach, i.e. based on your business strategy/model, you first develop your Business Capability Model; and it is against this that all other views are produced, based on the business processes, people and IT required to deliver the Business Capabilities and Core Competences you require.

Roadmap

The ‘roadmap’ describes the temporal dimension (or perspective) of a business or service – how the business or service, by design, is intended to change over time.

There are many factors that can drive this aspect of the design, e.g.:  planned changes in regulation; predicted changes in customer needs as the service is deployed; planned changes in other parts of the ‘system’; and constraints surrounding the deployment of the service itself.  Anyone familiar with the Amazon business model will be aware of how important this aspect can be.

This temporal dimension is represented as a roadmap, or ‘time-line’.  It is the roadmap that provides the link between design and the process of building and deploying a service into its operating environment.

Roadmaps typically consist of a visual representation of the timeline; with a supporting narrative covering its key features, including any external dependencies.  This is then developed into a more detailed ‘Transition Architecture’.  The end result is a current state and target state view, with a roadmap of how you are going to get from ‘A’ to ‘B’; and to all points in between.

The Roadmap should subsequently be used to drive an organisation’s business change portfolio/s and projects; which in turn should update the Enterprise Architecture and Roadmap; in a continuous cycle.The EA design process should never be considered as linear, rather it should be viewed as a non-linear ‘agile development’ process, based on concurrent and iterative development; and incremental delivery.

Taken over the whole life of a business or organisation, the design life-cycle should be viewed as a never ending process, of design, continuous improvement and redesign, against the ever changing business environment.

Design Principles

In defining the enterprise design, the establishment of a set of Design Principles is an early, and very important step.  They provide the guiding principles that will shape the nature of the organisation and how it will operate; and guide the design process thereafter.

Typically, there will be design principles that are strategic, relating to the business as a whole, and others that relate to more specific aspects of the business and individual design domains.

Design principles are particularly useful (if not essential) where the development and/or delivery of the service is highly distributed and/or incremental.

Below the design principles, you will often find more detailed guidance being produced, in terms of style guides and the like.

Design Patterns

Designing and building anything from scratch is time consuming and costly.  Few, if any businesses, are architecturally unique at every level of their design.  There will always be elements that are common to other parts of the organisation, or available externally as re-usable components.

Enterprise design uses ‘Design Patterns’ to capture architectural design ideas, as archetypal and reusable design elements.  These can exist at all levels of design – conceptual, logical and physical.  And you will find Patterns being used in all the design domains.

A Pattern needs to be truly a Pattern.  Just because something already exists does not make it a pattern.  It needs to be truly applicable/transferable into a different context, without the need for expensive modification, or by compromising other design elements.  I have seen this error being made many times, e.g. with shared services and in the use of ‘off-the-shelf’ IT applications.

There is also the concept of ‘anti-patterns’, i.e. patterns that are defined specifically to stop undesirable approaches that erode or compromise the delivery of the target end state; and may result in the creation of ‘architectural debt’.

First Published: 14/11/2011
Last Updated: 09/11/2019