Well - I’ve got a “service management” background, so it’s completely natural to talk in these terms. :) A service have in a way two interfaces - one business

Well - I’ve got a “service management” background, so it’s completely natural to talk in these terms. :) A service have in a way two interfaces - one business (the work it’s doing), and one technical (how it does it; a port publishing an endpoint or whatever). No business process to support, no service to manage. The lifecycle of the technical service will consist of a bunch of actions that will be taken, perpetually, until the sunsetting/decommissioning of the business process. Actions: init, code pushed, deploy, monitor, trace, update, decommissioning etc. You take these actions and put then in a lifecycle circle and you have a nice powerpoint! As much as possible, preferably everything, in this cycle have to be governed by conventions and automations. - Automatic follow-up if a service have no upstream or downstream services for example. Why do we have a dangling service?! - Or, you have a key service tied to an SLA, but upstreams are not matching this? - you have services that have not been touched in a timely maner. - etc... just drop the relevant team an automated slack message with the option to initiate whatever is required to keep the lifecycle churning. With many thousands of assets/ci (configuration items) almost everything have to be automated or you will grind to a stop eventually. If you can couple business process to automated technical service management - big wins!