22 August 2012

EA Quick Start Guide (Part 4): "Application" - Reclaiming the Noun

In part 4 of my series introducing Enterprise Architecture, I will focus on the second of the three layers described in Part 2; the Application Layer. This is the layer in which we apply the components, systems and sources from our infrastructure layer to provide solutions to the needs we have articulated in our business layer. To properly understand this layer those of an IT bent must throw off their belief that an application is a piece of software. For those you are saying “yes it is” as they read this, perhaps a dictionary definition will help:

Application: noun
  1. A formal request to an authority: an application for leave
    [mass noun]: licences are available on application
    [as modifier]: an application form
  2. [mass noun] the action of putting something into operation: the application of general rules to particular cases
    [count noun]: massage has far-reaching medical applications
    practical use or relevance: this principle has no application to the present case
  3. [mass noun] the action of applying something to a surface: paints suitable for application on fabric
    [count noun]: a fresh application of make-upa medicinal substance applied to the skin: an application to relieve muscle pain
  4. [mass noun] sustained effort; hard work: the job takes a great deal of patience and application
  5. (also application program) Computing - a program or piece of software designed to fulfil a particular purpose: a database application
The application layer covers all solutions to a problem, be they IT related or physical in nature. A nominal ledger implemented on paper is as much an application as is a spread-sheet created to achieve the same outcome.

A Quick Reminder
As discussed in Part 2, the application layer of the Enterprise Architecture Describes the high level solutions that need to be provided to support the future intent described in the Business Layer (see the following diagram showing the application layer in the context of the full EA Grid):

As was the case for the business layer, within the application layer there are three key models covering behaviour, structure and knowledge, defined as follows:
  • Capabilities (Application Behaviour)
    Shows the internal application services needed by the business (including IT) to allow it to undertake the processes described in the Services layer.
  • Solutions (Application Structure)
    Shows how the application services interact with one another to fulfil the needs of the Organisation model and thus provide the desired customer experience.
  • Data (Application Information)
    Shows the detailed data elements and relationships required to support the Information model. This data model is derived from the Information model, but at the same time, needs to be supportive of the application services described in the Capabilities model (and vice versa).
I have already recommended that a good architect starts in the corners of the EA Grid and works inwards, and following this principle I will now describe the individual models within the application layer starting from the edges. However, it should be noted that a degree of overlap in the development of these models will be beneficial to ensure that no one model is created without the benefit of at least an overview of how the other two models are evolving.

The Capabilities Model
Starting with the capabilities model provides a framework onto which you can hang your solutions and data. As for the services model in the business layer which articulate the future intent of the business, the capabilities model articulates the application services that will need to be provided (regardless of implementation approach) to fulfil this business intent. The approach taken to producing this model is very similar to that adopted in developing the business service model, but with a slightly different focus. Where in the business layer we focussed on the services provided by the business to the customer, in the application layer we focus on the generic services (or capabilities) that will need to be provided within the business to fulfil the business services. Also, where in the business service model our primary audience was the strategy and analysis community, in the application capability model our primary audience is the design community. As an example, in the business layer we might consider a service that allows us to accept and manage customer enquiries; in the application layer we might consider a generic contact handling capability.

Step 1: Domains
As for the business service model, start with a large blank page (electronic or physical) and first define your capability model in terms of service domains. These domains are high level grouping concepts that separate the application services to be provided within 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. A typical domain model for even the largest of organisations should need no more than five to ten domains. In the business service model we had to draw on vision statements and high level strategy to define our domains, but now that we have a fledgling business architecture (as defined in Part 3 of this series) we have a more detailed source of information on which to draw.

Needless to say, this makes the job of defining domains in the application layer more scientific, but also makes it a more time consuming activity. By analysing the services within the business service model you should be able to identify common themes for which you will need to provide capabilities. These capabilities will naturally group into domains and so steps 1 and 2 should be approach in an iterative manner. i.e. have a first stab at your domains (don’t spend more than a couple of hours on this), then discover your services in step 2 and from these services refine your domain model to recognise the families of services that you are discovering).

Step 2: Services
Now start populating this model with the services that you intend to provide to the business to fulfil its obligation to the customer. To do this you need to return to your business service model and look at the processes within it. You will start to see within these processes common activities that will need to be supported by your application capability model and it is these activities that define your application services (e.g. Document Lifecycle Management, Contact Handling, Product Servicing, etc.). Make sure you have captured as a minimum the intent of each service to avoid misinterpretation later, and more importantly don’t forget to map these application services back to the business services that they support! This is an essential step in ensuring that everything in your application layer can be directly related to something in the business layer. After all, if it is not supporting something the business wants to do in the future what is it doing there in the first place? 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 a week or two to produce the first cut of a fairly inclusive capability model.

