A Quick Reminder
As discussed in Part 2, the business layer of the Enterprise Architecture focuses on the future needs of the business by describing what the business intends to provide to fulfil the needs of its external and internal customers (see the following diagram showing the business layer in the context of the full EA Grid):
Within the business layer are three key models covering behaviour, structure and knowledge, defined as follows:
- Services (Business Behaviour)
Shows the business services to be provided to the internal and external customers to fulfil the business vision and objectives, and models these services as well defined and self-contained processes.
- Organisation (Business Structure)
Shows how the proposed business services fit within the target organisation model, and how these services interact with one another to create the desired customer experience.
- Information (Business Knowledge)
Shows the information as understood by the business as a set of entities and includes the relationships between these entities. This information model needs to be supportive of the business services described in the Services model (and vice versa).
The Services Model
Although there will inevitably be a high degree of overlap between the three models in the business layer, the most effective place to start is with the services model. It is here that the true future intent of the business can be articulated in a manner that makes sense to the business, and that focuses on the business from a customer-centric point of view. The Services model tells us exactly what it is the Business intends to “do” for its customers.
Step 1: Domains
Starting with a large blank page (electronic or physical) first define your future business in terms of service domains. These service domains are high level grouping concepts that separate the services to be provided by your business into areas of interest. Think of them simply as boxes into which you will place your services so that you and the business can find them easily in the future (e.g. “Insurance”, “Financial Planning”). A typical domain model for even the largest of organisations should need no more than five to ten domains. If your business already has a good idea of where it is heading, and there is some form of vision statement to support this, this initial domain model should take no more than an hour or two to produce.
Step 2: Services
Now start populating this model with the services that you intend to provide to the customer (e.g. “Insure my car”). Approach this in a brainstorming fashion, focusing more on what the business wants to do and less on getting the names and positions on the model right (they can always be moved or renamed later). Keep going until the ideas start drying up and then review what you have, making sure you have captured the intent of each service to avoid misinterpretation later. Take an 80/20 approach to this task; there will be plenty of time to add the services you miss as you develop the model further. Provided you have the right people involved in this process (those with the authority to formulate the future vision) it should take no more than one or two days to produce the first cut of a fairly inclusive service model.
Step 3: Tasks
To flesh out the basic service model you now need to define the individual tasks that will need to take place to provide each of the services (e.g. within “Insure my Car” you might have tasks such as “Produce a Quote”, “Agree Terms”, etc). A question that often arises at this point is “when is it a task rather than a service?” I stick to the rule of thumb that a task is something that can be performed by a single person (or team) and could be performed between cups of coffee. Focus first on those that are deemed most important to the business’s value proposition, and on those that are felt to be the most “radical” in terms of business transformation. For an average service, separation into tasks should take no more than a day at most.
Step 4: Processes
To complete the service model you now need to describe exactly what has to take place to fulfil each task. In my experience, the best tool for this is the old favourite, process modelling. Agree first on the pre-conditions and post-conditions for the task so that the start and end points are well understood, and then describe the steps that need to be undertaken to complete the task. If you have divided your services down into the type of tasks described in step 3 above, each of these processes will probably only consist of a handful of steps (typically between five and ten). Again, for an average task, the initial process should be definable in less than a day.
During each of these four steps you will find that there is a strong tendency to fall back on “what we do today” whenever the going gets tough. As the Enterprise Architect it is important that you regularly ask the question “is this what you want to do in the future, or is this what you have to do now?”
The Information Model
Closely aligned to the Services model is the Information model which describes what the business will need to know to support the service it provides to its customers. This model should approach information from a business centric point of view, and not from a more traditional IT perspective (which is typically adapted for suitability to the applications, technologies and database approaches, and has little meaning to the business). The business should be able to look at the information model and instantly recognise the content in the context of their day-to-day activities, and it is for this reason that this is often the easiest model to populate.
Step 1: Domains
Essentially, the same first step as for the services model, but this time we focus on domains that allow us to group our information according to subject matter (e.g. Customer, Financial, Products, etc.). As before, it should be possible to complete this task satisfactorily within an hour or two.
Step 2: Entities
Now start populating this model with the information entities; the things the business wants or needs to know about. (If you know anything about database techniques and third normal form please resist the temptation to impose your data modelling “experience” on this activity). Approach this in a brainstorming fashion, focusing more on the core things that the business wants to know about, rather than the fine detail (this will come later in Step 4 below). Keep going until the ideas start drying up and then review what you have, making sure you have captured a description for each entity to avoid misinterpretation later. It should take no more than a day to produce the first cut of this model.
Step 3: Relationships
Information does not exist in isolation. Now that you have captured the main areas of knowledge, refine this model by adding the relationships between these entities. Be careful to only link those entities that have a genuine relationship to one another. Do not link entities to one another simply because your business intends to use the information in a related manner. (For example, a Contact will probably be related to a Customer, but just because you intend to use your Contact History information to develop a Customer Insight Model does not then mean that these entities are related to one another).
Step 4: Discovery and Use
As mentioned earlier, the Information model is closely associated with the Services model. Revisit the tasks in your Services model, and show where knowledge is used or captured by linking the process steps to the relevant information entities. Where necessary create new entities (and their relationships) to support knowledge that is described in the processes, but has not yet been captured in the Information model.
In theory, it is possible to skip directly to Step 4, and use the your Services model as the core discovery tool from which to develop your Information model. However, in practice, you will find that your Business already has a well developed understanding of the knowledge it needs to support, and Steps 2 and 3 offer a more pragmatic and efficient approach to developing a draft Information model.
The Organisation Model
With the Services and Information model we have the basic building blocks for our business, but what we do not have is the overall structure to support this, and this is where the Organisation model comes in. This is not just an organisation hierarchy diagram; far from it. This model is more accurately compared to the London Underground map. By laying out the customer experience in the form of journeys with clear start and end points, travelling through stations representing the key business services used, we can show how these services interact with one another to create the desired result.
We can also recognise more clearly how our teams and departments may need to be organised to ensure that the customer journey is as smooth and efficient as possible, and to ensure that departmental handovers happen at sensible points in that journey. I do not recommend that this is approached as a single end-to-end activity. Instead, approach it in a demand driven fashion guided by the Business initiatives and projects whose needs are greatest. By adopting this approach you can assist with the development of projects requirements, ensure that the projects are aligned to the services in the Business Architecture, and leverage the funded resource assigned to the project.
Step 1: Journeys
The first step in joining up the pieces of our Business jigsaw is to identify and map out the journeys our customers are taken on as they use our services. Describes these as “stories” describing what the customer does, and what the Business does for them, and remember to consider the journey taken by the “virtual customer” as their information flows through our processes (not just the part of the journey visible to the customer) as this hidden journey impacts the customer experience. An example of a Customer journey might be that taken by a UK benefit recipient, which starts when they become unemployed and sign on for benefits through to (possibly) getting a new job and the benefit ending. Remember to model the journey you would like the Customer to experience, rather than the warts-and-all one they may have to take at present. Each journey will typically take a day to develop.
Step 2: Interactions
During a typical journey, a customer might interact with the Business on many occasions, and these interactions need to be identified and named. It is important during this step to recognise that although the customer journey might be unique, the interactions within it will probably re-occur in other journeys (for example, Make Complaint, Search for Jobs, etc.). Each interaction can then be modelled as a sequence of one or more business tasks from the Services model. The customer journey can now be added to the “tube map”. The journey itself represents the “track”, and the interactions are the stations along the way. Adding journeys to the tube map allows us to recognise where journeys join and separate and to understand how any departmental structures might cut across the journeys creating a more complicated customer experience.
Step 3: Organisation
As the tube map develops, there will come a point where it is possible to overlay the proposed business structure on this model. Consider the “zones” on the London Underground tube map and imagine these to be your business areas. You can now identify where it makes sense to handle customer interactions in call centres, and where expert teams need to (and can effectively) get involved. Symbols can be added to the “stations” to show where paper is created or destroyed to support your paper removal agenda (if you have one), or to draw attention to any other key events that you need to highlight. This one diagram brings everything together into a single big picture that shows the simplicity or complexity of your Business at the service and organisational level, and facilitates open discussions about the overall impacts of key Business changes.
And there you have it. The Business Architecture; done (as Gordon Ramsey might say).
Well, no... Not exactly. What you have done is started the reaction; what you have not done is reached the critical mass necessary to ensure that this activity does not simply fizzle out.
Your Business Architecture will have significant gaps that others can use to challenge its validity. Many areas will need further work to resolve conflicting requirements and ambitions. And of course, the vision for the future is not a static thing. It will change on a daily basis, and your architecture, as an articulation of this vision, must adapt to its twists and turns.
Architecture is a living thing, and Business Architecture is no exception. You will need to continually revisit and refine to respond to the emerging challenges and the immediate imperatives for the Business.
Above all, you must use your Business Architecture, and you must make sure that others use it too. Not as an afterthought to test alignment, but as the core source of information to identify change initiatives, guide projects, and develop requirements.
You’ve just finished the easy part. From now on it gets physical.
The Enterprising Architect