Value Chain Analysis

Recently we discussed how business services are realised in terms of business process, people, information, data, applications, and technology. A business service can be seen as a cohesive business capability that does not share process, data or business rules with any other capability.

The interface (or service contract) between business services is expressed in terms of business events. Business services are not dependent on how other business services are fulfilled, only the business events they raise. Consequently, the business architecture description is very stable. We can update process implementations without impacting any other processes so long as the high level business events are unaffected.

Our technical service components are then aligned with our business services and business events, extending this stability and loose coupling to our IT architecture.

So business capabilities are the key ingredient in determining our service model. But how do we go about identifying business capabilities? Do we simply think about what a business does at a high level and decompose? Or is there a better way?

A while back Nick Malik wrote about the relationship between capability modelling and process modelling. He posed the question as to whether these two approaches conflict, or if they are in fact complimentary. If you've been reading my recent posts on the matter you would probably guess that I feel the two approaches are very much complimentary.

Nick suggests that there are two main approaches one may take in identifying business capabilities. One is process centric where capabilities are defined around process areas within an organisation. The other suggested approach is to align business capabilities with organisational structure. In this approach, capabilities mirror the structure of a business (such as divisions, departments, business units and teams), rather than its processes.

As you've probably gleaned from my previous posts on business architecture modelling, I very much favour the process centric approach. In fact, the premise of modelling business services around capabilities relies on the capabilities being process-centric. As I mentioned above, the interface between business services is expressed in terms of business events. Business events are raised by business processes.

If a single business process were to feature in multiple capabilities (as would be the case if we modelled our capabilities around organisational structure rather than process areas), then multiple capabilities would expose the same business events. Moreover, updating a single business process would potentially involve updating the implementation of multiple business capabilities.

So when using business capabilities as a means of identifying candidate business services we must take a process-centric approach. How then do we produce a process-centric capability model of our enterprise? The answer lies with Value Chain Analysis.

Value Chain Analysis involves identifying the top level process areas (or functions) of an organisation and mapping them as a value chain. The value chain illustrates the series of top-level processes an organisation uses to take inputs from the market, transform those inputs, and then deliver value added products and/or services back to the market at a profit. These processes are synergistic in nature. The total cost of these processes is less than the value added by the organisation, thus justifying the profit margin.

A value chain is modelled in terms of primary and support activities. Primary activities are those that feature in the value chain itself. They are the processes responsible for engaging with the market and directly transforming inputs into outputs. Support activities support the primary activities.

The value chain for a typical insurance organisation is illustrated below.


There are seven primary and seven support activities in the above example. Each activity contains a number of processes that support the activity. Note that not all processes within a primary activity necessarily directly contribute to the value chain. A primary activity must only contain at least one process that contributes to the value chain.

An organisation may also have multiple value chains. Multiple value chains may arise where the organisation serves more than one market. Different markets may be served with fundamentally different processes within the organisation.

For example if we were to take two companies supplying completely different products to completely different markets and a merger were to occur, then we would end up with one organisation with two value chains. Support activities in one value chain may be primary activities in another.

The value chain depicts an end-to-end process that executes left to right. In the above example, Marketing sits at the beginning of the value chain because the business must determine what products it is going to offer before doing anything else. After determining the product mix and pricing strategy, Risk Modelling must occur to determine the means by which premium will be calculated for each product.

Armed with this information, actual pricing (rate charts) can be determined for each product. Note that this occurs in the Marketing activity. So we have transitioned back from Risk Modelling to Marketing. Feedback loops are always going to occur within value chains. The point is that the first process that had to occur (determining the product mix) lay within the Marketing activity, and thus Marketing sits before Risk Modelling in the value chain.

Now the business is in a position to start selling its insurance products to customers. This is the Sales activity. The Sales activity involves quotations, proposals, risk assessment and commission calculation. Commissions are paid to all parties involved in the distribution channel.

