Service orientation: impact on BT product portfolio

Service oriented infrastructure (Part 2)   » Log in

Service orientation: impact on BT's product portfolio

A Ward and C Smith

E-mail a friend

E-mail the author

Thank you!

To respond to competitive pressure, BT must simultaneously improve customer experience, dramatically reduce costs and improve time to market. This cannot be achieved by incremental change; a radical new approach is required. At the same time as competitive pressure is increasing, the nature of BT's market and its customers' needs are changing. Technology is enabling convergence between fixed and mobile; and between voice and data services. As a result the distinction between home and work is blurring for example customers often wish to share a single broadband connection for personal internet usage and business use, they may carry a single Personal Digital Assistant (PDA) or have one personal computer that meets all their needs. Customers want simple and complete services that are delivered to an appropriate service quality (perhaps differentiated between work and personal usage) irrespective of their location or device. BT's portfolio must meet this convergence opportunity for new products. The portfolio needs to be simple but complete. Fortunately increasing competitive pressure and this new customer demand for converged products can be combined to good effect as a stimulant to a transformational change to product development and to optimise the portfolio for customer needs. This change is being realised in BT through the implementation of a global, real-time and open platform for future products and services. BT can then build customer solutions on this open platform by, wherever possible, assembly from existing components rather than engineering of new. In order to enable this assembly process a Service Oriented Architecture (SOA) is required not solely for the IT estate but for the entire enterprise and portfolio; whether IT, communications applications or traditional network services. This paper describes BT's approach to optimising the portfolio through service orientation and the progress, learning and issues still to face.

In order to respond to competitive pressure BT must simultaneously radically reduce costs, improve time to market and improve customer experience (quality). BT has set out to become number one for customer service through improving key processes against measures of Right First Time (RFT) andCycle Time (CT). Figure 1 illustrates the three key processes for BT. These measures are directly impacted by the products launched through the Concept to Market (C2M) Process. Products must be launched more quickly, to reduce CT for C2M and the portfolio of those products launched must simultaneously provide value for money and simplicity for customers while preserving customer choice – that is, be 'right' for customers.

        Figure 1. BT key processes and end-end measures

These changes are not incremental on the portfolio but radical, so a key aspect of BT's transformation is not just a change in organisation and process but also in approach towards the portfolio and its structure i.e. the portfolio architecture. A transformed BT implies a transformed portfolio architecture organised to support enhanced customer experience (quality) for all customers from consumer to large enterprise as well as improved time and cost metrics. In general, simplifying the portfolio through removing products will improve time and cost metrics by reducing complexity, while choice is improved by offering more product options i.e. having a 'many product' portfolio. A transformed portfolio architecture must address these seemingly conflicting objectives. BT started this change process in 2005-6 by identifying re-usable components for product build which have been termed 'common capabilities' [1]. Initially the focus of the common capabilities programme was on re-usability and repeatability with benefits derived from cost savings by reducing duplication and RFT through the integration of already proven modules. However the concept of re-use can be extended further by applying the re-usable components to change the way products are built more fundamentally. The change is to allow flexibility through assembly of solutions (by product designers) from a structured set of choices i.e. a pick-and-mix approach to building products from a range of best of breed components. In some ways this 'assembly' can be considered as a special case of re-use. If the re-usable components have sufficient scope, appropriate specifications and are built to some specific architectural principles (section 2.2) they can readily be combined to construct products. More atomic (i.e., with smaller scope) components are initially easier to develop and re-use however are less suited to this assembly methodology at a product or solution level. These concepts are explored more fully later in this paper and in reference 2 however at this stage it is sufficient to recognise that BT's common capability programme began by promoting re-use and is now extending this re-use to more specialised and customer impacting application through extending re-use towards assembly.

        Figure 2. Managing complexity and customer choice through structured options

For this re-use and assembly concept to work and not drive unmanageable complexity in design it is important that the building blocks in the portfolio have some particular characteristics or features:

- they are 'loosely coupled' – that is, have few and known interdependencies.

- they can be described in terms of their behaviour, performance and interfaces, not their implementation

These characteristics allow solution designs to be created without a need to understand every aspect of all the components, which would rapidly become impractical. They also allow subsequent improvement of the individual building blocks without adversely impacting the existing solutions which are already dependent upon them (provided behaviour and interfaces are preserved). Examples of improvements might be improved resilience, geographical availability or reduced cost.

