I thought I'd pen a few entries related to Service Oriented Architecture (SOA) over the coming weeks.
In the area of service orientation, one key area that sometimes isn't framed effectively involves clear responsibilities for development teams that build and support services. I'll attempt to provide an outline here of items I'll expand on in follow-up posts...
Why are clear responsibilities important?
The typical goals and value proposition of an SOA have been elaborated time and again, so I'll at least postpone a recap. But among them are reducing duplication and increasing reuse as a means to promote a more cost effective and agile operating model.
In large I.T. shops, significant coordination across multiple organizations is often needed to deliver enterprise solutions. Typically this is the case when applications are highly integrated and delivering a business solution cuts across multiple application domains.
Transitioning from a highly integrated legacy environment to a SOA will require I.T. to be on the same page when building services. It is important to share a common set of goals and imperatives to achieve the promises of SOA across the enterprise. Ineffectiveness in this regard will place achieving the full benefits of an enterprise SOA program at risk.
Key responsibilities for those that provide a service for enterprise consumption (click on each link for details):
Transitioning from a highly integrated legacy environment to a SOA will require I.T. to be on the same page when building services. It is important to share a common set of goals and imperatives to achieve the promises of SOA across the enterprise. Ineffectiveness in this regard will place achieving the full benefits of an enterprise SOA program at risk.
Key responsibilities for those that provide a service for enterprise consumption (click on each link for details):
- The functional needs of the enterprise as a whole must be considered to maximize reuse and minimize duplication.
- Meet performance and availability requirements. As requirements and usage patterns change over time, be prepared to adapt.
- Publish and commit to a defined level of service (SLA). Publish planned vs. actual performance, and availability metrics.
- Implement common interface format and semantics applicable to the type of service.
- Implement business rules and edits to ensure the validity/integrity of the operation and any data that is mastered.
- Implement formalized change management. And implement interface versioning to limit the number of clients impacted by changes (decoupling).
- Provide business eventing, where applicable (e.g. asynchronously via JMS).
To a certain degree the responsibilities outlined here transcend SOA. I plan to detail each of these items and their importance in later installments. Thanks for reading. I welcome and look forward to feedback about your experiences.