Once a policy has been sold, it must be written. This is a Policy Administration activity. Once the policy has been written, the customer must then be billed. Once the premium has been paid by the customer, the customer may at some point register a claim. Note that this activity is optional. A customer may never register a claim. The Customer Service function is then responsible for serving the needs of the customer until his or her policy expires.

A value chain gives us a functional model of our organisation. That is, it models the functions an organisation performs without consideration for how they are performed. This is what gives the model its stability.

Later on as we drill down into the lower level processes supporting each activity in the value chain, we start getting into the implementation details. We start modelling the exact sequence of actions performed and the roles that are responsible for those actions.

It is through defining these lower level processes that we in fact are able to define the roles within the organisation and the responsibilities and KPIs for each role. Armed with this, we are then in a position to determine the organisational structure - that is, the reporting relationships between the defined roles.

This is illustrated below.


As lower level processes change within an organisation, so may the roles and responsibilities and by extension the organisational structure. This is further evidence of why we should model capabilities around business functions rather than organisational structure. It provides a considerably more stable model.

This activity of modelling the value chain has forced us to consider the entire business in a holistic and process centric way. As such it is an excellent tool for identifying our top level process centric business capabilities that we can then use to define our business service model.

How Did You Get Started in Software Development?

Rhys Campbell tagged me recently asking how I got started with developing software. Although I don't personally write software these days, I've certainly done my share of it in the past and I currently manage Change Corporation's body of knowledge in the area.

So let's get started:

How old were you when you started programming?

I can't really remember it was so long ago. But I think I was about 16 years old. I started writing "demos", which were effectively programs that did various visual effects (like flying through tunnels and what have you). The demos were entered into demo competitions. Very nerdy really.

I also wrote a music player application that played music stored in the S3M format. If anyone can remember, that was the Scream Tracker file format. The player was written in 80386 assembler and natively managed Expanded Memory (if anyone can remember that from the days of the 286 computer), hardware interrupts, and direct memory access (DMA). The player did real time digital mixing.

What was your first programming language?

I first started writing programs in C, but soon moved into 80386 assembler, and C++. Eventually I got into Visual Objects, Visual Basic, Java and then C#. I've also dabbled in Smalltalk and Eiffel.

What was the first real program you wrote?

I suppose this question depends on the definition of "real". The first commercial application I wrote was a consignment management system I think for a freight company. It was so long ago I can't really remember - but it was written in Visual Objects.

If you knew then what you know now would you have started programming?

Well I'm not really programming at all these days, so I guess if I knew then what I know now then I'd be doing Enterprise Architecture. Although it would be hard to get businesses to take me seriously in that capacity as a 16 year old. If I knew I would eventually end up doing Enterprise Architecture, then yes I would indeed have started programming as it eventually got me to where I wanted to be.

What’s the most fun you’ve ever had... programming?

Hard to say. There's always been good times and bad. I can't say that I've ever found commercial programming fun exactly. I've always found it rewarding and enjoyable. I would say that the demo programs I wrote many years ago were fun to write. I wasn't being paid for it, so they must have been. :-)

Implementing Business Services

In my last post we discussed business capabilities and how they form the basis of how we identify candidate business services. But what is the physical manifestation of a business service? Once we've determined the boundaries of our business services and their responsibilities, how do we go about implementing them?

A business service is realised as a set of business processes and business rules, the people that perform those processes, the applications leveraged by those people in support of their roles in those business processes, the information leveraged by decision makers within those business processes, as well as the information as inputs and outputs of those processes, the semantics and structure of data held within the service, and the technology platforms on which the IT systems supporting the business service execute.

Business processes in different services coordinate their activities via business events. These business events define the interface (or service contracts) between business services.

A business service may contain no IT systems whatsoever. Where there are IT systems supporting a business service, they may not at all support the interface with the rest of the business. A business event may be realised by a simple telephone call or a memo sent between people participating in different business services.

