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.
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.