Share via

Architect: SOA services lifecycle

  • Article

Beyond the natural MSF lifecycle where all software development should fit in, there is a higher level of process lifecycle abstraction that relates to the service. Services are one of the most important backbones of a SOA model, where the business capabilities and activities interact with the entities to provide the solution response.

From the architectural point of view, services born, live and die. In order to use a common definition we are going to divide it in three states: expose, compose and consume. The architect is responsible to govern and manage this lifecycle with a clear visibility of the current status of each individual service. This will help to empower reusability and to have a better control when change occurs, what is more, is the recommended path to migrate architectures that contain legacy monolitic systems in order to reach the dynamic level on the application platform optimization model.

Expose: This first step consist in analysing the business drivers (processes) that are going to be addressed. This helps to indentify the necessary services that will solve the process requirement. With the services indentified the reuse (or new green field) services are exposed.

Compose: In this stage the serivces are composed depending on the type of process, if this requires an orchestration of many services this is the place to do it. This stage will incorporate the necessary knowledge to use the business services.

Consume: The client applications are able to discover and use the services based on the processes that govern them.

The lifecycle granularity can be further exploded into specific activities that will categorize the service in a specific domain. This domain has specific implications and the architect will need to embark into the different tasks and responsibilities that each step brings. This is not a fixed model; organizations can tailor it to fit their structure but is a good starting point to avoid missing the plot and rushing services into the model.

The picture shows how the architect is involved in both areas, the solution framework and the operations framework. This approach has worked quite well in many implementations here at Microsoft. If the architect only stays aware on the solution section it will miss the global view, how the services are performing and which ones are candidates for decommission or replacement. When a new service request arrives, the taxonomy of the model should help to identify which services are available; this is part of the analysis step. At this stage we can review the current entities, capabilities and activities and their functional domain. Is the request pushing for a completely new concept that the current services can not supply? This is the question to answer.

Once the service has been scoped and designed following the MSF guideline the building of the service is triggered as well as the testing and provisioning. I always like it to have a list with all my service listed, organized in a domain based ontology that gives me the full picture of what is going on. A graphical representation is always useful to visualize the services used by the different processes, I know that is hard to keep it up to date, but trust me, it really worth it.

Comments