We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Pragmatic Software Design

Vijay Narayanan

Service Capabilities Need to Address Supportablility

user-pic
Vote 0 Votes

Enterprise software systems have several needs one of which is supportability. It is critical that your system is supportable in the production environment. Teams that start thinking about supportability during the last stage of a development cycle or when transitioning support responsibilities to an external team discover many rude awakenings at the last minute. When designing SOA based solutions it is equally critical that supportability needs aren't ignored. Your service design needs to consider several aspects in this space:

1. How will your service handle exceptions? Does it throw it back to the calling application? If it is logging them, is the format and content agreed upon by your production support team?

2. Related to above, it is equally essential to accurately classify exceptions in the service (as much as possible that is). This will help handle and route via an automated fashion as well.

3. Is there a way you can ping your services without corrupting live data? Maybe you need to setup test data and periodically ensure the services are behaving normally. The other option, depending on your business need is to handle exceptions but return partial data or data that is a bit stale etc. The service capability can continue serving requests simultaneously reporting issues.

2. How will clients get answers to issues during runtime? Will they call your support team and if so, what information are they expected to provide? If you have a known list of issues, you can classify them as infrastructure, data, and business logic and provide relevant answers, additional links, and contacts.

4. If your support team cannot isolate an issue, how will they escalate? When they do, is there information that can be of value? For example, the client application or business process name and version, stack trace, time of error, error message may be essential for troubleshooting.

5. Ensure your services capture relevant metrics throughout the request processing cycle. When was the request received, when processing completed, and origin IP or queue name are essential for troubleshooting. Additional, service-specific metrics might need to be captured as well (e.g. your consumer might want to know the status of a request with a particular customer number or an account identifier).

6. Provide tools for your support team that will make it easy for them to monitor service health, reset resources (e.g. database connection pools), and toggle integration points (e.g. an external system that needs to process the output of your service logic). These tools are very useful and will save valuable time when production issues occur.

These are ideas that just scratch the surface. As service capabilities get reused across composite service orchestrations and business processes, supportability becomes extremely important. What have you done in your environment to make services more supportable?

Vijay Narayanan blogs about software design from several perspectives - SOA,BPM, messaging, systematic reuse, agility, and architecture.

Vijay Narayanan

Vijay Narayanan is a software professional working on a variety of projects. Vijay has worked on several software initiatives ranging from single-user systems to large, distributed, multi-user service platforms with services. Most recently, Vijay has been involved in research dedicated to combining agile practices with service-orientation. He is a contributing author to the upcoming book Next Generation SOA as part of a chapter on modern SOA methodologies. Vijay maintains a blog dedicated to software reuse at http://www.artofsoftwarereuse.com.

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT