Systems and Services
Anonym
When we talked about software in the past, we talked about complete, closed systems that accomplished a task or set of tasks. These applications were written by a single vendor and were based on a set of requirements as interpreted and implemented by that vendor. Extending these applications or getting them to interoperate with other applications typically required intimate knowledge of the inner workings, and could only be accomplished by the original developer or through a highly detailed specification.
Things are changing. Now, when we talk about software we talk about services and capabilities. An application today might consist of a variety of services developed by different vendors or providers, all interoperating smoothly through standardized interfaces. Many of these services offer a single capability or a small set of related capabilities. They are often made available as web services over the internet. Vendors and developers can pick and choose from a variety of services to build an application that meets user needs. Where functionality is lacking, the developer can write a new service to fill the gaps. We may still call this a system, but it looks different than the closed systems we’ve seen in the past. Functionality can be added or swapped out easily because of the encapsulation into services and the use of standardized interfaces and protocols.
Some vendors are providing platforms where a set of related services are provided allowing other vendors, or even end users, to create a customized application built from the capabilities provided with the platform. These platforms, and the applications they serve, can be extended by incorporating additional services provided by other developers.
Two keys to the success of this type of services-based environment are standards and discoverability. Services need to be discoverable so that the developers building applications can find them and include them. Services need to have standardized interfaces so that they can interoperate with each other and the clients that call them.
Because services are typically centralized and accessed through the internet, many users can access them at once, often without needing to install any hardware on their local, or desktop, system. Multiple applications can leverage the same services, and applications can be updated by updating or adding only the services supporting new functionality. These are benefits that make this model of services-based applications more cost effective and efficient to deploy and support.
Are you seeing these changes in the applications, or systems, you use or support? Let me know.