Step 3: Functions
Now that you have defined the application services you intend to provide to support the business and linked these back to the business services themselves) you should be able to break these down into the functions that will support these services. Focus first on those that support the business services 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.

REMINDER: The term “application” does not just refer to IT applications! A nominal ledger implemented on paper is as much an application as is a spread-sheet created to achieve the same outcome. Not every element of our service model has to be provided by IT.

The definition of application functions is not a purely abstract activity as needless to say, it will help enormously if the functions you propose marry up with functions that are provided in the real world in one form or another. It is for this reason that (despite publishing this part of the guide first) I strongly urge enterprise architects to consider the corners of the model first, and thus populate the infrastructure layer at draft level before considering the application layer in anger.

An example of a functional decomposition might be the definition of a Document Lifecycle Management service into functions such as Template Management, Document Generation, Document Repository, Document Distribution, etc. For an average service, separation into application functions should take no more than a week at most (and more typically a couple of days).

As was the case for the business layer, you will find that there is a strong tendency to fall back on “what we do today” whenever the going gets tough. Don’t forget to regularly ask the question, “is this what you want to do in the future, or is this what you have to do now?”

And that is it. You now have the first cut of a capability model that defines the functionality that you will need to provide in the solutions model to fulfil the future needs of your business.

The Data Model
Defining the application services and functions in themselves is only part of the story. For functions to make sense in a real business context they must be married up with the data on which they operate. In the business layer we created the information model which defined at a high level the data that our business services managed and depended upon. This model was in itself quite flat in nature and we did not focus too closely on the underlying hierarchy of this information. Now we are in the application layer we need to get serious and drill down into the model to define that actual data within these business information concepts. What exactly do we mean by customer, and what data do we need to properly define that customer?

Step 1: Domains
At last, an easy step. In the vast majority of cases it should be possible to simply copy the business information domains that you defined in the business layer. Occasionally it might be necessary to add one or more domains to support information that simply does not manifest itself at the business level, but beware of this as more often than not this is a sign that you have actually missed something in the business layer itself. A good example of this is where IT architects forget to include the IT department as an integral part of the business itself!

Step 2: Entities
Remembering that the audience for this data model is the design community, we can now afford to use more scientific data definition approaches, encompassing the specific items of data required for each data entity, the hierarchies in which they sit, and the relationships that exist between them. This inevitably makes the job harder and more time consuming, but at least you have a business information model from which to derive your application data model. Once again, good prioritisation is key here. Look at your high priority business services and then at the business information entities on which those services depend. These are the entities you should focus on first. Focus at this stage on decomposing a single business information entity into one or more data entities (as a hierarchy) specific to this information entity.

Data modelling is always a time consuming activity, and I’m afraid this is very much the case here. However, if you focus first on the entities themselves, and their relationships and only drill into the individual data items as you move into the implementation phase of a solution, it should be possible to define the data model for a typical business information entity in two to three days.

Step 3: Relationships
Your data entities will not exist in isolation from one another, but we have a head start this time. The business information model already defines the relationships between the information entities from which your data entities are derived. All you need to do now is define the more detailed relationships that these resolve into in the data model. E.g. a relationship between customer and product holding at the business information level might resolve into a relationship between a customer reference and a specific account at the application data level.

Step 4: Discovery and Use
This final step should now be fairly straight forward as you already know which business information entities are accessed by which business services. All you need to do now is define the next level of detail by working out which data entities are accessed by which application services (and functions). For example, previously we knew that the Customer Management business service accessed the Customer information entity. Now we can be more specific and indicate that the Manage Customer Details application function accesses the Customer Contact Details data entity.

The Solutions Model
With the Capabilities and Data model we now understand what we need to do to support our business, but what we do not have are the actual building blocks from which we can create our end-to-end solutions. This is where the solutions model comes in. In the business layer, we defined the customer experience in the form of journeys analogous with a tube map, with clear start and end points, travelling through stations representing the key business services used. We then defined the interactions that the customer has with the business, and the organisation structure that the business plans to put into place to support these journeys and interactions.

