Service oriented infrastructure (Part 2)
Service orientation: impact on BT's product portfolio
A Ward and C Smith
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.
1. Business imperatives
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' . 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. Selecting common capabilities
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
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 . 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) .
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.
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
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
3. Selecting common capabilities - convergence
and a converged portfolio
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
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.
4. Service orientation and governance of
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
- What the service does
o How its managed
- How it should perform
- How you use it
- 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
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.
5. Implementing common capabilities
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
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
- 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
- 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
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.
- 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
- 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.
7. Capability management role – next steps
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
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
o To 'own' (i.e., be accountable for specifying
requirements, ensuring process in place to manage
overlaps, etc.) all the implementations relevant to
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
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
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
- Levy B, 'The common capability approach to new service
development', BT Technology Journal, vol.23, no.1, January 2005,Top
- Natis Y, 'Applied SOA: conquering IT complexity through software
architecture', Gartner, May 2005Top
- Mahony R and Molony D, 'The transformation to Enterprise Telco 2.0',
Ovum, October 2007Top
- Muschamp P et al, 'Data management system', US Patent
7310613B2, December 2007Top
- 'Shared information/data model', Telemanagement Forum,
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