In fact, these features characterise a Service Oriented Architecture (SOA), familiar to CIOs and IT architects but in this instance being applied to a product portfolio.

So in summary the business imperative is to improve all three corners of the time, cost, quality triangle simultaneously. The portfolio impact of this imperative is a need to move towards an 'assembly' approach to product launch and this in turn implies a need to change the portfolio architecture to be 'service oriented' to and to include appropriate product building blocks for assembly.

Given this premise two questions arise for BT:

- How do we select and develop the correct 'building blocks'?

- What is the optimum governance model; how are those building blocks managed?

In BT, the governance questions have been addressed through the evolution of reusable 'common' capabilities. In short common capabilities are becoming the product level building blocks within BT's service oriented enterprise. As they are re-usable elements, common capabilities also contribute to both cost management and ensuring RFT through repeated application of tried and tested components. Particularly important in the governance are the role and responsibilities of the managers that are commercially accountable for the product functions and service functionality: the capability managers. These responsibilities are described later in this paper. However we turn first to the question of selecting product building blocks. As would be expected in this case we should be led by customer needs and in particular the concepts of a 'service' business and of a 'convergent portfolio' for customers.

2.1 The concepts of 'service' and 'function'
In considering this question of 'what are the right set of product building blocks?' it is important to understand the difference between the functional element of a product and the service element of a product. When customers buy a product they do so because they have a perceived problem to resolve or need that they wish to fulfil. For example, people buy voice products because they need to be able to communicate with friends or colleagues at a specific time and when they are in a remote location. As the communication needs to be real time, a letter or e-mail is not sufficient. To meet this need we have to design a solution that comprises phones, wires, ducts, switches and countless other elements to simply make it possible for someone to make that call. This is the functional element of the product and in this case 'right' will mean that the customers need is met 'simply and completely' (more of this shortly).

The service layer on the other hand is a different aspect to the product. It describes the customer's experience in obtaining and living with a product – i.e. what happens when I buy the product, pay a bill or when I need a problem resolved? The service element is clearly very important to the customer's overall view of the product especially when there are multiple suppliers of the same product functionality.

Even when there is only a single supplier then it could be the case that the service experience is so poor that customers decide not to buy – the experience is just too problematic So 'service' is not generally the reason why customers buy products, it is often however the reason why they choose a supplier.

BT has traditionally been a product driven business and has tended to converged implementations on the basis of product stovepipes. By this we mean that each product designs its own functional solution, its own service layer and it own commercial terms and conditions, top to bottom. The three layers of a product identified above are tightly integrated. These layers are illustrated in figure 3. It is clear that in a 'service business', consistent customer experiences are key (to preserve simplicity for customers for example) hence implementations must be converged around customers not products and BT must create such a 'converged portfolio'. This will have building blocks at both the service and functional layers of product. For example 'register me as a customer' may be a common capability at the service layer, allowing common registration for a given customer across all products; while 'messaging' might be such a capability at the functional layer, allowing consistent messaging including preferences, format conversion, profiles, again across all products.

        Figure 3. Elements of a product

2.2 Relating the concepts of product, service and function to technology
Products will be delivered to BT's customers based upon our adoption of technology (both from ourselves and our partners) in a service-oriented architecture (SOA). For such an architecture to work (particularly when provided by a wide range of heterogeneous technical components), it is vital that it includes an underlying technical element that binds the different components together. This has been achieved using a common data model that defines the different data elements and how they relate to each other for product, service and function. In the late 1990s, BT and AT&T developed a common data model that undertakes this binding role [4]. It is important, however, that such data models are used across the whole SOA, including components provided by all suppliers. As a result, BT became instrumental in ensuring that the common data model was used to develop the international data model standard for SOA, known as the Shared Information/Data (SID) model, specified by the Telemanagement Forum (SID) [5]. In this common data model there are artefacts associated with product, service and resource. These provide the blueprints for the way technical components can be used to realise the elements of product, service and function described above. Conformance to a standard, preferably industry wide, data model is an example of one of the most important required architectural principles that are needed to ensure ease of product assembly.

2.3 Terminology
At this point it is also worthwhile considering terminology as unfortunately several words are used commonly in the context of product assembly but with different meanings. This applies particularly to the word service which has at least three different meanings depending on context Service in the context of SOA refers to the functionality, operations or interface offered by one of the component modules within that SOA. In this document such a usage is specifically noted.

        Figure 4. Combining products

        Figure 5. Portfolio roadmaps

