SOA Anti-Patterns When Building Services

When building services and service capabilities for your enterprise you have ensure that you have right set of practices to succeed as a service provider. Here are a set of anti-patterns to avoid building enterprise service capabilities as part of your SOA initatives. You can use this as a list of things to watch out for and possibly course correct when/if you recognize them in your teams.

Project Focus Only – Service capabilities are being built for projects and their behavior tends to be project-specific. This myopic view tends to introduce needless tight coupling into your services (making assumptions about client behavior, persistence of state, as well as how the request/response models would be structured etc.). Being too project focused also doesn’t give your firm the opportunity to evaluate existing services, overlapping/redundant functionality.

Ad-hoc Reuse – ad-hoc, minimal reuse occurs if you are lucky. Lots of redundant service capabilities being built. More worrying sign: each of these capabilities don’t leverage the same underlying implementation environments, object libraries, etc. increasing development, maintenance, and testing costs.caution

Assuming all your services will be Web services – SOAP over HTTP is the default and only supported mechanism for services. Services only get consumed via on-demand request/reply. No support for asynchronous messaging or REST-ful services. Idea isn’t to have all these flavors – the point is to have the flexibility to meet business needs and not be rigid about the packaging and transport choices.

Building services for a single platform – Near universal platform homogeneity. Assumption is, majority (if not all) consumers are invoking service capabilities from a single platform.

Semantic and syntactic cacophony – Service contracts are minimally aligned with your enterprise’s logical data model resulting in inconsistent naming, definitions, across services. Additionally, there are redundant data type and business entity definitions across services. This results in incompatible data bindings as well as increased maintenance costs. Not to forget it is downright confusing for your consumers to keep having to write code to parse related service capabilities.

Not Validating Service Requests – non-validating services provide a legitimate entry point for invalid data to be interacting with your reference data and operational systems. If you have got no data validation rules, how will you know you have got bad data? You will often end up fixing corrupt data so they don’t cascade to batch jobs or processes.

Minimal or no integration assistance – integration efforts tend to happen on a per-project and/or per-service capability basis. This results in increased pressure on development teams to help current and prospective consumers evaluate services. When there is inadequate documentation combined with ad-hoc knowledge sharing across projects it is a lose-lose situation for both the service provider and consumers. If you aren’t learning and capturing technical/process/data related integration issues it is sure to be a disruptive experience for every consumer that uses your capability.

Do you have additional ones to add to this list? In the next post, I will explain how to turn these around so you can build strategic services for your organization.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Advertisements

7 Responses to SOA Anti-Patterns When Building Services

  1. william says:

    Not defining SLA – It is important to know how much request can be handle by the service. It also helps capacity planning

    Not categorizing services: each service should fit in a service catalogue that is built incrementally and following a common taxonomy.

    Not defining standards for XML schema, WSDl, WADL, JMS, URI naming, etc. It is important that all services follow some common technical standards.

    • Agree William.

      When you say categorizing services, do you mean categories in the company’s problem domain? or broad service categories such as entity services, task services, utility services etc.?

  2. […] SOA Anti-Patterns When Building Services « Art of Software Reuse artofsoftwarereuse.com/2009/09/30/soa-anti-patterns-when-building-services – view page – cached When building services and service capabilities for your enterprise you have ensure that you have right set of practices to succeed as a service provider. Here are a set of anti-patterns to avoid… (Read more)When building services and service capabilities for your enterprise you have ensure that you have right set of practices to succeed as a service provider. Here are a set of anti-patterns to avoid building enterprise service capabilities as part of your SOA initatives. You can use this as a list of things to watch out for and possibly course correct when/if you recognize them in your teams. (Read less) — From the page […]

  3. […] SOA Anti-Patterns When Building Services « Art of Software Reuse Key anti-patterns include having only a project focus, and ad hoc reuse (which I suspect would be highly correlated). Good list of things to watch out for when building services. (tags: soa) Posted by Sandy Kemsley on Thursday, October 1, 2009, at 1:01 pm. Filed under BPM. Follow any responses to this post with its comments RSS feed. You can post a comment or trackback from your blog. […]

  4. […] Patterns and Practices In an earlier post I listed a set of anti-patterns when pursuing service orientation within the context of building reusable software service […]

  5. […] contract tends to get expressed using the underlying technology platform – one of the many anti-patterns to avoid. This inhibits interoperability and increases integration effort for service consumers. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: