SOA: Responsibilities of Service Providers (Part 5)

This blog post is one in a series.  An overview and general outline of this series is linked here.

Responsibility 4:  Implement common interface format and semantics applicable to the type of service.

Background

Imagine.  Your trusted business partners come to you with a new problem and clearly a user interface is the vehicle to provide a solution for them.  On the backside of the user interface there are a number of existing services that can be leveraged to perform 75% of the heavy lifting.  Sounds great right?

Stay with me.  Imagine.  The existing services were built independently across multiple development teams.  Some were even built by contractors and consultants during various engagements.  There was little coordination across the organization resulting in each service having its own "look and feel" so to speak.  I view this as an organization that simply has "lots of services" and not a "Service Oriented Architecture" (SOA).

So what's the big deal?  Well, without a level of coordination and standardization for how services should be built, development teams must conform to every difference embodied by each service. Technical differences across multiple services may include:

• Different authentication and authorization mechanisms (or no security at all)
• Different protocols (e.g. SOAP/http, REST/http, tcp sockets, Java RMI)
• Different payload formats (e.g. XML vs ASN.1) and conventions
• Different versioning strategies (or none at all) /* TODO blog later */
• Different methods/mechanisms to return error messages (e.g. SOAP Faults, Remote Exceptions, or returned in a response to be interrogated)

With each service having a little different look and feel, constructing the user interface and leveraging the existing services can be tedious.  And if care isn't taken the user interface code can easily become more complicated given these differences.

Considerations

I've seen a couple examples where a formalized technical "blue-print" for how services should be constructed across the enterprise has yielded significant benefits.  First of all, the service developers are not left to make their own fine-grain decisions for how services should be constructed on a project-by-project basis.  But rather focus can be re-directed towards business logic and the overall solution.  Too many times I've seen developers get wrapped around the axil about things such as "so, how to we implement security for our service".  When these details are landed in a blue-print it provides a platform for the I.T. organization to reach a common understanding and agreement for how services will be built technically. Question marks are minimized for developers and consistency is the net result.

From my experience, it is a best practice when the underlying service blue-print is implemented in a common framework.  This is the technical foundation that all services are built on top of.  At a high level, the key benefits include:

1. A rich service framework increases the odds that services will be constructed with similar "look and feel".  As a best practice, the items enumerated in the previous section should be isolated from business logic as much as possible by the framework.
2. Developers leverage a common code library to implement services.  Focus and energy can be redirected to service-specific interface definition, business logic, and configuration.
3. Hard problems can be solved once and embodied within the framework to be consumed by all.
4. When a change is needed to the underlying implementation, it can be changed once within the framework.  And incorporated by each development organization.

The goal of a common blue-print and framework for service development is to enable each development team to roll out services across the enterprise with a measure of consistency.  Ultimately, this consistency enables clients/consumers to reap the benefits of reduced effort and complexity when interacting with multiple services across the enterprise.

Now, think about the earlier scenario.  In taking this approach, the development team will invoke the first service as part of building their user interface.  As the team proceeds to invoke their second, third, and fourth service it will be done just like the first.  The team will not have to pause to learn anything new or implement semantics that are unique to each service.

Formalizing a common blue-print to reach agreement across the organization can be challenging.  Allocating time and priority to build out a common framework is well worth the effort.  The rewards can be very tangible and ultimately contribute to achieving a high-value Service Oriented Architecture.

SOA: Responsibilities of Service Providers (Part 4)

This blog post is one in a series. An overview and general outline of this series is linked here.

Responsibility 3:  Publish and commit to a defined level of service (SLA). Publish planned vs. actual performance, and availability metrics.

Background

“You manage things; you lead people” -Grace Hopper, invented the compiler in 1953

"If you can not measure it, you can not improve it." -Lord Kelvin, British scientist

It is difficult to effectively manage anything significant without metrics.  Managing performance and availability should be treated no differently, especially when very aggressive requirements are in play.  In a Service Oriented Architecture, services are the "things" to mange.

Ineffectively managing performance and availability can create problems.  A couple examples include:

• Critical business functions may be negatively impacted when availability and performance levels are unknown.  When interfaces are created from clients to services that do not support the required service level, it can result in business and/or direct customer impact.
• Lack of confidence in a service.  This can result from clients/consumers experiencing unknown, sporadic outages and performance issues.  When confidence is lacking this becomes a barrier to adopting shared services and achieving reusability.

Considerations

