Business Patterns for Software Engineering Use, Part 1

Philip Teale
Microsoft Corporation

Robert Jarvis
Systems Advisers Limited

April 2004

Summary: Defines business patterns in a way that is useful for software developers, and develops a business patterns framework using the Strategic Architecture Model. (13 printed pages)

Contents

Introduction
The Implementation Interface for Business Patterns
How to Recognise and Document Business Patterns
Definition of the Relevant Spheres
Conclusion

Introduction

This is the first article in a series of two. The purpose of these articles are to explore whether business patterns can be defined in structured way, and if so whether these business patterns would be of value for those who build software systems that support the business.

The first part explores how to define business patterns in such a way that they could be useful for software engineers. The second part explores how to develop systems from such business patterns. In these articles the term 'pattern' is used according to the classic definition created by Christopher Alexander, which identifies three key elements of a pattern.

A Pattern describes a generic solution to a recurring problem, within a defined context. The three key parts of the pattern definition are:

• Generic Solution. This means that a pattern does not define a specific solution. Rather, it identifies the 'class' of problem and how that problem might be solved with a particular approach, based on some demonstrable evidence. Its power is derived from the fact that it is an abstraction that can be leveraged across a large number of situations.
• Recurring Problem. This means that patterns are useful when the problem is not unique, and are most useful when the problem occurs a lot
• Defined Context. This means that you have to put bounds on the generic solution because there are no universally true solutions (at any useful level). So you have to understand the circumstances in which this generic solution is valid, and hence how to elaborate on it to create your own specific design.

Summary

What is a business pattern? A business pattern describes a re-usable approach to the solution of a particular business problem, usually scoped by a business process. It offers a solution based on previous success in defining solutions to the same, or similar, business problems. A business pattern may be described as an 'architectural template for a business solution.'

This paper answers the following questions:

1. Can we develop a framework for the creation of business patterns?
2. Can we define a consistent approach to creating business patterns?
3. Can we prove that the framework and approach work?
4. Can these business patterns be used to drive either software design and implementation patterns, or actual solutions?

In this vision and feasibility paper, we assert that answer to all these questions is yes.

We believe this to be the case because in this article:

1. We identify the set of architectural elements needed to fully describe business patterns. We classify these and focus on the elements that describe the most stable parts of a business, which are most suitable for 'patternisation.'
2. We have defined an appropriate approach, based on tried and trusted methods.

In part 2, we provide an example from the healthcare industry, which is based on a real engagement in the UK.

This article does not try to convince you that you should create business patterns, nor does it provide a cost/benefit case for such an activity. It describes some of the benefits to be gained from using business patterns but is not comprehensive. Our goal is to stimulate interest in this concept and sow some ideas, because we believe this will lead to better-engineered software systems.

Benefit of consistency in approach

The benefit of having a framework for software engineering is well known so we do not elaborate here. However the benefit of a consistent approach is worth a short explanation. It is the authors' opinion that we HAVE to document business patterns in a consistent, structured way for the following reasons:

• Such an approach allows for the gradual introduction of business patterns and business pattern-based solutions. It enables an evolution of systems that implement the patterns. This is necessary because enterprises are usually only interested in investing in parts of their business at any one time.
• Hence we need to deliver business patterns incrementally, according to the benefit to the enterprise. Thus we need a consistent approach that allows growth in the scope of the patterns by seamlessly adding to the existing ones.
• We also believe that this approach should be used across industries, so that if an enterprise in one industry acquires another in a different industry (for example, a bank acquiring an insurance company), they have the option to integrate quite easily at the business pattern level.

The Implementation Interface for Business Patterns

We believe that the key to success is that business patterns enhance the development and maintenance of IT systems by offering a consistent interface for all business patterns. We recommend that this interface takes the form of a definition of the components and services that will implement defined business functions on described business data.

Models Used

We need two models—one to show how to define business patterns and one to show how to engineer systems based on business patterns that may use other patterns in the process. We've selected two models that we've used before, but it's important to recognise we're not saying that you have to use these models. We do feel that it is best for all if the industry uses a consistent approach to define business patterns; but that it could then use many approaches to develop the systems that implement them. The models we use have been used by Microsoft consultants both on Microsoft internal projects, and on external to create deliverables for customers and partners. These methods and techniques have been proven in the real world.

Model 1: an enterprise architecture framework—SAM