Service in the context of a 'service business' has the meaning indicated in section 2.1. This is the usual usage of the word service in this document. Service in the context of a product or solution sold to customers, typically involving an ongoing customer relationship e.g. through rental business model. The term product or solution is used explicitly in this document, where solution implies a more be-spoke or customised implementation cf product which implies a more standardised approach with applicability to a large number of customers.

An obvious feature of a converged portfolio is a consistent 'look and feel', common input modes, help information, contact numbers etc. However there are two other equally important but less apparent features. Firstly, for a converged portfolio, it is straightforward to combine products into customer centric bundles and combined offers. Typically, this is achieved today by overlaying a commercial and service layer on two inconsistent service implementations, adding glue to map and interwork functions and manage inconsistencies. This is because the stovepipe design of today's products often leads to different and incompatible service stacks. Separation of service from function, a key part of the capability governance model, is one part of addressing this problem as it allows customers to select a common service wrap for any combinations of functions they choose to buy. This improvement is illustrated in figure 4. Secondly, there is a need to think about how customers needs and solutions change over time.

Consider figure 5. The boxes on this diagram can be considered to be customer needs or alternatively the elements of the solutions or products that meet those needs. The three-layer stack of boxes represents a converged product bundle – perhaps in a consumer example data, voice and an entertainment offer. A given customer might 'arrive' at this converged bundle in different ways as is shown, depending on their particular priorities – for example, initially buying a data service or web surfing and then subsequently adding voice/entertainment. It is important however that whichever route is taken the destination is the same and also that the possible steps are as seamless as possible, for example part components are not unnecessarily provisioned or withdrawn and perhaps re-supplied. This is the third important element that defines the meaning of convergence for customers in a portfolio sense. This means that to deliver the right portfolio transformation we need to analyse these 'deltas' in functionality on the portfolio – the deltas will typically relate to a specific customer need that 'components' of functionality can fulfil. Hence the point above that the boxes on the diagram can be considered to be needs or solutions. Perhaps more importantly as these boxes relate to choices a customer makes in navigating the portfolio at the highest level, they must represent some of the higher level common capabilities we wish to combine in the portfolio. Hence this is the approach required to define the correct set of common capabilities – a detailed design review of propositions and portfolio roadmaps to identify customer 'journeys' through the portfolio and common elements that will become the required common capabilities.

Having considered the question of selection of common capabilities we return to the question of governance. To understand the governance model that BT is adopting it is first necessary to consider in a little more detail the service oriented architecture that we have already identified is being adopted for the portfolio.

        Figure 6. Capability hierarchy

In a service-oriented architecture, we describe applications and processes as black boxes that can be fitted together in different ways. These black boxes are described in term of:

- What the service does
o Functionally
o How its managed
- How it should perform
o Functionally
o Managerially
- How you use it
o Functionally
o Managerially
- How much it will cost
- The service guarantees

Generically in BT, we refer to the services in our implementation of SOA as 'capabilities'. Capabilities are the way that the components of BT's SOA are described, allowing them to be used flexibly in implementations. The common capabilities described above are therefore one type of this more generic class of capabilities. The different types of capability are driven by their different primary objectives – generally re-use and assembly. Figure 6 illustrates how these types of capabilities relate. This SOA diagram illustrates the point that the services are hierarchical and that some (but not all) of the 'operations' that are inherited from the lower layers will be visible in the higher layer service descriptions. Generally, the lower layers of the hierarchy are designed to address problems at the reuse end of the spectrum. There are many of these capabilities. For example, BT has identified many ten's of capabilities that encapsulate BT's system stack (hiding complexity and supplier choice as mentioned earlier) and they are highly re-usable. This gives much flexibility in the portfolio as well as process implementations. At the other end of the spectrum though, there are a few common capabilities (a few tens in total). Generally these correspond to higher layer functions in figure 6 – that is, the 'assembly capabilities'. These capabilities fulfil the portfolio functions outlined earlier. They provide some 'templating' of the allowable combinations of the lower level re-usable components and they reflect the deltas in the proposition roadmaps. They limit unnecessary flexibility for customers to ensure that choice is manageable and costs can be contained. They also ensure that the portfolio is coherent.

