Product Meta-Models
Delivering business agility through a new perspective on technology
Peter Evans-Greenwood
peter@evans-greenwood.com
Introduction
Imagine the future. Not the distant future, we’re talking
about next week or maybe the week after rather than an
eventual future where we all have flying cars. A new
business competitor has emerged on the market, coming
out of nowhere with a business model that makes it
impossible for your company to compete. They have
half the cost to serve of their competitors, half the time
to revenue, they seem to be able to introduce a new
product in a matter of days rather than weeks, and their
products are incredibly customisable. They seem to have
halved the business metrics that you want to go down,
doubled the ones you want to go up, while as the same
time supporting a product portfolio of impressive depth
and complexity. And they claim to be able to do this with
conventional technology. How did they do it? And how
are you going to respond?
Complex products
A number of industries have what we can consider
complex products. Companies in these industries sell
services that we can package and repackaged in a huge
number of ways. While the core product, the basic
service, offered in these industries might be quite simple,
the potential to combine and recombine the basic
product creates an overabundance of possible products
offered to customers.
Logistics companies might offer express, freight, air,
sea, next available flight, reverse logistics, all of which
can be boiled down to move box. Similarly,
telecommunications is based on call minutes or, more
recently, move bits, which is packaged into prepaid, off-
peak plans, mobile roaming, … Finance might have
started as pay interest, has been focused on manage risk
for some time, and seems to be evolving into connecting
customers with markets, but offers a broad range of
products to customers, such as credit cards, fixed and
variable mortgages, personal loans.
There is nearly an infinite number of ways to package
these simple core products and offer them to the market.
Packaged products can be defined in terms of the tools
used to provide them, creating a distinction between
ground and air freight for example. Or they can be are
defined in terms of the capability they provide, such as
distinguishing between overnight, express and standard
delivery. We might also collect a group of synergistic
products together, offering them as a bundle.
What has been common until now is that the definition
of complex products has been guided by our ability to
deliver them. As our capabilities have grown so has the
number of product options available to us. The
increasing complexity of our products is driving up the
cost of service delivery, making the ability to rapidly and
efficiently evolve our IT estate is key to success in
today’s rapidly changing markets.
A generation of product facing systems
Today we have so many options that product definition it
effectively arbitrary. A product is created to meet a
defined need or in response to a customer request, and
then baked into our IT systems so that it can be offered,
delivered and billed. The result is a generation of
product facing IT solutions: applications defined in term
of the products they support rather than their role in the
business. For example, it's now common to have
multiple billing solutions in operation, each solution
supporting a small numbers of products and replicating
90% of the functionality of other solutions. We need so
many billing solutions as each solution is only capable
of rating a few products. We see similar problems when
we look at other areas of the business, such as sales and
operations.
This approach to defining and realising products is
constraining the business. Products are difficult to
change, as change often requires a major investment in
IT to update applications across the full width of the
business. What do we do if a product is wrong, doesn’t
meet customer requirements, and needs to be tweaked?
What happens when we need to react to a product a
competitor has just released?
It is also challenging to manage the huge number of
options and possibilities available to create new
products. Companies find themselves on one of two
routes. A single, inflexible product is defined and offered
to the market—“You can choose any you like, as long as
it's black”—at the cost of missed opportunities in the
market and the inability to react to competitors. Or
they’re forced into selling bespoke products; each
designed to support a single customer, incurring a high
cost of sale, high support costs, and which are often
unprofitable.
A complexity continuum
We can easily imagine a complex product continuum. At
one end is the single, static product; the model T of our
industry. At the other is chaos, where each client has an
individually tailored product.
What we need is a way to control the chaos. We need a
way to define the moving parts for our products, creating
a framework segregating the areas where we want to
allow customisation from those we want to standardise.
By providing some structure, but not too much, we can
create an environment where out sales team is
empowered to adjust the product to meet a customer's
specific needs, while providing operations with stable
target to support. The right framework can act as an
engine for innovation within product management by
providing them with a suite of components that can be