In the first part we develop a business patterns framework using SAM—the Strategic Architecture Model. SAM provides an excellent analysis approach and documentation structure for enterprise architecture and associated problem domains.

SAM uses the notions of 'spheres of interest' to represent coherent sets of facts about an enterprise and 'relationships' to associate these facts into useful groups that provide insight into the structure and operations of the enterprise. SAM has been developed by Systems Advisers Ltd, a UK consultancy that has worked extensively with Microsoft in architectural areas. In this paper we have used SAM to identify the key business pattern topics.

SAM can be regarded as a superset of the Zachman Framework for Enterprise Architecture 4 that extends this framework by providing a generic structure for architecture definition and mechanisms for organising, relating, and analysing architectural information.

SAM takes an iterative approach to architecture development operating in either a top-down or bottom-up manner, or in a combination of the two, in building its deliverables. A SAM 'sphere of interest' contains all the relevant information on a particular topic, such as organisational structure or business processes, filed and organised for easy access. A sphere may be populated 'bottom-up' by gathering all relevant information at a detailed level and summarising progressively into higher and higher level groupings, or 'top-down' by defining the putative higher level groupings and decomposing these in progressively more detailed levels until an 'atomic' level is reached. In practice these approaches are usually used together to build comprehensive and resilient architectural models and most importantly to verify the integrity of the analysis.

Having built and populated a pair of spheres to a sufficient degree of detail, the members of these spheres may be linked to represent the real-life relationships that drive and sustain the operations of the enterprise. The analysis and refinement of these relationships enables business optimisation and improvement.

In the context of IT business patterns, SAM provides means of modeling business functions and data, and their interrelationships, to derive the components and services that support a defined business domain.

Model 2: a problem refinement model

A generic PRM has the following steps:

1. Problem
2. Conceptual Solution
3. Logical Services
4. Physical Services
5. Implementation

For example, we can apply the PRM to the steps in building a home.

1. Problem: Sheltering a family in a suitable building.
2. Conceptual Solution: A visualisation of the property in a model of its location with its properties described in such a way that the prospective owner can relate to them.
3. Logical Services: A further refinement of the conceptual solution in which the standard requirements; like rooms, windows, and roof types, are selected for the building.
4. Physical Services: A refinement that focuses on the infrastructural needs; such as foundations, plumbing, insulation and so on.
5. Implementation: The final refinement brings together the logical and physical services to shown a blueprint of how this particular house will be constructed. This is the end of this architect/designers work and the design is handed to a builder. This is analogous to the roles of the IT Architect and the IT Project Designer.

In part 2 we use a Problem Refinement Model (PRM) to show how to work from a business problem through to a technology implementation. The generic Problem Refinement Model can be used to iteratively refine any problem from its initial definition to its final resolution. Our experience has shown such an approach to be very useful for solution architects and designers and so the PRM we show has been customised to their problem space. We'll show how to use that PRM to evolve the business problems (which in our case are expressed as business patterns) into IT solutions.

The PRM we use also recognises the frequent need to separate the enterprise architect's perspective from the project designer's perspective, and uses different techniques for communication with these audiences. For each audience it describes different refinement techniques to use within a five-layer view, and the transforms between the layers. The five layers are shown in Figure 1.

Figure 1. A five-layer view of problem refinement

The reason for having five layers is that it seems in practice to provide a comfortable number of refinement steps:

1. The business problem (as represented by a pattern) is very specific to the business functions being performed and the data required.
2. The conceptual solution elements might be reusable by other business patterns.
3. The logical services are reusable across many solutions.
4. The physical services are oriented to nodes and function/data placement, which is vendor-product independent.
5. Vendor-specific issues are isolated to the implementation layers. So for example, here we can provide very detailed Microsoft product usage guidance, within the overall context.

One great value of using a refinement model like this is that you can maintain traceability through the evolution of the system. So you can look at an implementation detail and trace back through the layers to understand clearly what each of the drivers for that implementation was, right up to the business problem level.

When applying the model for enterprise architects, we typically use documentation techniques that are suitable for long-term guidance of a programme of implementation projects. When using it for project designers, we use techniques like UML—commonly used 'languages' for project analysis and design. (The distinction of programme versus project need is the important point for the refinement technique used; not the role labels.)

How to Recognise and Document Business Patterns

Using SAM's spheres to recognise the real world

