I turned up this gem while looking for a list of common SOA anti-patterns: http://www.oracle.com/technetwork/topics/entarch/oea-soa-antipatterns-133388.pdf.
I appreciate the focus on needing to solve the organizational challenge around SOA as well as the technical challenges. I’ve recapped the anti-patterns and the proposed solutions that I took away from the article below:
- From Application Silos to SOA Silos Anti-Pattern – Solution: Establish a center of excellence or an architectural review board that will ensure communication and interaction across teams.
- Build It and They Will Come – Solution: Establish an architecture review board that will clearly define the architectural roles and communication responsibilities for the various layers of IT execution and relevant artifacts.
- Over-Engineer Reference Architectures – Solution: Architectures should evolve along with business requirements. Adopt a just-enough, just-in-time architecture that reflects business requirements and available IT resources.
- Undefined Baseline for Business ROI – Solution: Plan and budget projects with value-based milestones, and include the right contingencies – including asking for help from outside experts.
- Web Service Sprawl – Solution: Be deliberate about the creation of enterprise services and govern the design of your service contracts.
- Armchair Architecture from the Ivory Tower – Solution: Always provide usable reference architectures. Be clear about their capabilities and limitations and how they should be used. Validate your architecture rigorously.
- Scattered SOA Strategy Entangled with IT Strategy – Solution: Get and set expectations with absolute clarity when adding SOA to a project midstream.
- Expecting a Free Ride on the SOA Train – Solution: Embrace a maturity framework, build a shareable enterprise foundation, and invest in enterprise-wide training and adoption.
- Where’s the Money? Or SOA Equals EAI 2.0 – Solution: SOA is more than an ESB deployment and is not just a matter of using Web services for interfacing between systems.
Many thanks to Peter Heller for writing this article.