A process for realizing services

To the question is there a process to determine wheter when it's best to somehow wrapper and re-use exising code or re-write it from scratch, methods have been developped.
As an example the article Service-oriented modeling and architecture , describes the "Service realization" step. This step recognizes that the software that realizes a given service must be selected or custom built. Other options that are available include integration, transformation, subscription and outsourcing of parts of the functionality using Web services.
"In this step you make the decision as to which legacy system module will be used to realize a given service and which services will be built from the “ground-up". Other realization decisions for services other than business functionality include: security, management and monitoring of services".

It is however important to have identified and specified the services before, to ensure that they have passed the exposure "Litmus test".
The techniques for realizing services with existing code and applications vary and are driven by a combination of the functional interface identified in the previous phases and non functional requirements. In the "adaptation" layer issues such as state management unit of work and security will have to be solved. I will expand on these concerns in a further blog entry.

"Services building" but what services

Enterprises have optimized their line of businesses by investing in more complex and rich-featured software technologies, but in consequence they often have created business operation silos as well as technical operations silos.

The advent of SOA opens now the opportunity of breaking those silos and enabling the business models and resulting processes that span the enterprise and even expand to its partners. It is about building business components that expose existing business logic, or optionally integrate new logic, so that they can be integrated in new business processes.

However building services faces the risk of a bottom-up only approach that only exposes existing interfaces or APIs as the appropriate services.

Avoiding this risk implies that building services is not a pure technical and development matter but also a method and an architectural approach. Several questions will have to be answered to build the appropriate services:
- How can the right business and technical services be identified? Top down, bottom up or meet in the middle?
- How can the variations of the service usage be addressed? Particularly how can loose coupling be applied at business semantic level to integrate with existing business logic and processes?
- How can the new processes coexist with existing business processes that will continue to operate in existing ERP and other systems implementations?
- What are the appropriate architecture layers, implementation models, tooling and technology?

All these matters and more as discussion open is what I plan to elaborate in this blog, with your interactions and collaboration on this essential matter. I target a new entry each week exploring the paths that your reactions will open.