In the application layer we can use this organisation model as the context for our solutions. We also have the capabilities and data models in the application layer and so all that is left to do is to tie these together to create our solutions. In traditional architecture terms we are now creating our logical solution designs.

Step 1: Defining the Building Blocks
It is unlikely that we will create solutions to all our needs in one go. Businesses have limited resources to deliver change, and by the time we come to implement many of our solutions anything we put in place in the early days of our architecture may well be out of date. However, every good architecture provides standard building blocks from which solutions can be created, safe in the knowledge that they are following an architecturally compliant path. In order to define these building blocks we need to look back at our capability model and at the application services and functions that we have defined in that model. The architect needs to identify from this model the sets of functions that can realistically be grouped into units of functionality that can then be used to build solutions.

This is where the “art” elements of architecture come in: the art of simplicity and the art of the possible. For example, we might take all the functions from the Document Lifecycle Management service and propose that they be delivered as a single building block (or application component) safe in the knowledge that there are numerous vendors out there who provide out of the box solutions to fulfil this need. Alternatively, we might take our Systems Development service and propose separate building blocks to cover Software development, Change Management, Testing, etc. It is not immediately obvious what the right answer is and opinion will differ widely as to the correct approach to take. There are of course, many ways to skin a cat. There are of course some key things to take into account when making these decisions:
  1. What do you already have within your arsenal of strategic choices?
  2. Are there clear patterns in the outside world that numerous vendors have followed in providing standard offerings?
  3. Are there clear structures in your organisational structure to which you want to align your solutions?
  4. Can you justify grouping the application functions into a single building block based on their relationship to one another, or are you lumping functions together that would make perfect sense when considered in isolation from one another?
As for many architecture activities this will almost certainly be an iterative process accompanied by much head scratching, soul searching and lost sleep. One thing to always keep in mind however is that you should record your thoughts in your model as you go, even if you are not sure it is right. This allows you to revisit your thinking, and more importantly to share it with others and invite their input (be it positive or negative). It is only through this process of sharing that you will create a robust a widely accepted picture. You do have the advantage that you don’t need to go hunting for your requirements in order to define your building block. These have already been provided for you in your business layer in the form of the related business services and information that are fulfilled by the application functions that your building block needs to provide.

Step 2: Aligning to the Physical
Our building blocks tell us what we need to create in order to support our solutions, but they do not tell us from what we are going to build them. Each of these building blocks will of course need a design. At the very least we should take each of these building blocks and link them to the physical world, and to do this we will need our infrastructure layer again. In the component model of our infrastructure layer we will find the physical things from which we can build things. These might be items of IT software or hardware or non-IT items such as stationary, buildings and transport, and we need to define our building blocks in terms of these items. We are now linking our architecture to actual design artefacts and I will not go into detail on this matter here as this is intended to be a quick start to architecture, and not a design guide.

Step 3: Black Box Solutions
And now to our end-to-end solutions, but what exactly is a solution in the context of this architecture? In simple terms a solution is a bringing together of the building blocks defined in step 2 into a single black box to support the handling of a set of related customer journeys by a set of related people. Thus, in a typical internal example we might take all the customer journeys relating to the handling of all our employees’ HR needs, and propose a single solution to support these. Defining what this solution needs to do is fairly straight forward. By understanding the business services from the customer journey that we need to support we can identify the application services and functions from the capability model that need to be provided by the solution. For these services and functions we already have our building blocks from step 2, and so all we now have to do is knit them together to create the solution.

We’re back into design again here so I don’t intend to describe in detail how you might go about this, but suffice to say, you may discover that to provide a reasonable experience to the user of the solution (or in knitting together the building blocks) you discover the need for a small number of additional building blocks that you had not previously thought of. These will need to be added to the model and linked back to the application services in the capability model (which in turn might also need to be updated). This is not a problem, nor is it a failing in your architecture. It is simply a natural part of the iterative architecture process in which the model is subject to continuous refinement.

The Problem Solved
You now have a working application layer (and thus a working end to end architecture) that is delivering solution designs and driving real projects. Through its use to solve real world problems you will be able to continuously refine and extend this architecture to ensure that it stay current.
Obviously I haven’t explained the infrastructure layer yet (which you will have worked on to some extent before the application layer) and that will be covered in the next part of this series. “But why” I hear you ask, “didn’t you cover that first?” Well – two reasons:
  1. People expect architecture to be explained in the order I am covering it here.
  2. How else am I going to tempt you to read part 5?
The Enterprising Architect