What is a service portfolio?

A service portfolio is a collection of all services that a company offers to its customers. It includes both core services, which define the corporate product or service itself, as well as complementary services that increase the value of the offering and strengthen customer loyalty.

Portfolio vs. catalog

Based on the definition of the service portfolio based on the widely used ITIL framework, a service portfolio consists of three components:

• Service catalog - the current range of services
• Service pipeline — the future offering of services
• Service retreat/graveyard (“retired services” in accordance with ITIL) — the historic offering of services

The portfolio is thus intended to present a holistic picture of an organization's performance on a thematic, operational and temporal level.

Theoretical foundations

As is often the case with IT frameworks (ITIL, SAFe, etc.), there is no clear right or wrong approach when it comes to the service portfolio. It is always the organization and its employees who must combine the theoretical principles with the practical procedure in order to define the details.

However, when working with our customers, we are able to see and experience different approaches and implementations from various sources. This results in various “good practices” which, in our opinion, have prevailed.

Hierarchy of services and assets

When defining an organization's services, it usually quickly becomes apparent that there are services at different levels. For example, various services can be combined in order to be able to realize overall responsibility.

Therefore, when designing the service portfolio, it should be considered that services can be linked to each other hierarchically. For example, to represent the combination of services for the implementation of a higher-level service.

As part of a service portfolio, the definition and combination of services should be considered as well as the differentiation and inclusion of the assets that make up the respective services.

According to ITIL, a service is defined as:

”A way to add value to customers by facilitating or promoting the achievement of clients' desired results...” (Axelos ITIL Glossary)

From our point of view, however, it is an essential step for developing a service portfolio to develop a common understanding of the “service” mountain range in the context of the organization.

Using the example of Atlassian applications, “Atlassian” could be defined as a service that consists of the “Jira” and “Confluence” applications. At the same level, Microsoft applications are also bundled under a corresponding service. Both could be subordinate to the “Collaboration” service.

The naming of services by manufacturer or individual products is often avoided in order to make the conceptual structure of a service portfolio manufacturer-independent. However, this can also create ambiguities on the part of users who do not associate specific services with generic terms. Here, too, it is important to take into account the current circumstances and organizational peculiarities.

A hierarchy may be unbalanced

The combination of services and subordinate assets therefore results in a hierarchy in a type of tree structure. From practical experience, this structure does not have to be balanced. This means that the elements below a possible service could have three intermediate levels, while another has four intermediate levels.

This potential imbalance makes it possible to flexibly map more complex structures and dependencies resulting from interfaces or organizational responsibilities. Even with future changes, new intermediate levels can be inserted as required without having to redevelop the entire portfolio structure.

Accordingly, not only can dependencies be presented, but responsibilities can also be more clearly documented and communicated.

Links to other configuration items offer additional options

In addition to the links between services and assets, it is also possible to integrate links to other configuration items (CIs) or assets while building a service portfolio and defining services.

The link to physical hardware (servers, laptops, scanners, etc.), licenses or organizational units makes it possible to map an extensive network. This allows dependencies not only to be displayed between services or applications, but also to be traced to specific hardware or other components that are necessary to provide services.

(Jira) Assets as a basis

Originally developed as an independent app “Insight” by Mindville, Atlassian bought the manufacturer in November 2020 and from then on integrated the app into the existing Jira Service Management product. Today, the app is fully integrated into Jira Service Management (JSM) under the name “Jira Assets”. Assets are already fully included for JSM Data Center and JSM Cloud Premium licenses.

While some solutions focus primarily on CIs or assets (and thus exclude users or organizational units, for example), Jira Assets offers the option to freely define objects. On a technical level, there is therefore no distinction between services, assets or CIs.

Jira Assets provides a platform for defining objects. The user alone is responsible for designing the use and use of these objects. Although this also results in the effort required to define and create, it also results in great freedom and the possibilities for extensive linking of elements that are not traditionally available in the same system.

Implementation in Jira Assets

Jira Assets is made up of three main components.

• Object scheme represent a container, a collection. Similar to processes in Jira projects, all objects must be assigned to an object schema.
• Within an object scheme, any number can object types be defined.
• An object type is primarily characterized by the defined attributes , which record the detailed information of an object. In addition to text and list attributes, it is also possible to define links to other objects as attributes.

In a specific example, services and applications could be defined as separate object types in the same object scheme. Each service object then has links to higher-level and dependent services. On the application object, there is in turn a link to the higher-level service and to other dependent or connected applications. (see graphic above)

Since links in assets are always bidirectional (analogous to Jira), a corresponding tree diagram can be drawn using defined links and lists can be created using queries. In effect, assets can thus make a significant contribution to clarity and transparency.

Linking with other processes

However, most of the value of a service portfolio in Jira Assets comes from using the available objects in other processes (or disciplines, in accordance with ITIL 4):

• As part of the Change Enablements A change is automatically assigned to the service owner for approval if it is maintained as an attribute on the service and this service is available when creating changes on a mask in Jira.
• Incidents can be assigned fully automatically to the correct support organization after the affected application has been selected on the user interface. In the background, the links between the application, the service, the support team and, if necessary, up to the individual are resolved.
• In addition to the selection of applications in test management or in the area of development, there is a particularly extensive use case as part of Service Request Management. Not only the definition of the selectable requests, but also routing to the right support center up to the selection of the right SLAs can be defined and automated on the basis of corresponding objects in assets.

The key to success

A clearly defined service portfolio and implementation in Jira Service Management or Jira Assets can be a great opportunity for organizations in development, growth or change to represent their services in a state-of-the-art solution.

With the flexible options for defining and linking objects and using them in Jira and Confluence, there is great potential to give existing service management new impetus or to offer organizations a platform for developing the maturity of their services.

At Swarmit, we support our customers from a wide range of industries in implementing a wide variety of requirements and approaches. Our consultants help in various areas, from developing a service portfolio, to mapping in Jira Assets and/or operating the applications, whether local installation or in the cloud, whether from Zurich, Lausanne or directly at your office.

contact us!

As mentioned several times, the development of a service portfolio should always be considered in the context of the respective organization. This results in very different approaches and views on definitions of terms and structural components.

This article only presents one of many options.

We would be happy to discuss your individual requirements with you and show you how Swarmit can help you implement a successful service portfolio in Jira Assets.

More information:

• Jira Service Management: https://www.atlassian.com/de/software/jira/service-management
• Jira Assets: https://www.atlassian.com/de/software/jira/service-management/features/asset-and-configuration-management
• Swarmit: https://www.swarmit.ch