A Service Based Development Process – Part 2

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.

A Service Based Development Process – Part 1

I have been toying around with this for quite a while. What prompted me to return to it was:

  1. With the cloud hype curve reaching its peak I feel compelled to join in, in one of the ways I know best, method, process and architecture.
  2. It allows me to further discuss the power of using an open, method framework based approach to building delivery processes in a plug-and-play kind of way.

I originally thought of calling this “A Cloud Service Based Development Process” however I think the word ‘Cloud’ is redundant. Whilst this process could be used for developing services “in the cloud” it is actually a generic process that can be used for developing services wherever they may actually be deployed. The process is based on three major components, all of which are in the public domain. All I’m doing is what architects are supposed to do, namely assemble components in new and interesting ways.

  1. Service Based Disciplines (from the CBDI), see here.
  2.  The Open Unified Process (from the OMG’s OpenUP), see here.
  3. The concept of activities and capability patterns from the Software and Systems Process Engineering  Metamodel (also from the OMG), see here.

The process emphasizes the organisational and contractual boundaries for a service-oriented enterprise (SOE) by a separation of concerns into a number of disciplines as follows: 

  • The service consumer and service provider are clearly separated as these require different skills and can be done by different teams. 
  • Enabling of SOA via the SO environment is a concern of its own (for example an ESB supports the implementation of services but does not affect their business content). 
  • Governance (manage) is integrated into everyday work. Example: negotiating the interface for a business service. 

These disciplines (concerns) are shown below.

Process phases are from OpenUP and are: 

  • Inception: Establish scope and define acceptance criteria. Identify key requirements, define candidate architecture and estimate the overall cost and schedule with detailed estimates for the elaboration phase. Identify risks and prepare the supporting environment. 
  • Elaboration: Establish a baselined architecture, produce an evolutionary prototype of production-quality components, as well as possibly one or more exploratory, throw-away prototypes to mitigate specific risks. Demonstrate that the baselined architecture will support the requirements and establish the supporting environment. 
  • Construction: Complete the analysis, design, development and testing of all required functionality. Iteratively and incrementally develop a complete product that is ready to transition to its user community. Establish that users are ready for the application to be deployed. 
  • Transition: Perform user and acceptance testing to validate the new system against user expectations. Convert operational databases. Ensure users and maintainers and ready to use the system. Perform deployment-specific engineering such as cut-over, commercial packaging and production, sales roll-out, field personnel training. Achieve stakeholder concurrence that deployment baselines are complete and user self-supportability. 

In the diagram below I show how the OpenUP phases combined with the previously mentioned disciplines can be overlayed with a deliver process for creating and deploying services.

The process is shown at the level of activities. An activity groups together one or more tasks and tasks deliver artefacts created by roles. I’ll detail more what each of these activities consist of in the next blog.
The other aspect to this diagram is that of iterations. As I’ve mentioned elsewhere I  believe the agile versus waterfall debate is essentially dead. We should deploy whatever processes make most sense for a particular project that can be accomplished in the most time efficient way possible. Using iterations usually makes sense so any process needs to allow for this as does this one. Each phase is iterative meaning that each iteration has elements of each discipline. You can view iterations as a wave which flows through the end-to-end process, early on the emphasis is on business modelling but also includes elements from the other disciplines whereas later on the emphasis shifts to operations and management even though the business process may still be being refined. 

Like I say, next time I’ll look at what each of the activities in this service based development process consists of and what artefacts they create.