An illustrative analogy of the hierarchy and different types of capability can be drawn with the automotive industry. Consider a car engine as an equivalent common capability in a new car purchase. This engine probably uses pistons/valves that are common with other engines and screws that are common with many parts of the car. However typically a customer need is for different size engines with different power/performance/ economy characteristics. Customers are allowed to choose along those dimensions. They are neither allowed (or probably wish) to specify which screws will be used in the build of the engine or car. The screws, piston etc represent the lower level capabilities. Customers (and even those with responsibility for integrating the higher layer building blocks to form the final car) are not allowed to choose how the screws, pistons and other components are combined to form an engine. This problem is solved once for all users by the engine component manufacturer.

This templating should not be confused with least common denominator. With careful design based on proposition roadmaps the customer can be offered the choices they require but economically and accessibly and in a way that still allows products to work together. If customers have two similar but distinct needs then this should be reflected as two distinct common capability services or capability variants not a single common denominator 'shoehorned' to partially fit two different needs.

We should also not confuse different types of capability as being an implication of little or no commonality. All of the capabilities share common characteristics – and that is because they are described as being part of a SOA. It is often highlighted that re-use is an important advantage of SOAs. This is true, however it should now be clear that re-use is not the most important advantage from the point of view of a product portfolio. Ease of assembly of products and solutions is the advantage here and this is related to governance. Products and solutions are sold to customers and must be integrated into common customer experience journeys that form the service layer described earlier. So commercial costs, performance (particularly under error conditions) and trade-offs between the two are very important to be managed as part of the governance for common capabilities. Re-usability, a primary metric and governance parameter for lower layer capabilities, is a secondary issue for common capabilities (although a useful benefit metric in the early days of introduction of capabilities into the business). In essence common capabilities need to be governed in much the same ways as products would be governed for BT in the past, albeit cost and quality are the important dimensions rather than explicitly profit and loss.

Managing contribution to profit and loss of dependent products and understanding of key cost and performance drivers are essential. The skills required for this the governance are akin to product management skills. This is expanded later in this paper.

As an aside it should be noted that an SOA alone is not enough to achieve an improvement in time to market through an assembly approach to product launch. If an important capability is not in place and available to assemble, then that component will be on the critical path in the implementation of a solution. The product cannot go to market until that component is constructed. Hence another key aspect of the common capability governance is the ability to develop key functions just in time for the first intercept (use of a capability in a product). This has been termed; 'shoot ahead of the bird'. This commercial risk management, alongside best of breed capacity management function, is a key part of the capability management role.

In summary, capabilities share common features in that they are services within an SOA. Different capabilities exist in different places in a capability hierarchy and the governance of specific capabilities depends on the type of capability in question – their position in the hierarchy. The lower layer capabilities should be governed for re-use; architectural conformance and technical issues are paramount. On the other hand common capability governance, at the high layers, should address assembly. Product issues such as functional and management performance and costs and commercial investment risk are paramount. In short, common capabilities should be governed in much the same way as products have been in the past (except they are managed for cost not profit), including adopting appropriate price-performance trade-offs and investing to the right level of market risk.

Significant progress has already been made in implementing the common capability model and development of a global open platform. More than 30 common capabilities were identified in the first analysis and 18 of these have already been launched, six in 2007-8. These capabilities have supported more than 300 product intercepts to February 2008, comprehensively proving the benefits of a service oriented approach to the portfolio.

A rigorous and collaborative budget build process has been established to govern the development of these capabilities. The Common Capability Investment Board, a BT senior investment board, provides line of sight between the company's market-facing units and its product and design divisions for evaluating product functionality investments. BT has invested 25 per cent of its product development budget through this process in the early years of this implementation. Cost avoidance has been significant: the programme has saved BT �2.80 for every �1.00 spent The governance model has also started to eliminate 'unnecessary choice' as described in section 4 by reducing the options for product development. A central team and specific gates in the procurement process have monitored product developments to minimise the cases when products are not assembled from common capabilities. As more and more common capabilities and templated solutions become available, assembly from capabilities becomes increasingly tractable within BT, without projects being subjected to increased risk through waiting for multiple developments to complete concurrently.
There are numerous capability specific examples of the benefits of the approach. For example:

- the storage capability has proven to be 40 per cent cheaper than typical bespoke solutions;
- the authentication capability protects more than 150 portals inside and outside BT, supporting four million customers and 36 million transactions per day, and assisting BT in winning contracts from banking and government customers;
- the user interaction capability reduces product 'look and feel' design from 35 to five days and drives a consistency of presentation to customers that has significant brand value for BT.