A complexity continuum
reused, updated, redefined or recombined to create a rich
palette of new product offerings. And finally, and
possibly most importantly, finance can use the
framework as a tool to establish the real cost of each
product offering, allowing them to ensure that sold
products are profitable (unless we choose to sell a select
client an unprofitable product under exceptional
circumstances, in which case we know just how much
the exception will cost).
There are precedents for this in the physical world.
During the early to mid nineties the development of
flexible manufacturing systems enabled some
manufactures to offer mass customised products for the
first time1 . First to market were manufactures with
small, simple products such as bicycles. The product was
divided into a number of discrete components—front
wheel, back wheel, gear assembly, frame, seat,
handlebars, etc.—allowing customers to assemble their
own bicycle by selecting the versions of each component
they prefer. A few product rules, governing how
components can be combined, ensure that the result was
a fully functioning bicycle.
Flexible manufacturing techniques quickly moved into
more complex and expensive products. Today, the car
you order from the local dealer may be built to order on
a production line in another country. Car manufactures
have made a science of using their product model to
lower costs by sharing components between models, as
well as driving innovation by quickly creating concept
cars through recombining existing components with
some new elements.
Thinking about our products in terms of reusable
components allows us to find the middle ground. A
component based approach reigns in the chaos by
providing structure, limiting the number of moving parts
within a product to a manageable number. The number
of moving parts, how granular we make our product
components, is a slider that can be set somewhere on the
product continuum between complete chaos and a single
product with no options.
The product meta-model
By now we all agree the structure (the right amount of
structure, but not too much) in our product is a good
thing. We might even establish a strategic initiative to
capture and leverage this structure. As with all strategic
initiatives, defining our goal is easy—the real challenge
is in execution.
1 B. Joseph Pine, Mass Customization: The New Frontier in Business Competition, Harvard Business School Press, ISBN: 0875849466
Our first step is to formalise our approach to creating
product components in a product meta-model. The meta-
model is not a product model (as a product model is
really a description of a single product type), but a
model which defines what we mean by product—a
model about a model.
Take our flexible bicycle manufacturer. The racing bike
product model describes a racing bike: two different
choices in wheels with skinny tires, three different seats,
two different racing frames, handlebars and optional
elbow rests. We might also have models for mountain
and hybrid bicycles. The product meta-model describes
what it is to be a bicycle, and provides the foundation for
our product models: a bike has two wheels, frame, seat,
breaks, and so on. Our factory can assemble anything
that meets the bicycle meta-model, but the real world
restrictions of manufacturing (the number of different
parts we can stock, available space in the catalogue ...)
mean that we only want to offer a relatively small
number of product models compared to what is possible.
A product meta-model
The granularity of the product meta-model determines
where we have set the slider on the complexity
continuum: the more fine-grained we make the model,
the more control we have in customising products, but at
the cost of additional complexity in defining and support
individual products. We need to structure our product
meta-model to enable the amount of innovation and
flexibility required, while minimising the effort to define
and field new product models.
The second step is to capture business rules for the meta-
model. These rules specify how different elements of the
product meta-model may be combined, such as
mandating that every bicycle must comprise two wheels,
a frame, seat, handlebars and drive train. The also
specify dependencies between elements, such as the
requirements that the two wheels must be of the same
type and must match the frame.
We can easily imagine applying the same approach to
any of the complex product industries. The model for a
logistics company will specify two end-points and
include attributes to capture the type of service offered
and its service level. All move box products can be then
mapped to this model. Finance could create a mortgage
model, capable of representing any loan that is secured
against an asset (or set of assets), with different types of
mortgages (fixed interest, flexible interest …) mapped to
the model. And telecommunications can create a model
that captures the ability to deliver data to a device, or
between two devices, with mobile calls, home phone and
VPNs mapped to the model.
Bringing stake holders together
Creating a meta-model for our products is just the tip of
the iceberg though. By creating a formal definition of
our product we’ve formed the nucleus for a shared
understanding of our product. We can use this
understanding to bring together stake holders across our
organisation, accelerating collaboration by creating a
common product taxonomy and language.
Bringing stake holders together
Marketing Finance
Product
Product
Operations
Management
Extending our meta-model to include departmental
concerns, we create a common framework to share our
understanding of the products we support. Marketing,
for example, might extend the core product meta-model
to capture how products will be offered to the market,
showing how the product will be differentiated. Finance
will focus on extending the model to capture how
offerings will be priced and how these prices will be
associated with customers and accounts. Operations will
extend the model to capture the detailed technical
information required to configure, create and deliver the
product, while Product Management will use the core
product meta-model, with input from customers and the
other departments, to determine what configuration
options should be offered.
Controlling the chaos?
A product meta-model is a tool to help us manage the
complexity we typically face in taking complex products
to market. Rather than being forced to one end of the
complexity continuum—either offering a small number
of tightly constrained products to the market, or
unleashing sales to create bespoke solutions which may
not be profitable—we can used the product meta-model
to structure our operations, streamlining them to
accelerate adoption and to set the slider somewhere in
the middle, somewhere where we choose it to be.
The meta-model facilitates conversations between
departments by ensuring that all stake holders are
working from the same basic assumptions. If Marketing
and Product Management jointly decide to update the
product in a way that changes the core model, then these
changes can be measured against the core meta-model
and reflected into the extended models developed for
Operations and Finance.
Adding support for tandem bikes, for example, would
require the core model to be updated to support a bike
with two seats and a more complex drive train. These
changes are then reflected into the Operational and
Finance models to determine the changes the impact of
supporting the new model across the business. This
information can be used by the stake holders as a group
to make an informed decision on the viability of the new
products this change enables.
Similarly, Marketing, Finance and Sales can use the
meta-model as a common point from which to determine
how much freedom Sales has is configuring and pricing
solutions for customers, providing us with a simple
three-tiered approach:
1. Any solution constructed within the meta-model is
easily priced, offered to a customer, as its costs are
well known. This allows us to provide Sales with
complete freedom to work within the meta-model
when constructing a customer solution.
2. Solutions that require new product components—a
new type of wheel, for example—will incur an
additional but easily quantifiable cost. A light-weight
approval process can be used to determine the cost
and ensure the opportunity justifies it.
3. Completely bespoke solutions—leveraging existing
and new components in the construction of a
completely custom solution—are still possible. In
this case the meta-model provides us with a toolkit to
simplify the design and costing of the custom
solution. While (potentially) expensive, a custom
solution might be justified in some circumstances for
strategically important clients. A more onerous
approval process can be used to ensure that custom
solutions are only offered when the opportunity
justifies it.
Product meta-models provide business, sales and
operations with a common yard stick. By measuring our
plans against this yard-stick we can ensure that
conversations are grounded in fact, and drive them to
successful and informed conclusions, enabling us to
manage our complex product environment.
Developing differentiation
At a high level we can expect a product meta-model to
be common across an industry as we're all working with
the same basic moving parts. If we’re all selling
essentially the same product then we can expect our core
product meta-models to be similar, if not the same.
To establish differentiation we need to look at how we
extend the core meta-model, capturing how we price our
offerings, or how we assemble (and reassemble) our
products from the components through to how many
different versions of components we plans to offer.
Extending the core meta-model forces us to answer
some basic questions about how we intend to manage
our business and approach the market. Pricing, for
example, is much broader than simply defining an
algorithm to compute a price from an inventory of
product components. How much flexibility do we want
in setting the price? Do components have a fixed price?
Or will they be priced via tariff table or pricing function?
Do we want to bundle different types of products? What
happens when a product is used across economic
borders? When and where are surcharges applied? And
how much flexibility do we have on deciding when to
apply a surcharge? Are accounts tied to a business unit, a
region or are they managed globally?
Differentiation will be captured in how granular we
make different areas of our model, as more a more
granular meta-model provides us with more flexibility
and a greater ability to differentiate. A sophisticated
approach to pricing, for example, will provide more
flexibility and a greater ability to differentiate though
highly customised pricing; however, it also implies
increased developed, maintenance and operational costs
required to support the additional complexity it brings.
Another approach is to focus on providing a low cost
product or service, minimising the complexity of our
product meta-model to ensure low cost operation, but
trading off flexibility in the process.
Our product meta-model, once fully developed, will
mirror our business and approach to the market. A meta-
model to support low cost operation will be different to
one focused on better customer support, or providing
mass-customised products. Within this framework,
business units driven by cost will seek to minimise
complexity, while those wanting to differentiate will
enrich their area of the model to capture this
differentiation.
We will have, in effect, taken our business strategy and
formalised it. We can then use this formalism to create
an IT environment that is explicitly aligned with our
business drivers and operation. We’re poised to deliver
on the much promised, but never realised, business-IT
alignment.
Realising the model
At this stage our product meta-model is little more than
information. While this is valuable as tool to facilitate
discussion, we need to operationalise the model if we
want to leverage its full potential. Rather than simply
using the model as a planning tool, we want to realise it
in software, embedding it in operational systems where
the efficiencies provided by IT will allow us to focus on
leveraging the model rather than managing its operation.
Doing this creates a significant challenge; delivering an
IT estate that is capable of realising the agility,
flexibility, compliance and innovation latent in the
product meta-model requires us to break with the
problem and product centric approaches of the past.
Service-Oriented Architecture (SOA) has recently
emerged as the technology to deliver all this and more2 ,
as it promises to usher in a new wave of enterprise
development. Vendors are integrating SOA concepts into
2 Peter Evans-Greenwood, CapITalise: A game for the whole company to play, Capgemini
3 UML is developed and supported by the Object Management Group (OMG).
the core of their products while analysts are extolling its
ability to right many of the perceived wrongs in the
current IT environment. The fine grain control of IT
provided by SOA enables a more pragmatic approach to
both technology selection and delivery. SOA is attractive
not because the technology itself is new—most of its
constituent technologies have strong heritages already. It
has emerged at a point in time when changes in the
enterprise software environment promise to allow it to
deliver where previous generations of technologies have
failed.
Combining the product meta-model with a service-
oriented architecture, we can create an IT estate
designed to support the business—as opposed to the
existing product-facing systems that seem to work
against it.
A more organic approach
The new world of SOA promises an end to the mega-
projects of old; allowing you to adopt a product meta-
model and integrate it into your enterprise without
launching another mega-project with its associated cost
and risks. We can use the metaphor of city planning to
guide our approach. Paris wasn’t built in a day, and
neither will be the city landscape that is your new IT
estate.
Paris started small, on an island in a river bend.
Gradually, over time, it grew into a cluster of villages.
New villages were founded then expanded until they
could touch each other. Eventually the villages merged
together, forming the interconnected enterprise that Paris
is today. It was an organic approach that didn’t rely on
single grand design. The population developed and re-
developed the landscape as required, reacting to the
environment changing around them while working
toward the common goal of developing a harmonious
city.
We can use a similar approach to manage the transition
from our old project- and application-based world to a
new world founded on the twin principles of our product
meta-model and a service-oriented architecture. To do
this we need to establish a clear, long-term plan
capturing our strategic goals. Then we need a joined-up
approach to IT planning and delivery that connects our
strategic goals, to tactical imperatives, to the realities of
our current IT environment.
Capturing our strategic goals
The product meta-model provides us with the starting
point to capture our strategic goals. Our first step is to
take the meta-model and render it in a suitable technical
language, creating a version of the model which can be
directly supported by information technology. A
technical language, such as the Unified Modelling
Language (UML)3 , is used to capture the concepts and
relationships expressed in the meta-model to create a
technical product meta-model.

