SOA Anti-Patterns and Solutions

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.

About Chris VanHoose

Principal Software Architect at CT Lien Solutions
This entry was posted in Software Architecture. Bookmark the permalink.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.