The initial implementations have proven the common capability concept but there are challenges in scaling the model to cover the entire portfolio.

At least four key challenges can be identified in scaling up the common capability programme:

- Extending the model to embrace service as well as function
- Developing best in breed cost apportionment
approaches
- Maximising the value of existing legacy investments (to continue to extract value where they are fit for purpose) and managing migration to new platforms
- Optimising investment management for assembly – developing comprehensive roadmaps

6.1 Including service in the model
Separation of service from function, as outlined earlier, allows for the efficient combination of products, bundling and building of solutions. This means customers can choose the service options that are appropriate to them. These service layer options should be defined to meet the specific needs of each customer segment. Customers will therefore have a consistent experience for ordering etc. irrespective of the specific product functionality (e.g., make a voice call) that they use. This is critical to customer experience for a convergent product set and to the business objectives outlined at the start of this paper.

However, common capabilities need to be constructed on the basis that this separation of service from function is realised. This has a consequence on the product functions, for example they should all offer up a set of consistent 'hooks' into the service layer. The requirements for such 'hooks' must be set by the service layer owners, and setting these requirements consistently is a challenge. If this is not done product functions will need to develop many, unnecessarily variant, implementations of management functions.

As an aside it would also be desirable if the governance SOA concepts described above for product functions were extended to the service layer. Componentisation of this service layer, with a hierarchy much as for the function layer may also yield benefit in customer experience. This is the subject of further analysis.

6.2 Cost apportionment or trading models
In this instance 'trading' should not necessarily be taken to imply that usage charges must be raised between organisations within BT, nor imply any particular financial treatment. It does however imply that we need to understand the key cost drivers and absolute costs or apportionments in order to understand and manage product profitability. This is essential to deliver the best in breed investment objectives for common capabilities.

While common capability costs may be relatively small today they will undoubtedly be very material as the company moves towards solutions and products assembled from capabilities for the majority of the portfolio. Changing the basis on which product cost stacks are built is a fundamental cultural and organisational challenge for BT and a key part of the governance model. It is important that cost allocations do not drive inappropriate behaviours in the product community. It is also important to prototype and trial the approach required as soon as possible to ensure RFT as capability costs become more and more material.

Common capabilities need to be re-used across many products, available just in time and specified to anticipate the future market and costed to reflect underlying, volume related cost drivers. The financial model for the future portfolio must not introduce unnecessary overhead onto product profit-and-loss (P&L) balance sheets and must be tractable to administer.

Considering the drivers leads to the conclusion that four key principles should apply to trading:

- Cost-based trading
- Costs amortised over more than one financial year i.e. they should be costed on a forward-looking basis based on forecast total demand over a specified period. The 'first product past the post' should not bear all the cost.
- Capability pricing based upon the higher of forecast (as agreed by capability manager and including his forecasts) or actual volumes
- The 'traded entities' are the common capabilities (and service capabilities) which are described as capability services – i.e., those entities that are selected for assembly not every re-usable component.

Furthermore, it is important to realise that the cost model underpinning this trading approach must reflect the capability design and not a single technology implementation. The capability manager must also have sufficient commercial flexibility to drive the behaviour of product managers towards the best value approach overall for BT. The realisation that capabilities do not equate to single implementations has a significant impact on trading models. The capability design in support of a specified 'capability service' will draw upon resources across several technologies (probably including legacy) and will inform an appropriate apportionment of costs from those technology platforms.

It is also important that cost apportionment reflects a reasonable view of cost drivers. Consider network access as an example; in certain geographies network access will be significantly more expensive than others – if the capability cost apportionment does not reflect this difference and instead shows an average cost across all geographies then the cost stack into products will drive the wrong behaviours. The unrealistically low price in expensive geographies will tend to drive product pricing towards winning business in those locations at very low or negative margins (and losing business in other areas). Furthermore the low value of this business will not be evident from the cost breakdown. Even if on average capabilities are best of breed in cost-performance terms it is important that capabilities avoid 'best average'.

6.3 Impact on legacy investments and migration
There are several subtleties to the model that must be managed in relation to existing investments. Two illustrations by way of example might be:
If a new capability service is requested (perhaps a new level of performance or a new protocol interface) then a decision to invest in a new implementation to support this service must take account of the costs and impact on the existing platforms. This must be factored into the usage cost of one of more of the capability services.