Historically at FedEx, Customer-Supplier Alignments have been a useful tool to synchronize needs and expectations between groups that are dependent upon one another.  This parallels a Service Level Agreement (SLA) in concept.  With either, the bottom line is effective communication and aligning expectations between constituent groups.  Much has been written about SLAs by others.  I will only hit on a few key points.

Service level management effectively starts as a Design-time activity and requires Runtime enforcement. /* TODO blog details later */  Your focus and mileage may vary depending on how critical the service is in terms of the availability and performance requirements it must meet.

Capacity Planning

When a service is being developed, analysis is required to determine the requirements of the service.  This is typically started by analyzing the types of business processes that will be supported.  A service supporting customers placing orders via the web or 800 number can be very different than supporting back office batch processing.

Each client application (service consumer) must quantify performance and availability required.  I typically like to quantify requirements using:

• Requests per second (average and max during peak hour throughput)
• Response time per request (average and max tolerable response time)
• Minutes/hours downtime tolerable per hour/day/week/etc.
• Business impact of not meeting above requirements

Formal capacity planning/analysis is done to ensure the requirements can be met as-is or by adding hardware, or taking other measures.  The more aggressive the performance and availability requirements, the more formalized the planning activity should be.

Capturing Metrics

At run-time, the service should be instrumented to capture actual performance metrics.  These are most useful when captured by client/consumer--this level of detail can always be rolled up to an overall number.  Useful metrics to capture are requests per second and average response time for a given interval.  

Alerts when performance falls out of variance is considered a best practice, especially when measures can be taken to address degradation.

Services hosted by eBay and Twitter for example implement "rate limiting" features.  This is to prevent a run-away client's unplanned volume from impacting the ability to meet service commitments for other clients.  Typically this is implemented in a very simple way to enforce the SLA at run-time.  I prefer two levels of alerting:  a warning threshold and an absolute ceiling by client resulting in requests being turned away for specified interval.  /* TODO blog details later */

Planned vs. Actual performance and availability metrics should be published.  This is a critical tool to assist formal capacity planning.  And while alerting for outage conditions is a must, keeping metrics for total outage minutes, for both planned and unplanned events, is considered a best practice.  These details are very useful for building confidence with current and future consumers.  Also, measurements such as these drive improvements to meet business needs, depending on the criticality of the business processes supported.

Details regarding service security will not be outlined in this post but I don't wish to minimize it's importance.  A critical success factor is being able to reliably identify each client uniquely.  This will assist troubleshooting, enable metrics to be captured reliably at the client level, and allows the client's SLA to be enforced at run-time.  Allowing anonymous or rogue clients to invoke a service can skew metrics and cause other manageability issues. /* TODO blog details later */

Level of Rigor May Vary

The level of rigor applied can vary depending on the criticality of the service.  When developing and managing a service that demands high-performance and high-availability, it is difficult to imagine taking on this challenge without considering the key elements of this principle.

SOA: Responsibilities of Service Providers (Part 3)

This blog post is one in a series.  An overview and general outline of this series is linked here.

Responsibility 2:  Meet performance and availability requirements. As requirements and usage patterns change over time, be prepared to adapt.

Background

Sometimes we encounter situations where an existing service does not meet the performance or availability requirements for a new project.  Resolving the matter often involves a technical constraint of some variety.  Here are a couple examples:

• The service makes very heavy use of database stored procedures.  The approach to scalability long term is complicated.
• The service interface supports very large request/response payload sizes.  The worst case is probably where an "unbounded" size is allowed (e.g. by the XML Schema Definition or XSD).  Under low volumes the service may work fine.  However, the service becomes unstable as volume and number of concurrent requests increases (e.g. due to exhausting the JVM memory allocation).

Issues such as these and/or organizational concerns can prevent changes from being made in a timely manner to meet requirements.  This can impact the re-usability of a service.

Considerations

This requirement, or principle, is front and center so it is clear to service providers the architecture must scale to meet current and future requirements.  Even a re-architecture should not be out of the question for any unforeseen situations.  The service provider must have "ownership" of a solution to meet the purpose and general objectives of a SOA.

Typical patterns and decision points:

