| Backgrounder: |
In today’s world, services are often merely an interface to existing applications. They are certainly useful, and deliver value, but they are still merely an appendage to current monolithic application structures. Indeed, some see service orientation to be all about the use of web services technology—if you’re using the technology, you’re doing service orientation. However, this is to ignore the great promise of service orientation. CBDI sees “service orientation” as much more. Service orientation is a whole way of thinking about both function and structure and what they are for. It is a way of thinking about how function is made available in properly-sized chunks with minimal side-effects and dependencies so that they can be exposed as services that can be composed to provide new function.
There is also a school of thought that contends that services are a single layer at the outside of a set of core business systems, and that service orientation applies to no more than that. We disagree. We strongly believe that effective service orientation requires services to be recursive; that is, the implementation of one service makes use of other finer-grained services, which in turn make use of even finer-grained services, until the “bottom” of the service hierarchy is reached.1 Hence all business function is provided by services, and each service not only provides an interface but also has an implementation of that interface. This implementation is itself a composition of services.
But we can apply this thinking not only to applications provided for users outside IT (such as CRM, ERP, etc.). We can also apply it within IT—and within the wider “development” community that uses such capabilities as BPM tools to define their own business processes (which are then acceptance-tested and deployed by IT). With a raising of the virtual platform [5] we can expect some business people, hitherto quite separate from IT, to become involved in defining and testing business function. The first article in this series [1] described near-future scenarios where this occurred, and subsequent articles described how this could work.
But the scenarios describe something quite different from today’s development practices: they describe an environment in which life cycle assets are actively managed and used to support specific service capabilities. The assets created and maintained are service and other specifications, along with their metadata. Metadata describes and permits modification to the usage of a service, which allows a “360 degree view” of the status of the service, and a wide range of useful new services both directly operating on service status, as well as composing other services, so offering yet further services.
This environment is presented to users through a “Business Services Console” (BSC)—technically a rich client using services to aid in the “business” of development (as well as the usual application services such as Order Entry). The BSC presents users with an environment where the business is in direct control of significant parts of their IT, and where the IT organization itself becomes an indispensable, fast-reacting, often proactive, provider of run-time services.
The environment described in the Part 1 scenarios depends on an effective virtual platform whose run-time part includes an ESB, on a solution to the “business/IT gap” problem, on the kind of architectures addressed in the pages of CBDI Journal over the past several years, and on the capabilities described in the last three articles in this series.
This article focuses on how the development services offered through a business services console are provided. |
Home