A meta-model in UML
The technical product meta-model formalises the
concepts and the relationships used in the product meta-
model. The model also provides the basis for database
schema and interface definitions for operational systems.
A business service blueprint to support the meta-model
Next, we create a business service blueprint—a high
level review of the business activities in the problem
area and their interconnections. The blueprint builds on
the concepts and relationships defined in the product
meta-model to capture the business services that would
exist in a service-oriented solution, aligned with the real
activities we see in the business environment.
The business service blueprint defines a service model,
capturing the business activities that are responsible for
managing and interacting with the product meta-model.
Each service represents a single business activity,
providing a clear line of traceability between business
drivers and the IT assets a service-oriented solution will
deliver.
Planning our next action
Using this approach to renovate an area of our business
is not a process of rip-and-replace: detonating existing
applications and infrastructure to make way for the new.
Services provide a more granular approach, allowing us
to consider the implementation options on a service-by-
service basis.
A quick survey of the business landscape will identify
the most likely location for our first settlement: the first
business process or problem ripe for moving to a
service-based approach. This might be the need to
provide first class IT support for storing and accessing
our product meta-model, or a problematic end-to-end
business process. It might even come from outside the
organisation, such as the need to improve the time to
market for new products in order to remain competitive
in the marketplace. Or it might be all of the above.
Each service receives individual treatment to determine
the most appropriate approach to realising it. This
decision is based on a wide range of factors, such as how
well a service is supported in the current environment,
the suitability of commercial off-the-shelf components
or, most importantly, its importance to the business and
how much budget we are willing to commit to its
implementation.
The options in realising a new service
Existing solutions which are fit for purpose are simply
integrated into the new environment by exposing
interfaces aligned with the business service blueprint.
Solutions we want to replace, but where we are not
willing to commit resources to at this point in time, are
treated to surround-and-destroy: ring-fenced with
interfaces aligned to the service blueprint and then
gradually destroyed as time and budget permits; broken
into smaller business services and replaced by more
appropriate implementations.
New services, providing functionality that is not
supported in the existing environment, might be
implemented either in a commercial off-the-shelf
solution (COTS) or as a bespoke development,
depending on the availability of a suitable commercial
component and our willingness to relax business
requirements.
The more granular nature of services and their clear
traceability to the business activities which they must
support greatly simplifies this decision. No longer are
we struggling to determine if a monolithic finance
application meets our needs; the product meta-model
provides us with a clear statement of our requirements
while SOA enables us to break the problem down and
consider each activity on its own merits. Do I want to
buy or build a product information management (PIM)
solution? Perhaps I should spend my money on
developing a rating/pricing engine? Or the invoicing
engine? Of those three, I’m most likely to care about
rating/pricing engine, since its ability to support my
product and pricing models will have the most direct
impact on my bottom line, whereas order management is
an undifferentiated activity that just needs to be cost
effective and reliable. Even in selecting a COTS-based
solution we can distinguish between those services
where we are willing to customise the application and
those where we want to control costs by restricting
ourselves to configuration only.
The process of mapping out how we will realise the
business service blueprint can be considered IT strategy
in the small. Using a scenario-based approach (deciding
which implementation scenario is most appropriate to
realise each service) delivers a clear plan for delivering a
suite of IT services that are aligned with the business, as
well as meeting tactical and strategic goals.
Execution
As with any strategy, developing the strategy is only half
the battle; the most carefully thought through and
elegantly crafted strategy is easily let down by poor
execution.
We need to address three key factors, common across all
software development efforts, if we are to create a
solution that solves the immediate problem while, at the
same time, providing us with a foundation for
developing our SOA going forward:
• The right level of infrastructure.
The success of SOA is predicated on adopting cost-
effective, commoditised infrastructure, and we need to
determine how much of this new infrastructure is
required. Too little, and the project teams will be
forced to spend their time developing in-house
infrastructure which will gradually erode the benefits
of adopting SOA in the first place. Too much, and our
expensive new platform will go under utilised.
• Mobilising the team.
As with all new technologies and approach, SOA
requires a new mix of skills. Are these skills available
in-house? Can I, or do I even want to, recruit them?
Can I train my team, either via formal training or by
partnering with a systems integrator? Or do I want to
engage an out sourcer?
• Managing the process.
How do I plan to manage the development, delivery
and operation of the constituent services? What
governance and oversight is required to ensure the
smooth delivery?
While these issues are not unique to a services-based
approach, they do bring them into sharper focus due to
the greater number of moving parts, and unique IT
assets, which a service-based approach creates.
Return to Start
Once the first service-oriented solution is delivered, it is
simply a matter of returning to the first and repeating the
process.
1. Survey the landscape and identify the next problem
to tackle (multi-channel, partner integration, etc.)
2. Develop a business service blueprint, or expand an
existing one, to meet the problem
3. Determine the most appropriate implementation
strategy for each business service, including the
possible reuse of an existing service.
4. Execute
5. Return to 1
Over time, the SOA and product meta-model it supports
will expand throughout the business landscape, hugging
the contours while bridging the streams to create an
interconnected blueprint of the entire enterprise.
End Note
So how did they do it? What did that new competitor do
to create a company that it is impossible to compete
against?
Over the last few decades we have become very
proficient at managing the technology delivery process,
but at the expense of managing the technology
landscape. This is most likely the result of how we have
been forced to engage with technology over the history
of business IT; an asset-centric approach resulting in
large technology projects was appropriate when few IT
assets could be purchased off the shelf.
The asset-centric approach of the past is constraining the
business, forcing us to manage the IT asset delivery
process rather than focusing on how we should be
supporting the business. Today, however, IT delivery is
more like enterprise bricolage as we paste together off
the shelf components with limited custom development.
Rather than focusing on technology installations, the
new competitor realised that how we combine the IT
assets is more important that the individual assets
themselves. This shift away from asset centric approach
to IT is not another multi-year transformational journey
because we are not working toward a well defined end-
state. If we want to realise the potential latent in the
technologies we are using today then we need to change
the way we work now, and focus on constantly evolving
our businesses.
One way to manage the complexity is to create a product
meta-model, a description of the moving parts we will
use to create product. By providing us with a shared
understanding of what our products are, a product meta-
model ensures that all stake holders are working from
the same page, providing a basis for decision and
yardstick against which we can measure our business
processes. This approach destroys the existing barriers
between business strategy, tactics and execution,
creating an environment that encourages innovation
while driving lower costs.
Ultimately the tools like product meta-models can
change the way we think about our products. Our
behaviour and mindset shifts, moving to focus on
guiding the evolution of our product strategy (meta-
model) and its interaction with the market, rather than
expending our energies on reacting to the market and
executing on our existing product set. Delivering the
meta-model directly into the hands of our clients
(possibly via a rich internet application) empowers them
to configure the product for themselves, changing the
business-client relationship from supply-driven to
demand-driven. At this point are we offering tens of
thousands of products, the number of possible
combinations of the meta-model, or a single product, the
one the customer configured themselves?