Representing Products and Services in Ardoq

In building a representation of how an organization works, Enterprise and Business Architects often have a desire to model the products and services their organization provides. This can be a particularly useful lens through which to analyze change:

More broadly, almost all Ardoq Solutions, each of which realizes a set of business questions, could add the following question by adopting one of the approaches outlined in this article:

And in some cases, it might be desirable to aggregate new information at the level of a product, service or customer segment (e.g. costs or investment funds).

The primary focus of this article is on enabling architects to include the products and services that their organizations provide to their customers in the knowledge graph of their architecture repository. This allows them to view information from across that repository, such as costs, resource levels, risks, proposed transformations and changes, from the perspectives of those products and services. Some organizations extend the concept of products and services to the outputs of organizational units that are then consumed internally by other organizational units. This approach is also potentially within the scope of this article, and is discussed in some detail later in the article.

The scope outlined above is aligned with the Archimate concept of a Business Service, which similarly reflects both customer-facing services and internal support services:

Many IT Architects and Service Management professionals use the language of services to represent their provision and support of application and infrastructure components and the interaction of such components with each other. Examples include the “Service Instance” and “Technology Management Service” classes in ServiceNow’s CSDM, and the Archimate elements “Application Service”, which represents “explicitly defined exposed application behavior”, and “Technology Service”, which represents “explicitly defined exposed technology behavior”. These IT-specific notions of service do not correspond with the meaning of “product” or “service” in the context of this article.

We do not recommend the use of the Product or Service component types in the Ardoq metamodel to represent these IT-specific concepts, which can be more efficiently represented in Ardoq with the use of references that interconnect the component types that represent IT elements, such as Applications, Application Modules, Data Stores, Interfaces, Technology Services and Servers.

There are many different approaches to modeling business architectures. These often vary according to the size and scale of the business, its industry, its level of maturity, the nature of the markets in which it operates. Ardoq does not impose one approach to this: some business architectures are oriented around business capabilities, some around value streams, some around organizational units, and yet others around processes. And many use combinations of these.

Products and services are the realizations and outputs of these, so there is no single approach to representing products and services that will suit all business architectures. And organizations use these terms in very different ways. For example, some organizations reserve the term “product” for the physical goods they supply to customers, such as the outputs of manufacturing processes, maintaining them in a formal catalog. The term “services” is also sometimes reserved for services provided to end customers, such as financial or legal advice, vehicle servicing and repairs, electrical, plumbing and building services. But many organizations have also adopted the language of products and services to include the internal provision of services from one organizational unit to another. Examples here include the centralized provision of human resources, facilities management and IT services to the rest of the organization.

To further complicate matters, what one organization calls a “product” another might call a “service”. Some recent theories, such as Service Dominant Logic, suggest that all products should be viewed through a services lens. While others take a product-oriented view of everything they do - even packaging advisory services such as those offered by lawyers and real estate agents as “products”. We do not attempt to impose any one definition on either “product” or “service” in this article, leaving it to the reader to align the design patterns described below to their own definitions and usage of the terms.

Whilst one tends to think of products and services as the final output of an organization, delivered for consumption by its customers, many organizations also break down their internal operations into a set of products and services that are delivered by organizational units for consumption by other organizational units. This has become quite a common organizational pattern for IT departments, where infrastructure teams deliver a set of platform services that are consumed by agile business-aligned product teams who deliver and maintain applications for consumption by the rest of the organization. In such a case, the platform services might relate to provision of cloud storage and processing, or servers in the organization’s data centres, while the products would be the business systems that are developed and supported by the IT department and consumed by business units or end customers. Other departments that provide internal services might follow a similar approach, with recruitment, procurement and facilities management, for example, all being seen as products or services that are delivered by their relevant departments for consumption by other departments in the organization. Such internal products and services are also within the scope of this article.

If you do plan to define internal products or services, beware of falling into the trap of seeing everything as a service. As mentioned above, some architecture modeling approaches propose the identification of a plethora of “service” types: Business Services, Application Services, Data Services, Technology Services etc. If you find yourself with an explosion of possible services, consider carefully whether they really are all best described with the generic Product or Service component type in Ardoq. It might be more appropriate for many of these to be identified with more specific component types, such as Applications, Technology Service, Process or Organizational Unit for example (many of which probably already exist in your model). Keep in mind that all new components come with an added maintenance burden - they are only worth creating if they will help you answer valuable business questions, and they should only be kept in your model if you’ve got a way to keep them up to date.

Before reading further, it is vital that you have clear in your mind whether you need to describe “products” or “services” or both in your architecture model, and precisely what each term represents in your organization. You should only consider modeling them in Ardoq if doing so will help you to answer valuable business questions, and if you can see a way to keep them up to date.

The question of maintaining product or service information is particularly significant if you plan to record a substantial product catalog. It is unlikely that Ardoq should become the primary source of a product catalog. Could you reduce the number of product components that need to be maintained in Ardoq by recording only product categories rather than all individual products? If not, do you have another source with which Ardoq can be automatically synchronized?

If you conclude that you do need to model “products”, “services” or both, you should think about your answers to the following questions:

In order to accommodate the variety of possible definitions and usages of the terms “product” and “service”, the Ardoq metamodel contains component types for both Products and Services. They share the same triples in the metamodel, allowing users to adopt either or both. If both are used, it is possible to use the Is Supported By reference between them in either direction (i.e. Product Is Supported By Service or Service Is Supported By Product): some service organizations might back up their services with tangible products, while some product organizations may offer services in support of their products. In this way, the Ardoq metamodel remains agnostic regarding the definitions and primacy of products and services.

