Internal and External SOA: What's the Difference?

SOA discussions regularly focus on concepts, ideals, scale and grand design. These won't get you to the goal.

SOA discussions regularly focus on concepts, ideals, scale and grand design. These won't get you to the goal.

In an ideal SOA implementation, the principals recognize all available information and understand all relevant data interactions. Each unique data element exists somewhere only once and can be retrieved efficiently. In this ideal scenario, you can easily design associated services to acquire and present the information in the most concise or appropriate format. All the hardware, software and data comply and integrate seamlessly. The human support infrastructure is in place, maintenance needs are minimal and service contributions are perfected.

That's a nice fantasy, isn't it? But let'come back to earth.

In reality, few business technology solutions have such comprehensive goals. Most IT projects require cooperative or shared access, which implies compromise, data overlap and duplicate process rather than optimal efficiency. You can't afford complete system replacement. (That's a nice way of saying: The techies don't always get their way.) Perhaps a more practical approach is to evaluate your path toward the eventual SOA ideals, rather than to focus all your attention on the end goal. Considering the difference between internal and external SOA implementations affords such an evaluation.

The financial industry is often cited as the poster child for SOA implementation because its solutions support both external and internal customer requirements. Whether by accident or intent, the efforts did not start with formal SOA design.

Many financial business organizations realized the value of delivering aggregate customer information through a single interface almost by accident. They had to work to gather the information from disparate systems to deliver a usable, initial product. Service elements delivered encapsulation, abstraction, reusability, composability and autonomy components before these concepts were formally defined as a part of SOA. Isn't it nice to be ahead of the buzzword curve?

When banking first became Internet-enabled, for example, competitive necessity drove technology solutions rather than did any initial strategic design. The pipelines from back-end systems to customers created services that internal departments could also retrieve and use. (Hey, Mom, look at what I found!)

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags SOA

Show Comments