After a service is developed, it is typically used. That is, the software gets deployed into a running system, performing more or less mission-critical business functionality for the company, enterprise, or universe.
There is an important point to understand here. This is the moment at which the software that implements a service transitions from being software under development to software under maintenance. In general, SOA is a concept that combines new software under development with existing software under maintenance. However, for systems under maintenance different rules apply. For example, modifications become much more critical, especially if the systems have different owners. For this reason, we must also look at how to modify and withdraw services in production.
As soon as a service is in production, it can be used in mission-critical scenarios and business processes. That means whenever you modify such a service (whether its interface or "only" its implementation), you are modifying existing business processes that are in use. And if this results in broken business processes, you're in trouble.
For this reason, we should be careful about drawing an arrow back from the run state of the service lifecycle to previous states. In fact, it is a best practice for services in production to be stable. Whenever you need to modify the behavior of a service in production, you should do this by introducing a new service or a new ...