Internal and External SOA: What's the Difference?
You need to decide whether you want quick returns with a limited external SOA deliverable or can afford to dedicate yourself to a thorough, internal SOA project and delay a larger return for years.
Wed, August 20, 2008
CIO — 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's 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!)
Developers across all industries regularly distinguish between externally and internally focused SOA, or at least they identify efforts separately. Results suggest vastly different approaches, with identifiable stages, time lines and the probable path of an SOA evolution.
The Evans Data North American Developer Survey series has been tracking a shift from an internal to external SOA emphasis for several years. Most developers still put most of their efforts on internally focused SOA efforts, implying that infrastructure must be in place before robust external solutions can be fully or cost-effectively implemented. Despite internal requirements, external efforts continue because they fund internal change. The evaluation and implementation of service components are done in a different sequence, for instance.
