Agility via Reuse

Service orientation promises reuse in all services, no matter whether or not immediate requirements for reuse are present. Such a fundamental principle impels us to pay close attention to each of the units delivered of automation logic that we wish to deem services.

The main strategic goal that is generally associated with the idea of reuse is the need to position every service as an Information Technology asset with repeatable value. As the quantity of reusable assets increases, so do the chances of fulfilling new Business automation requirements through building less and utilizing more of what already exists.

Such an action is expected to reduce the amount of time it takes to construct automation logic, thus improving the Business’s overall responsiveness to change. Through decreasing the associated effort, fulfilling automation requirements also becomes more cost effective. This leads to a major potential of streamlining Information Technology development environments.

While this might sound unlikely, a lot of Businesses nowadays are heavily investing in creating reusable service inventories as a means of capturing such benefits. Such a principle facilitates all forms of reuse, including composition, inter application interoperability, as well as the creation of utility services and cross cutting.

As has been discussed earlier, a service is merely a collection of operations that are related in some way. It is thus the logic that is encapsulated by the individual operations that has to be deemed reusable in order to warrant representation as a service that is reusable.

By emphasizing far reaching reuse, the suitability of utilizing web services as an implementation option for services is also highlighted. Through making every available through an industry standard communications framework, the potential of reuse is drastically enriched owing to the fact that the logic that is encapsulated by a service now becomes readily accessible to service requestors that have been built with several underlying technologies.

The Service Contract

Both principles reiterate the need of a quality service contract. The content of such a contract should determine what shall be and what shall not be abstracted. Through the design of such content, we will be able to determine how reusable and generic non abstracted parts shall actually be.

This raises the need to view a service’s design as an investment. The construction of service oriented solution logic is nearly always infinitely more expensive and time consuming owing to the fact that considerations have to be taken into account that transcend immediate tactical requirements. Thus, it is necessary to fully understand and appreciate what service orientation is meant to accomplish in order to justify the heavy investment.

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Show/Hide comments

Show/Hide comment form