We can envisage a circumstance when two related capability services are required; a standard and fully featured version. In the short term it may be pragmatic (while volumes are low) to host both of these services on a single platform that is specified to the higher feature set. Although in due course two differentiated platforms will be available. In the interim however it is reasonable that the costs are apportioned in a way that is weighted to favour the lower featured capability. Ownership of the supporting analysis to make these decisions must lie with the common capabilities (as indeed will any new asset deployed). Unless this approach is taken it will be impossible to compare 'apples with apples' in assessing the cost of an implementation. Investment decisions will be based on a sub-set of the facts. For example even if a new technology becomes available that delivers functionality at a lower unit price than existing implementations (which is very likely given technology advancement) it may still not be a wise investment for BT in the immediate term if existing platforms are adversely affected due to reduced volumes, or increased inter-working costs. Only a capability manager is in a position to make this assessment and to own the migration of the existing assets to take advantage of the innovation as this becomes possible.

Capability managers are also well placed to consider third party delivery options if they are more value creating for BT. There are also similar migration issues that apply to tactical investments that are made when it is judged that getting to market ahead of availability of fully strategically conformant capabilities is critical. The accountability for the migration and cost to migrate these implementations must be with the capability managers. As an aside it can be noted that this model is likely to reduce management behaviours that promote unnecessary divergence of BT's technology estate. In many cases the motivation for a product manager to establish a new 'stove-pipe' is to secure control over the assets as much as because the 'stove-pipe' approach is more fully featured. In a model where capability managers would own such tactical implementations anyway then this motivation no longer applies.

In summary:

- Trading models must be underpinned by cost models that reflect the capability design;
- This will typically span platforms and extend to legacy platforms and the design will inform cost apportionment of those platform costs;
- New investment decisions must be made and justified by the capability manager, cognisant of the whole costs to BT, including impact on existing infrastructure;
- Capability managers own the implementation and costs of migration from tactical to strategic and existing to innovative new technologies. The trading models should reflect these costs;
- The capability manager must show appropriate risk assessments and sensitivity analysis to support his capability pricing, especially when capability services are closely related (e.g., two different performance levels at significantly different costs for an otherwise similar functionality);
- Capabilities should consider legacy investment – including existing assets under the same governance will deliver significant benefit.

6.4 Investment management for assembly
Related to the trading model is the question of investment management. In order for components to available to assemble and 'trade' at the right time, avoiding adverse impacts on cycle time, it is important that BT invests in developing functionality in the right way and at the right time.

In general there is a mismatch between the cycle times for customers from concept to market (usually short) and the required infrastructure (usually relatively long). In order to manage the difference between these cycle times there is a need to develop clear Capability roadmaps so that common capabilities are available just in time. These roadmaps should address functionality available now and in the future, based not just on known product intercepts but a future market view of required features. First implementation may be delayed until a product intercept is identified however the implementation will take account of not just this intercept but the more general requirements underpinned by the roadmaps.

This approach also allows for a more sophisticated investment model to be developed. The majority of a platform deployment should be funded and justified by early product intercepts however the 'delta' required to ensure the implementation is consistent with common capabilities, justified by the roadmaps, can be funded and governed through the common capability investment model. This approach allows more assets to be managed consistently for assembly. If the entire platform development costs were managed in a single common capabilities programme that programme would rapidly become unmanageable, especially as the assembly approach is extended towards covering the entire portfolio; as will be required in order to deliver convergent products for customers. The changes needed to adapt product developments to meet the model will be a small proportion of the overall cost of development and thus can feasibly be governed in a single programme.

In summary, the next steps must respond to the key challenges identified above and in particular two key next steps need to be progressed:

- to build on the success of the investment management bodies already established for common capabilities to address the points highlighted in the previous section;
- to re-enforce the existing common capability management role to be accountable for development of business cases, roadmaps and in-life management plans. It is worthwhile being explicit as to the required responsibilities of a capability manager for success. These responsibilities can be summarised as follows:

- To manage a portfolio of capability services within the service-oriented enterprise:

o That are described in implementation independent terms, as far as possible and are fit for purpose for inclusion in service assembly process.
o That cover the full scope of a capability - e.g., end-end and can be easily assembled into propositions. This means ensuring that we have the right aggregation of capability services to ensure optimum investment.
o That use other capabilities as required - i.e., specify requirements of other services from capabilities.
o That can be composed into products - e.g., include management interfaces as well as functional interfaces.
o That are built on platforms with appropriate in-life and operations support.

