Product Meta-Models

Delivering business agility through a new perspective on technology Peter Evans-Greenwood


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?

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

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, offpeak 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

A complexity continuum

Our first step is to formalise our approach to creating product components in a product meta-model. The metamodel 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

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.

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 metamodel. 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

1 B. Joseph Pine, Mass Customization: The New Frontier in Business Competition, Harvard Business School Press, ISBN: 0875849466

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

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



Product Product 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

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 metamodel 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

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 serviceoriented 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 megaprojects of old; allowing you to adopt a product metamodel 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 redeveloped 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.

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).

A meta-model in UML

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

The technical product meta-model formalises the concepts and the relationships used in the product metamodel. 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-byservice basis.

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 costeffective, 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 endstate. 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 metamodel 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 (metamodel) 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?