We address the question by considering a set of SAM spheres. These represent a superset of the Zachman framework. Our experience of building real Enterprise Architectures shows that the spheres shown in Figure 2 typically represent the important areas of interest.

Figure 2. Typical spheres of interest

These spheres of interest need some explanation. In particular it should be stressed that these definitions may vary from enterprise to enterprise. What is important is that the concepts are recognised and incorporated into the overall architectural design.

Within each sphere we store information about the particular topic—structured for easy maintenance and retrieval. Usually this will take the form of one or more hierarchical structures, the analogy of the filing cabinet comes to mind. Each item of information is known as a 'member.' A member is therefore a discrete piece of information belonging to a sphere of interest. A sphere about 'Locations' might have the members 'Head Office,' 'London Sales Office,' 'Birmingham Plant,' and so on. Further examples of members include:

• A specific organisational unit, for example 'sales department' within the sphere 'organisation,' or
• A specific business process, for example 'Accept Order' within the sphere 'Business Processes,' or
• A particular data entity, for example 'Customer' within the sphere 'Data.'

Definition of the Relevant Spheres

Objectives and Goals are the strategic and tactical aims of the enterprise in fulfilling its mission. They may be high-level such as 'Improve Customer Service' or quite focused such as 'Reduce call centre waiting time to less than 30 seconds.' Objectives and goals impact business processes and are assigned to organisational units for their achievement.

Organisation is concerned with the organisational structure of the enterprise—groups, departments, divisions—and the interrelationship of these organisational units.

Infrastructure is concerned with the fixed assets of the enterprise—locations, buildings, equipment including IT equipment, networks, transportation, and so on, and their interrelationships.

Business processes are defined here as the procedures and activities carried out by the enterprise. Business processes are usually expressed as a sequence of work activities carried out by various organisational units working in a coordinated way. Examples might be 'Process Customer Orders,' 'Recruit Staff,' or 'Prepare Shipping Documentation.'

Business functions are the things an enterprise does, like marketing, selling, product design, manufacturing, financial management, personnel management, and so on. These should not be confused with 'departments' that might do these things. A function might be carried out by many departments or organisational units. Functions can typically be represented in a non-redundant hierarchy. A functional decomposition is constructed on the principles of loose coupling and tight cohesion, principles of good modularisation that will be familiar to software engineers.

Data is the fundamental pieces of information created and used by the enterprise. Typically these pieces are expressed at the level of a data entity such as 'Employee' or 'Product' or 'Customer.'

Business components are encapsulations of business function and data. A business function creates, reads, updates, and deletes data. Grouping together all the functions that create and update the same data entities, using a technique such as commutative clustering, defines non-redundant 'building blocks'—components that may be used to construct systems or applications that in turn support particular business processes. Components are also important artifacts in modern systems development. By encapsulating functionality and data, software re-use and replace-ability become practical. Further, components offer 'services' that may be used in conjunction with the services offered by other components to instantiate a service-oriented architecture. Services exposed using Internet technology are called 'Web services'—an important aspect of Microsoft® .NET technology.

Applications are the enterprise's inventory of computer and other systems. These would include all operational systems (the 'as-is'), those under development, and those planned for the future (the 'to-be'). They may be component-based or have been built using older methods of construction.

Technology describes the hardware, software, and communications environments, and facilities used to construct and operate applications.

Projects are the controlled pieces of work needed to realise an application or set of applications. Projects are prioritised in alignment with objectives and goals.

Using SAM's spheres for business modeling

We believe that the above set of spheres and the relationships between them can be used to define a sufficient business model. So is this how we can describe business patterns? Do we do this by documenting all these spheres and all relationships?

In general terms the answer is 'Yes,' but this would be is far more than is strictly necessary, or indeed desirable, because different spheres are subject to different degrees of stability: ranging from highly stable to quite dynamic. We want to base our business patterns of the stable elements of the enterprise and from this foundation create flexible, agile solutions.

We postulate that there are really three categories of spheres in the set as shown in Figure 3.

Figure 3. Stable, agile, and dynamic spheres of interest

Set 1 = Stable

These spheres describe the stable elements of the business and represent the fundamental structures—business function, data, business components and infrastructure—that must be present in order to operate in the defined business domain.

Set 2 = Agile

The agile spheres describe the things a business does, or can do, to clearly differentiate itself from its competitors. How it does this will determine whether it is an agile business or not. The agile spheres—organisation, business process, applications and technology—are things an enterprise can change reasonably quickly, even continuously, in response to market and economic conditions.

