bruce anderson

A Service Based Development Process – Part 2

Peter Cripps architecture , , ,

The basic Service Based Development Process I described previously described an end-to-end delivery process for creating services, whether these be cloud-based services or traditional ones running on a an enterprise service bus. The process consisted of a number of activities (where an activity groups together several tasks) as follows:

  • Business Modelling – Develop business process models to understand the business activities that need to take place. Probably a mix of as-is and to-be as well as manual and automated activities.
  • Solution Architecture and Design – Create the architecture for the solution, decides what services are to be used, what platform and delivery environment (public/private cloud, ESB etc) will be used.
  • Solution Assembly/Implementation – Assemble the services into an application and implement using the appropriate technology. Hopefully much of this will be done using tools that generate the appropriate process flows and pull in the right services.
  • Service Identification – Decide what new services need to be specified (i.e. not already in the Service Portfolio).
  • Service Specification – Specify services, their contracts (functional and service levels).
  • Existing Asset Analysis – What assets does the enterprise already have that could be service enabled (legacy code that could be wrappered etc).
  • Service Realisation – Decide what technology will be used to implement services.
  • Service Implementation – Implement services using the chosen technology.
  • Service Platform Design and Installation – Having decided the service runtime environment design and install it. For cloud-based services this means procuring the right cloud resources.
  • Service Operations and Management – Manage and run the service.
  • Service Portfolio Management – Ensure the Service Portfolio kept up to date.

In the example process we have seen so far each of these activities is composed together in such a way that a complete solution can be built out of a set of services that are deployed into a run-time environment. But that is not the only way these activities can be composed. A better way is to compose activities into capability patterns. Capability patterns are comprised of tasks and/or activities that can be composed into ‘higher-order’ capability patterns or delivery processes. They are reusable patterns which can applied across a range of delivery processes. Capability patterns have input/output work products which together define the ‘contractual boundary’ to which performers of the capability pattern must conform (more on this next time).

The delivery process described in part 1 is actually comprised of four capability patterns, each of which could be a process in its own right, or composed into different delivery processes. The four capability patterns are:

  • Provide Capability: Create a new or updated business process/capability based on user requirements. Uses existing services or specifies new ones where needed. Uses tasks mainly from the Consume discipline group.
  • Provide Service: Specify, design and build a new service according to business need. Certify, publish and deploy the service into the operational environment. Uses tasks mainly from the Provide discipline group.
  • Manage Service Portfolio: Create and maintain a service portfolio with an initial set of specified services. Ensure services are certified. Uses tasks from the Manage group.
  • Provide Environment: Design, build, test, install and run a new environment capable of running services. Uses tasks mainly from the Enable group.

Using the same diagrams as before here are the above four capability patterns laid out in terms of disciplines and phases from OpenUP.

Provide Capability
Provide Service
Manage Service Portfolio
Provide Environment

In the third part I’ll look at the work products which together define the ‘contractual boundary’ to which performers of each of the capability patterns must conform.

The ideas in this blog were jointly developed with my ex-IBM colleague Bruce Anderson.

When Does an Architecture Become a Reference Architecture?

Peter Cripps architecture , ,

A reference architecture (RA) is a particular kind of reusable asset that is basically a “ready-rolled” architecture that has been used and proven in a number of other situations and can be applied (wholly or partly) to to solving different problems (though within a particular context). The question is, when does the  architecture of a system become one that can be reused elsewhere and therefore become a reference architecture? I have a colleague, Bruce Anderson, who was instrumental in the early pattern movement who once said to me that something can only be called a pattern if there are at least three known instances of it. One of the things that made the famous Design Patterns book so powerful and continues to make it so enduring is that it was based on rigorous research by the authors who trawled through several systems designs to look for common themes and harvest them into the catalogue of patterns that make up the book. Whilst a reference architecture could be considered a kind of pattern it has some differences that make it harder to find multiple instances that are already ‘out there’. Namely:

  1. A reference architecture is, by definition, a large-grained asset typically made of  many subsystems which in turn are made up of interdependent components. There are many ways of assembling these components together, any one of which will usually do the job. It is unlikely therefore that exactly the same assembly of subsystems and components will exist in more than one architecture. Consider the architecture of an online retail store for example. There will be subsystems for allowing new customers to register and change there contact details, managing the ordering process and for managing the database of products that are for sale. However the internal components that make up these subsystems could be wired together in many different ways. Who is to say which is best?
  2. Architectures at the system level are typically documented in a multitude of different ways. Some may use rigorous modelling languages such as SysML captured in a modelling tool whilst others use more informal documentation consisting of pictures and words captured using a word processor. This makes it difficult to compare like with like when trying to find “best of breed” which is, after all, what we are trying to do when harvesting architectural assets.
  3. Large-grained assets consisting of complete architectures are likely to contain a considerable amount of intellectual property that give companies competitive advantage so they are unlikely to offer them up as potentials for becoming an industry reference. Some subsystems my be covered by patents (amazon’s one-click ordering for example) so are at least accessible but many will not be generally available for anyone to view.

These three factors (and there are probably more, feel free to comment) make it difficult to find similar architectures, compare them to see which is best and to harvest them as a reference for others to use which is the whole intent of the patterns movement. What to do?

  1. Reference architectures can be built. With an enterprise, a bank for example, it should be possible to build a reference architecture bottom-up. By deploying architects with the right industry and technology skills components can be selected and assembled in an optimum way that makes most sense for that organisation. This can then be a reference for other parts of the organisation to use. For companies that provide consultancy across multiple clients this can be a very powerful way to achieve reuse across projects however it does require a significant up-front investment as well as ongoing maintenance to keep the architecture current.
  2. Reference architectures should be described using a standard approach. It helps to document architectures using a standard set of work products. In the book The Process of Software Architecting we describe a set of work products that can be used for documenting a systems architecture (Architecture Overview, Functional Model, Deployment Model, Architecture Decisions etc). The point about using a standard set of work products to describe a reference architecture is that these can then form the basis of the documentation of the system that is to be built based on the reference system.
  3. Reference architectures are made to be changed, not used as-is. Once a reference has been defined it will almost certainly be changed to a lesser or greater extent depending on its “fit-gap” to the requirements of the new system. It’s usually worthwhile to do a formal fit-gap analysis to determine this and to use the output as part of the documentation of the new system.
  4. For reference architectures context is critical. This really follows from the previous item. Knowing the context (functional and non-functional requirements) is critical to the applicability of a reference architecture being reused. There is a danger it will be forced to fit when it makes no sense to do so. For example the new system has particularly stringent performance requirements that mean the way components are wired together in the reference architecture cannot be applied to the new system.

A reference architecture is associated with a particular domain of interest (retail banking, online commerce etc) and typically includes many different architectural patterns, applied in different areas of its structure. Since a reference architecture is an architecture, it is no surprise to find that the best  reference architectures are described in exactly the same manner as any other architecture using the same work products.