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.

    Inaugural post

    Welcome to a stream of random thoughts about technology.

    This is my first blogging experience.  I plan to share experiences applying technology to solve business problems.  And interesting tidbits I run across from others.  It is my hope a few folks will find interest in what is posted here.  I look forward to your comments and learning from your experience regarding the topics posed.

    I've spent in the neighborhood of 20 years working in the field of Information Technology.  Over the past 12 years, my primary focus has been leading or advising large-scale software development projects, with global operational impact, for a Fortune 100 company.

    Most of my time is spent these days with enterprise architecture planning and related concerns.  I'm often engaged in business analysis, software architecture, software design and coding, database design, messaging, performance tuning, and capacity planning.  In recent years, Java and Linux have been the widgets of choice.  Typically, I am involved in operating systems, networks, and other infrastructure items only when necessary, which seems to be quite often. :-)

    In recent months, I've been consumed with implementing an application that is deployed across 3 (or more) geographically-distributed data center locations in an Active/Active configuration.  The design enables requests to be serviced from any data center for high-availability and fault/disaster tolerance.  Another focus area is application modernization.  As a result, of special interest is Service Oriented Architecture (SOA) and Event Driven Architecture (EDA) based solutions deployed and managed at "enterprise scale".

    Some useless trivia about me:
    • I grew up on a farm outside Natchez, Mississippi.
    • I was a walk-on football player in college and earned a full athletic scholarship.  My teammates and I enjoyed participating in 3 bowl games.
    • I'm an avid SEC football fan, having missed only 1 Ole Miss home football game since 1988.
    • I'm a lifelong New Orleans Saints football fan.
    • My first computer program was written in BASIC on a TRS-80 Model I.
    • My first "corporate" computer program was written in COBOL on an IBM 3090 mainframe.  I still think JCL is cool.
    • Nostalgia abounds.  I've developed software for PC, AS/400, and UNIX (Linux, Solaris, HP/UX, Siemens RM600, Pyramid Nile, AT&T 3B2) platforms.
    • I dogged Apple for 30 years.  Until I bought an iMac to do some iPhone development.
    • My first application for Android, SEC Football Guide 2010, received notice as a Top 20 application by Information Week.
    • I produce a weekly radio program on Sports 56 WHBQ in Memphis, TN USA
    • I was a youth football coach (Defensive Coordinator and Kicking/Punting) for a couple years in the OBYFCL league.  A very rewarding experience.
    Last revised: February 9, 2011