Solve your Agileocrity Part II: The SOA Integration Anti-patterns
Dain Hansen's Blog |
April 4, 2008 3:51 PM
|
Comments (2)
I presented recently at the Arch2Arch Summit in San Diego a presentation on SOA & BPM: Better Agility through Business Integration. During the talk we discussed in detail some key things to avoid in your SOA Integration Architecture. These anti-patterns come especially from Architects like you who are trying to improve their architectures and build them purpose built with agility in mind.
 Anti-Pattern #1: Service-Enabled Spaghetti
We’ve seen spaghetti diagrams before. I admit it – I’ve generated at least a dozen of them. However this is a slightly different takeaway. Simply putting a web service interface to all your systems doesn’t get you the benefits of an SOA. Why is that? Because the returns of SOA are only realized when you can properly sort through the spaghetti, when you can control it, when you know how people are re-using those services, and when they truly insulate from change, and not just add to confusion. Without an organized, highly controlled, architecture, you’ll cause yourself more headache than if you had simply left your systems alone.
Recommendation: Build a SOA Reference Architecture to properly classify the intent and purpose of services. Leverage SOA Governance to be the watch-dog on what you build. Make sure you build it with an intent and purpose to be flexible.
Anti-Pattern #2: Accidental Integration Architecture
This particular pattern was referenced in the SOA Integration Blueprint Article.
Historically, integration started as a pattern to build better transparency between consumers and producers of information across multiple channels. You can think of EAI as one of the earliest forms of integration focused around application integration, ERP modernization, and B2B (a specific type of multi-enterprise integration). As SOA was recently introduced, integration evolved to meet other, more specific needs such as service mediation for web services. On the journey to integration, enterprises also recognize that data services as well as real-time events needed to be treated uniquely within other integration scenarios.
All these integration patterns are "correct," but, unfortunately, many companies struggled to adopt all of them or simply favored one but not another. The Accidental Integration Architecture emerged simply as a means to solve multiple types of integration between consumers and producers.
Recommendation: Look at Integration as components within a broader solution framework. Eliminate redundancies in connectivity, security, management, and QoS by considering a single unified solution which meets multiple integration entry points.
 Anti-Pattern #3 The SOA Silo
In this example, each project does the “correct” implementation, yet in a silo. ESBs are implemented properly, reference architectures (within the project) are consulted, and solution frameworks consider multiple entry points. However it is still wrong. Why?
There are 4 problems with this approach: 1) There is no unified management, control and visibility across the project Silos. 2) The re-use across the ESBs hasn’t been considered. It might require a federation architecture for services that are needed to span the organization. 3) There might be security, privacy issues for data that spans multiple projects. 4) Duplicates of data models where data isn’t single-sourced.
Recommendation: Look at Governance to better manage interactions across the silos where a federated registry can deal with the complexities of multiple run-time domains. SOA Management can help SLAs that span across the business. Look at ESB federation if interactions needs to span across data-centers, domains, projects and business units. Look at identity and security federation requirements. Look at Data Services or Information as a Service approaches to manage data federation.
In summary, these patterns are most likely not new, they are iterations on previous anti-patterns we have seen before in Integration. Leveraging SOA Integration together with SOA Governance and the right types of reference architecture we can start to see some of the benefits getting more agile systems.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
I guess the point I was trying to make was that given a siloed ancestry, one should try to look to new ways to consider getting out of that mindset. Perhaps 'anti-pattern' is too strong of a word, but it gets people's attention that there are new ways to think.
I believe that SOA Governance would be a simple step that gets you past the silos as one example. It is actually a compromise as you say - because you can leave the existing applications and even perhaps the integration points as they stand.
Thanks for your comments!
Posted by: dainsworld on April 7, 2008 at 8:27 AM
-
Dain,
I feel the Anti-Pattern concept can be addressed only in an Ideal world. Real world applications are more often than not, based upon their Siloed ancestors so need to be more compromising.
-Ajar
Posted by: ajarv on April 4, 2008 at 10:03 PM
|