Where IT systems do support the interface with the rest of the business, we have software components in different business services exchanging data. In the SOA style of architecture, this data exchange is performed by way of exchanging explicitly defined messages in conformance with a service contract.

Where we design our software components around business services (rather than taking the JBOWS, Service Oriented Integration or Layered service Model approach), business events are realised as event messages published onto our service bus. The technical service contract then consists of the schema of the messages published by the service onto one or more topics.

Inside the boundary of our business service, we may have one or more software components that exchange data via messages. For example, a smart client application supporting a business service may interface with one or more back end components using SOAP based messages.

These interactions that occur behind the service boundary are an implementation detail of the service itself. These design aspects are local to the business service and as such do not influence the business service contract or play a part in the broader architecture.

In conclusion, the way in which business services are manifested in terms of IT systems depends on the flavour of SOA chosen. By aligning our technical service contracts with business services and business events we achieve considerably better structural alignment between the business and the IT systems that support it.

Business Capabilities

In my last post, I mentioned that we can achieve very stable service contracts by aligning our service boundaries with business capabilities. But this then begs the question, what is a business capability? In short, a business capability is something that an organisation does that contributes in some way towards the overall function performed by the organisation.

The advantage of business capabilities is their remarkable level of stability. If we take a typical insurance organisation, it will likely have sales, marketing, policy administration, claims management, risk assessment, billing, payments, customer service, human resource management, rate management, document management, channel management, commissions management, compliance, IT support and human task management capabilities. In fact, any insurance organisation will very likely have many of these capabilities.

This means that any organisation operating within the same vertical industry will have a remarkably similar capability map. This is a result of the fact that what these organisations do and the services they offer are fundamentally the same. What differs from one organisation to the next is how these capabilities are implemented.

That is, the business processes, applications, data, technologies and human resources (including their roles, skills and knowledge) that support each capability will differ from one organisation to the next; but the nature of the capabilities themselves, the value they deliver, and their core responsibilities will not vary.

This means that whether a capability is implemented as a series of completely manual processes executed by employees, whether the capability is completely or partially outsourced, or whether the capability is fully automated with IT systems does not change the nature of the capability itself. Other capabilities within the organisation are concerned only with the fact that the capability is performed, not how it is performed.

As such we can change the implementation of a business capability without affecting any other capabilities supporting the organisation. This makes for a considerably more stable business architecture description. One problem commonly faced by business architects is that the organisation continues to change and adapt during the process of mapping out the business processes.

This is in part due to the fact that process maps in a typical business architecture tend to span multiple business capabilities. This significantly increases the number of process maps that contain implementation details of a single business capability. Consequently when we change the implementation of a business capability, there is a larger number of process maps that need to be updated.

By limiting the scope of our process maps to a single business capability, we substantially reduce the number of process maps affected by a change in the implementation of a capability. As a result, our business architecture description is more stable and by extension more manageable.

Business capabilities are hierarchical in nature. We can decompose a business capability into smaller capabilities that support the broader capability. We only decompose a capability into smaller capabilities where there is sufficient distinctiveness between those sub-capabilities to warrant separate and distinct process maps to describe those sub-capabilities.

Of course there are business processes that span multiple business capabilities. However, those processes are realised as event driven process chains. Each business process that executes within a business capability has the ability to raise business relevant events. Other business processes that execute within other capabilities subscribe to these events in order to trigger the execution of these processes.

As such, end-to-end business processes are realised implicitly by virtue of the event publications and subscriptions between processes defined within each business capability. Note that this notion of business event publication and subscription is not a technology concern. It is simply a stable means of describing how business processes execute within an enterprise.

Now, this is a really nice way of modelling a business architecture. But what is the relevance to SOA? Well, when we apply the SOA style of architecture to the business architecture domain we are concerned with business services. A business service is modelled around a business capability that has an appropriate level of coupling and cohesion.

