NULL
If there is a constant in IT implementation, it is change. Business conditions change, consequently requiring IT implementations to change. New techniques and patterns allow for better implementation of qualities of service, such as load balancing and failover, security, and so forth. Information technology itself changes continually with the introduction of new operating systems, programming languages, and application servers, for example, that simplify creation and maintenance of new solutions. In fact, a driving force in the implementation of an IT solution is its ability to cope with these inevitable changes. In the era of monolithic applications, changes were dealt with on an application-by-application basis. Implementation of change, whether for a new business or infrastructure—for example, the introduction of a security policy or requirement, or moving an application to a new software platform—was done for an application as a whole, consuming significant amounts of time and money to complete. On the other hand, because each application was developed by a single team and independent, this approach allowed changes to be contained. As a new version of an application was introduced, the previous version came out of use and could be disposed. One of the main advantages of a service-oriented architectural style is its ability to efficiently deal with changes. SOA is based on a decomposition of enterprise IT assets and separation of "stable" IT artifacts (services) from "changeable" artifacts (business processes), orchestrating services into IT solutions (processes). As a result, business requirements changes can often be satisfied by either changes to existing processes or creation of new enterprise business processes based on the existing services. This approach allows for much better (faster, cheaper) support for required changes through (re)assembling of a solution based on the reusable enterprise services. Business services become resources, shareable by multiple business solutions, enabling massively parallel autonomous development of services by multiple disparate teams, each with its own delivery and maintenance schedule. Because every service, in this case, is used simultaneously in multiple enterprise solutions, a change in a business service can have a significant impact on many existing implementations and may, consequently, require changes in each of them. This is not only extremely expensive (requiring a tremendous amount of coordination between development teams and testing, ensuring that none of the multiple service consumers are affected), but also goes against one of the fundamental SOA tenets: Services are autonomous. Autonomy is the fundamental concept behind service orientation. Services should be deployed and modified/maintained independently from each other and the systems that use them. The problem of dealing with shared, potentially changing components is not a new one. For example, Windows operating system and Windows-based applications rely on the shareable COM/ActiveX components. In the COM case, components are considered immutable and any functional change requires introduction of new component with a new globally unique identifier (GUID). Such approach allows for simultaneous coexistence of multiple components/versions. In this article, I will discuss service-versioning approaches, allowing service implementations to evolve without breaking existing consumers. Read the article>>