Set 3 = Dynamic

The dynamic spheres are about business direction, work programmes, and change management—basically 'what it is all about.' They describe the effort needed to move towards a set of business objectives and goals by means of a set of related projects.

Table 1.

Table 1 answers the questions:

• Which of these sets of spheres can be expressed as business patterns?
• Which are useful for software engineering?

Conclusion

We conclude that a business pattern will describe:

• The business functions being supported.
• The data that is required to support the described functions.
• The business components that are the IT representations of the data and functions the business needs.
• Optionally, the infrastructure needed to support the functions, data, and components. This is necessary in highly distributed enterprises or those made up of divisions or units with diverse technical or operational environments.

In addition, the business pattern will describe the key relationships between these dimensions. All SAM spheres have relationships to all other spheres. However, we need to focus on certain core relationships that fundamentally shape the business pattern.

The core relationships are defined thus:

The Stable Relationships

• Business functions perform actions on business data (typically, create, read, update, and delete).
• Business functions are included in business components.
• Data are included in business components.

The stable spheres link to the agile spheres as follows:

The Linking Relationships (Stable > Agile)

• Business functions are executed by business processes.
• Business processes use the services of business components.
• Business components are implemented in applications.

The following relationships in the agile space are useful:

The Agile Relationships

• Business processes are supported by applications.
• Applications operate using technology.

Figure 4. Minimum essential model for business pattern definition

This is represented graphically in Figure 4. In addition, there may be relationships involving infrastructure and organisation (in grey) depending upon the nature of the enterprise and the business domain being considered.

However we would issue a word of caution. Although it is far from necessary to populate all spheres before useful results appear, it is necessary to achieve a critical mass of related, stable structures before any significant decisions regarding the scope and boundaries of business patterns can be made.

Solution vs. Pattern

Business patterns are defined using the stable spheres and relationships only. The connections from the business patterns to potential solutions are provided by the linking relationships. Further agility is achieved by improving and optimising the agile relationships.

In a full solution development, we would address at least the linked Stable and Agile spheres and the shown relationships.

Thus for a business pattern we require that only the three Stable spheres and the relationships between them are documented. This gives the most solid base for flexibility in implementations of the patterns. The Three stable spheres required are highlighted in Figure 4. The greyed relationships and spheres represent the linking relationships from stable to agile i.e. towards a particular solution. If a business pattern exists for the subject, then the solution builds on the pattern.

Part 2

In JOURNAL3, we will show a way of developing business patterns as represented by business functions, data, and business components. We will also show how these can be used to engineer software systems.

Disclaimer: The opinions expressed in this paper are those of the authors. These are not necessarily endorsed by their companies, and there is no implication that any of these ideas or concepts will be delivered as offerings or products by those companies.

About the Authors

Philip Teale is a Partner Strategy Consultant working for Enterprise & Partner Group in Microsoft UK. Previously, he worked for the Microsoft Prescriptive Architecture Group in Redmond, and for Microsoft Consulting Services before that. He has 29 years of Enterprise IT experience of which four years have been with Microsoft and 16 with IBM, in both field and software development roles. At the time he left IBM he was working in for the IBM Software Strategy group, in Somers, New York. He has also worked for Standard Life in Edinburgh, TRW in Southern California and Bank of America in San Francisco. His international experience includes nine years working in the USA, three years in Canada and seventeen years in the UK. Phil's background is in architecting, designing and building large complex distributed commercial systems, with specialisation in the Finance industry. His most recent contribution to industry thought-leadership was to drive Microsoft in the creation of patterns for enterprise systems development. Philip Teale can be reached by e-mail at pteale@microsoft.com.

Robert Jarvis is a Director of Systems Advisers Limited, a UK consultancy specialising in the development of Strategic Systems Architectures for major international enterprises. He is also an Associate Architectural Consultant with Microsoft Ltd. Bob has over 30 years experience as an International Systems Consultant and Architect advising business and governmental organisations in the UK, Continental Europe and the Americas. He is the author of ' Enterprise Architecture—Understanding the Bigger Picture,' a Best Practice Guideline published by the UK's National Computing Centre in 2003. Robert Jarvis can be reached by e-mail at v-rjarvi@microsoft.com.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.

© Microsoft Corporation. All rights reserved.