In this blogpost I will be briefly explaining what a service catalog is and what the function is as part of a service-oriented architecture. The inspiration for this blogpost comes from a project that I am currently leading in which I am implementing a Service Catalog for a customer.
A service catalog, also called a service inventory is an indepently standardized and governed collection of services within a boundary that represents an enterprise. The purpose is to be prevent IT projects introducing redundancy and disparity by delivering new services that (partially) overlap in logic with existing services. This will also lead to additional benefits for the maintenance party, which will have a less complex and diverse information technology landscape to maintain.
You can’t reuse, compose and recompose services if you are not aware of them nor able to discover them. This concept supports the highly focus on service reusability which on its turn comes back in all of the principles associated with a service-oriented architecture but especially Service Reusability, Service Discoverability and Service Composibility.
The service intentory (Figure 1) can contain various service types like process services (also orchestrated task services), task services, entity services and utility services. The latter one is more process-agnostic and holds therefor a higher reuse value whilst the first mentioned is more process-specific and therefor less reusable.
Although the service inventory is often a forgotten concept it is essential to implement when the occasion arises since it forms the foundation of a service-oriented architecture. Simply stated, without a service catalog reusability is dictated by the limited knowledge of the designers and developers. This is not a problem when IT projects are planned sequentially and the same pool of resources are responsible for the design and implementation but it will cause a serious risk once IT projects are executed in parallel and the pool of resources is shifting.