- To manage investment on a group basis:

o Secure intercepts across the group for the capability.
o Have oversight of investment in all relevant platforms and infrastructure (including third party) that contribute to their capability and accountability for the costs- ensure that these initiatives include budgets, plans, etc. consistent with capability.
o To 'own' (i.e., be accountable for specifying requirements, ensuring process in place to manage overlaps, etc.) all the implementations relevant to their scope.
o Build cost models for their capability that includes apportionment of costs from all relevant platforms and that reflect the capability design.
o Develop capability charges that reflect the services provided and that reflect the true drivers (in the medium to long term view) of cost.

- To manage strategically for the business:

o Be accountable for the capability roadmap.
o To build a business case to 'shoot ahead of the bird' based on a forward view of requirements from markets/channels as well as products.
o To own the migration of platforms or functionality to the strategic direction informed by the architecture.
o To manage seed-corn money to re-purpose existing functionality to fit capability model, accelerate migration and support early products in building to the model.
o To be accountable for the in-life implementations of the common capabilities
o To champion the use of capabilities across the whole of BT, selling the concept to market-facing units, helping them engage with common capabilities and always seeking new ways to extract value from the programme.

Changes in operating models to take account of these required responsibilities are now being implemented to ensure the promotion of an assembly approach to product development and to realise the changes needed in BT's portfolio architecture over the complete product range, new and legacy.

To meet the triple challenge of reduced costs, faster time to market and improved customer experience BT has introduced a service oriented approach to not just its IT estate but also the wider enterprise including the product portfolio through common capabilities. Capabilities in general have promoted the concept of re-use to significant benefit while common capabilities, as a more specific type of capability has started to develop the concept of 'assembly' for BT's product portfolio.

Through this common capability approach BT has already progressed along the path towards producing efficient convergent products and created a platform for further progress. This progress will require increased focus on:

- Supporting investment management as a key part of a capability manager role and ensuring capability funds are managed to influence other programmes to develop product building blocks;
- Development of proposition and capability roadmaps to ensure that the correct capabilities are developed, forecast and deployed just in time for first intercept;
- Assembly as a product development methodology and separation of the service layer from the functional layer as an enabler to this approach;
- Including a wider range of assets into the model, including legacy assets. To allow the approach to apply to the whole portfolio as is required to develop customer converged products.

This paper would not have been possible without the hard work and creative thinking of all the capability managers and the programme team that have worked on the programme and help changed the conceptual approach to a reality delivering business benefit. In particular, we would single out Andy Fielden who has lead the programme across several years and is responsible for the creation and adoption of many of the 'pragmatic, real-world' principles that are required for success and described in this paper. We also wish to acknowledge Paul Muschamp's input to section 2.2.

1. Levy B, 'The common capability approach to new service development', BT Technology Journal, vol.23, no.1, January 2005,Top  
2. Natis Y, 'Applied SOA: conquering IT complexity through software architecture', Gartner, May 2005Top  
3. Mahony R and Molony D, 'The transformation to Enterprise Telco 2.0', Ovum, October 2007Top  
4. Muschamp P et al, 'Data management system', US Patent 7310613B2, December 2007Top  
5. 'Shared information/data model', Telemanagement Forum, www.tmforum.orgTop

Alan Ward joined BT in 1980 as a sponsored student and graduated in Physics from Oxford University in 1984. His subsequent career with BT has spanned corporate and group strategy, product development, bid management, organisational design, network design, systems integration and systems software development. He has worked extensively with BT's commercial partners in Europe and Asia. Alan has recently moved to the service and solutions team in the Chief Technology Office where he has been responsible for thought leadership for common capabilities from the outset of the programme. He also leads a team of analysts accountable for setting the innovation direction in a range of portfolio and service projects, most recently in the area of information networking.

Chris Smith joined BT in 1988 from GEC Research. He has a B.A. in Mathematics from the University of Oxford and a M.Sc. in Computation from the Programming Research Group at the University of Oxford. Since joining BT, Chris has undertaken a number of roles including research, systems development, commercial analysis and major programme management. Most recently, Chris has been part of the Services and Solutions team within the Group Chief Technology Office; where he has been developing the common capability model and service innovations such as Information Networking.

|

Next »