1. Implement stateless request/response services that scale by adding additional computers or virtual machines behind a load balancer to handle additional volume.
2. Use of an "intelligent" load balancer to direct requests away from failed instances during a period of outage (as opposed to static DNS RR).
3. Clear separation between data persistence and application tiers to enable each to scale independently.
4. Business logic is best suited in the application tier where scalability is much easier to achieve. If there is a belief it belongs within a stored procedure to meet performance requirements, evaluate this belief very carefully. (Maybe I'll cover this topic in a later blog post.)
5. Where applicable, an in-memory caching strategy can and should be employed behind the service interface to meet aggressive requirements.
6. The application team must make critical decisions around the appropriate level of granularity for the service. For instance very fine-grain RPC style invocations are typically not appropriate when the technology is SOAP or REST over http. A more coarse-grain approach is best with these technologies.
7. Where applicable enable a client to submit multiple "units of work" in a single request. This will cut down on the number of round trips across the network.

In a later installment, we will touch on a related topic--Service Level Agreements and measuring planned vs. actual metrics.

SOA: Responsibilities of Service Providers (Part 2)

This blog post is one in a series.  An overview and general outline of this series is linked here.

Responsibility 1:  The functional needs of the enterprise as a whole must be considered to maximize reuse

Background

It can be common to find feature/function duplicated across multiple applications and development organizations, especially in companies that have been around a while.  For instance, "address validation", "geocoding", "credit card validation", and "currency conversion" are examples of functionality that might be duplicated.  In each case, the features might differ, the underlying technology might differ, and where applicable underlying software vendors might differ.  Ultimately this duplication translates into increased hardware, license, labor, and maintenance costs.

What are some reasons duplication exists?

In using "currency conversion" as an example:

1. Technology and platform differences:  A distributed application invokes currency conversion directly using a C API.  A COBOL application uses currency conversion on the mainframe and inaccessible to distributed applications.
2. Differing requirements:  An application area supporting North American operations deploys conversion between U.S. and Canadian currencies only.  At some other point in time, another development area supporting international operations requires conversion for a broader set of countries.  Or an application needs "historical" conversion rates but the service owner is only able to support "current" rates.
3. Differing priorities and timelines:  An existing service cannot be extended to meet the needs of others due to project workload and competing priorities.
4. Ownership considerations:  An application area is unwilling to take responsibility for any impacts resulting from outages.  Or is unwilling to coordinate changes/testing with any other development groups.
5. Differing performance and availability requirements:  An application team with more stringent availability or performance needs decides to deploy duplicate capability to maintain control of their own destiny.
6. Lack of visibility to existing services that are available

At this point you might see a common thread:  some of these relate to underlying organizational considerations/issues.  Additionally, without a productive governance program, issues are accentuated in organizations operating in vertical silos (e.g. associated to line-of-business) as opposed to certain functions aligned in a more horizontal manner.

These items are sometimes used as justification for sprouting duplicate functionality.  An archaeological dig into the history of how duplication came to be is educational.  Sometimes the reasons for duplication can be rationalized.  And sometimes the reasons aren't valid at all, especially after a certain amount of time has passed.

Considerations

When building a new service or transitioning a legacy environment to common services, it is important to ensure "functional ownership" is clear.  Achieving reuse can have different context.  Some services have utility across the enterprise.  Others are more domain-specific but hold the promise of greater use across the enterprise in the future.  This is the reason I slipped the word "enterprise" into Responsibility 1.

To paint a simple picture of a good "currency conversion" service, it is one that maximizes reuse for both today's use cases as well enables future use cases to be supported.  It supports currencies for the countries presently served and can expand to support other countries when needed.  It supports conversions for current conversion rates as well as historical rates if there is a need to do so.  And the architecture and development team is able to flex to meet additional functional, performance, and availability needs to maximize reuse across multiple applications.

This can be difficult to achieve without organizational considerations and/or a formalized governance process.  Additionally, standing-up a service suitable for the enterprise requires the ability to perform a necessary level of business analysis.  This is to ensure the broad functional needs of the enterprise are identified.

As briefly mentioned in a prior post, the goals of SOA typically involve reducing duplication and increasing reuse as a means to promote a more cost effective and agile operating model.  It is difficult to meet these objectives without taking at least the spirit of this principle seriously.

Next time I'll explore...Responsibility 2: Meet performance and availability requirements. As requirements and usage patterns change over time, be prepared to adapt.

The 7 Responsibilities of a Service Provider in an Enterprise SOA (Part 1 of 8)

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):

1. The functional needs of the enterprise as a whole must be considered to maximize reuse and minimize duplication.
2. Meet performance and availability requirements. As requirements and usage patterns change over time, be prepared to adapt.
3. Publish and commit to a defined level of service (SLA). Publish planned vs. actual performance, and availability metrics.
4. Implement common interface format and semantics applicable to the type of service.
5. Implement business rules and edits to ensure the validity/integrity of the operation and any data that is mastered.
6. Implement formalized change management. And implement interface versioning to limit the number of clients impacted by changes (decoupling).
7. 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.