If we choose a business capability that addresses too many unrelated concerns, then we will have low cohesion. If we choose a business capability that is too finely grained, we will have tight coupling between services as related concerns will be distributed across multiple business services.

So here we see that business capability mapping is an extremely valuable tool for deriving the business service model for an organisation. It is important to note that this entire discussion falls within the business architecture domain. The technical components that support a business service fall into the domain of the application and technology architecture.

We find that the business service model is an incredibly valuable tool for achieving alignment between the business and IT domains. This is because this single model has equal relevance in both domains.

Service Contract Stability

SOA as a style of architecture reduces coupling between services by mandating that services have no knowledge of each other's implementations. Services communicate only by way of exchanging messages that conform to service contracts. As such, service consumers are dependent only on a service provider's service contract, not its implementation.

However if we do not take particular care in designing our service boundaries and responsibilities, and by extension its service contract, then we run the risk that our service contracts may themselves be highly dependent on a service's implementation. One such example of this is white box services.

Consequently, we want to align our service contracts with concepts that are very stable. With a JBOWS approach, services are exposed somewhat arbitrarily. They do not contribute towards any defined broader architecture. Therefore service contracts will have an arbitrary level of stability.

Next on the list is Service Oriented Integration. With this approach, service contracts are centred around applications. They are expressed in terms of the application with which we are integrating. Consequently if the scope of the application changes, or the application itself is exchanged for another (such as exchanging an Onyx CRM with MS CRM), the service contract is very likely to change.

So what about layered service models? In this case, we have atomic business tasks, business processes and data stores abstracted as services. These concepts are not at all stable. Businesses very often make changes in business processes that in turn require changes in how atomic business activities are defined and how data is represented. With this approach we are very likely to find ourselves changing our service contracts as business processes are updated.

But what about business capabilities? Business capabilities are by their very nature incredibly stable. Although a retail organisation may make regular changes as to how it goes about inventory management, the fact is that it will always have an inventory management capability. Moreover, other capabilities within the enterprise don't care how inventory management is performed. They only care that it is performed.

Consequently, aligning our service boundaries (and by extension our service contracts) with business capabilities gives us an incredible amount of stability. This is the basis of the self-contained process centric-service model introduced in an earlier post.

By defining our services around business capabilities we achieve greater business agility by way of being able to update how business functions are performed without influencing other services in our enterprise.

Transactional Services (continued...)

In my last post we discussed the concept of transactional services and how they ensure business actions can be executed atomically within a service by enrolling local queue and/or topic resources into a distributed transaction. What I did not explain however is why queues and topics are essential for supporting transactional services.

Queues and topics are necessary to support transactional services because that both types of transports queue messages while they await delivery. Although the transport may not store messages durably, they are still stored somewhere until they are delivered. Neither the sender nor receiver holds onto the message during its transport.

So, would it be possible to implement transactional services using a non-queued transport? For example, let us assume we wanted to use WS-AtomicTransaction (WS-AT) over an HTTP transport. As it turns out, it is not possible to achieve this without spanning the distributed transaction across your service boundaries. As we all know, spanning transactions across service boundaries is not a good idea as it hurts performance and reliability.

The reason for this is that with queued transports, messages are delivered to the receiver using a pull based mechanism. Messages are first pushed to the receiving queue, after which they wait to be read by the receiver at a later time. This means that the sending service can complete and commit its transaction without concerning itself with the success or failure of the receiving service.

Moreover, queued transports will cache the outbound message locally making the availability of the receiver irrelevant in committing the local transaction. Without this mechanism for storing messages as they are transported between services, the successful transport of the message as well as the successful execution of the operation at the receiver become relevant as to whether the local transaction can be committed at the sender.

Consequently, the sender must wait for a response from the receiver before committing the transaction - during which time local resources will likely be locked as part of the local transaction.

So although transactional services are an incredibly powerful tool in service design, they do unfortunately require the use of a queued transport.