Given the wide range of possible answers to the questions presented above, we now introduce four patterns of representation. We suggest you read all of them while keeping in your mind your organization’s use of the terms “product” and/or “service” before you decide which one or ones are the best fit for your needs. The four metamodel patterns show you different ways in which products and services can be related to your view of how your organization’s business works. These are:

One might, instinctively, expect to see a “Business Capability view” in this list. Business Capabilities feature in all four views, but it is worth remembering that business capabilities are conceptual, while products and services are tangible things. If we wish to have a direct link from business capabilities to services, we are likely to end up with one “Deliver Services” capability that realizes all the organization’s services. Which does not shed any light on differences between the services. The alternative to this is to create separate capabilities for each service, which undermines the conceptual essence of a business capability and makes them indistinguishable from processes or organizational units. So in the following examples, there is always a “realizing” component type that sits between the conceptual business capability model and the tangible world of products and services.

The first two patterns relate to value streams and processes. There is sometimes a degree of confusion between the two terms: conceptual value streams and operational processes. If you’re not sure of the distinction between the two, you should read What is the difference between Business Capabilities, Processes and Value Streams? before continuing with this article.

Ardoq’s Business Value Streams Solution enables organizations to create a high level model of their business with one or more Value Streams. Each one can be broken down into Value Stream Stages which are, in turn, realized by Business Capabilities and/or Processes. The output of a Value Stream is one or more Value Propositions. The Value Stream is an abstracted view of what the organization does, and this way of representing a business is often adopted by organizations that have multiple products or services that share a common high-level sequence of steps that proceed towards the delivery of value to customers. The abstracted Value Stream enables them to identify commonalities between what might otherwise be seen as a lot of separate processes delivering different (but similar) products or services.

If you have modeled your business with Value Streams and Value Propositions and wish to represent your products and services, you can extend the Business Value Streams metamodel by having Product and/or Service component types as the realization of Value Propositions. This recognizes that products and services are the tangible result of the more conceptual Value Proposition that is delivered by a Value Stream. The Value Stream is, of course, also conceptual - it does not represent operational processes, which should be modeled using the Process component type. The metamodel that corresponds with this approach is shown below:

For organizations that have also adopted the Business Process Management Solutions, and show Processes as the tangible, operational realization of both Value Stream Stages and Business Capabilities, there is also the option of showing which Products or Services are delivered by each Process. This allows you to make clear the operational processes that deliver each product or service. You will note that there is intentionally no direct link from the conceptual value stream or value stream stages to the tangible products or services.

Some organizations view their business operations through the lens of tangible business processes. This is common in manufacturing organizations, where processes are precisely defined, and heavily monitored or automated. Highly regulated industries also typically work with clearly defined repeatable processes, and often model these in the architecture repository. It is natural, in this situation, to consider Products and Services as the outputs of Processes. They can be modeled with the Delivers reference type coming from Processes to the Products and Services they produce. A more conceptual view of the business is still possible, since Processes, along with Organizational Units and Applications, can be represented as the tangible realizations of Business Capabilities. Thus, it is possible to link Products and Services to Business Capabilities via the Processes that realize them.

Many organizations prefer to view their business around an organizational structure that accurately represents how they operate. These tend to be centralized organizations that don’t have duplicated functions (e.g. in different geographies or lines of business). For such organizations, organizational units lie at the heart of the operating model, and they have direct responsibility for the delivery of their products and services. In some cases, a business capability model is superfluous, since the organizational structure reflects the capabilities the organization needs. In others, the primary link from business capabilities to the tangible world is the realization of capabilities by organizational units. The organizational units deliver the products and services with the support of applications and data. This is a common pattern for organizations that rely upon human expertise for the delivery of services (e.g. advisory, consulting, regulatory or bespoke services). In this situation, there is usually rather less reliance on defined repeatable processes, so the method of service delivery is placed at the door of organizational units rather than described with individually defined processes.

It is often assumed that Products and Services are delivered by an organization for consumption by its external customers. But some organizations take a product-oriented view of their entire organization, describing how their organization operates as a set of product teams that exchange products and services with each other as well, of course, as delivering final products or services to their customers. The Product and Service component types in Ardoq can be used to represent these internal products and services just as well as customer-facing products and services.

There are many variations on this theme, depending on how abstractly the concept of “product” has been taken, and whether it has been applied across the entire business, or just within one internal business unit, so we’ll take one concrete example to bring what might otherwise seem a rather abstract metamodel to life.

In our example, we will consider a department that provides IT services to all the organization’s many business units, both customer facing and supporting. In order to provide a responsive service to the business units it serves, it has divided the development and support of business systems between a set of Product teams. These teams, which consist of a mix of business and IT specialist staff, have adopted an agile development method to ensure that the products they provide are continuously developed to respond to the demands of their business users, maximising the business value derived from the systems that have been deployed.

To optimise the efficient use of underlying software and hardware infrastructure, these Product teams call upon a set of shared services, reducing the risk of duplication among the teams, and maximizing the opportunity to leverage scale. The shared services are provided by a set of Platform teams, offering standardized capabilities for facilities such as network, cloud compute, analytics, storage, authentication and security.

You can see from the metamodel below how the dependencies between the software systems (the Products) and the platforms they run on (the Services) are represented with the consumption of platform services by product-delivering organizational units. This link can, optionally, be made more explicit by showing how individual products are supported by services.

There is no single, standardized approach to representing products and services in an architecture model. There are too many varied interpretations of what products and services are, and there are many different ways to describe how they are produced or delivered. In this article, we’ve reduced a large number of modeling possibilities to just four design patterns which we believe are likely to serve the vast majority of enterprise architecture modeling needs well. Whilst you may find that a hybrid model that blends two of these patterns best suits your needs, we would caution against trying to use elements of all of them in an overly complex metamodel. Always keep in mind that whatever you model will have to be maintained, and should only be included if it helps you answer a valuable business question.