Enterprise Design involves the systemic design of an enterprise from various perspectives and at various levels of detail, through to implementation. Business Architecture addresses the strategic design of the enterprise.
Business Architecture as a discipline shares some of the same language and concerns as other architectural disciplines. Business Architects talk a lot about ‘blueprints’, ‘perspectives’, ‘views’ and ‘models’. They are also as concerned about the ‘setting’ of the enterprise as the design of the enterprise itself, i.e. the nature of the environment it operates within. And also about the interaction of the ‘parts’, not just about the design of the individual ‘parts’, be it an individual service, technology or data product.
Before I move on to describe the various building blocks of Business Architecture, a brief word about “IT Enterprise Architecture” and associated methods such as TOGAF. Although these also 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 as an overall approach to enterprise design they are incomplete. If schooled in these methods, please be prepared to be ‘reframed’ by what follows. Enterprise Design and Business Architecture is about a lot more than IT, but it does not mean that these IT enterprise design framework are not of any value.
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.
The Business Model is frequently viewed as part of Strategy and indeed it is usually developed as part of strategic planning, but it also forms part of the Business Architecture and overall enterprise design.
There are various business modelling techniques, all seeking to define and better understand the strategic architecture of the enterprise.
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. Note that you may have multiple Business Model Canvases, one for each market offering/value proposition, and architecturally these need to be viewed both individually and as a whole.
Conceptual Model
The conceptual model is a high level visualisation of the enterprise or a particular line of business; 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:
Conceptual Model View
The key thing about rich pictures is that they are unstructured forms of representation – they should take whatever form is most meaningful with those involved in the enterprise. 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 enterprise, their effect can be very powerful.
Operating Model
The Operating Model is a holistic, systemic model of how the activities of the enterprise are currently being delivered (the ‘present state’), and how they will be delivered in the future – the desired ‘future state’, or ‘Target Operating Model’. 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 your ‘system of interest’.
The Operating Model is derived through a set of architecture perspectives, or domains. The language used varies quite a bit which can be confusing. I tend to draw on ISO 420020, which is an international standard for architectural frameworks. Here the Enterprise is defined as the ‘system of interest’. Each perspective is a “viewpoint” and each viewpoint has a “view” that consists of one or more architecture models that cover the whole system from that viewpoint.
The perspectives used can vary, but typically they will be ‘Process’ (i.e. the activity), ‘Organisation’ (or People), ‘Location’, ‘Information’, ‘Technology’ and ‘Security’. More specific viewpoints can also be introduced against this core set, 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.
The Business Architecture operating model design is carried forward into the Service Design, which designs each of the individual services through a process of logical to physical design and implementation.
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, you first develop your Business Capability Model; and it is against this that all other viewpoints and views are developed, based on the business processes, people, information and technology the business capabilities 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: 20/10/2025