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.

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!)

Page Break

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.

Infrastructure, architecture and technology drive internal SOA efforts. They focus on data migration and regularly apply a system-by-system approach. Developers modify each system until it provides a rudimentary, common interface en route to fully shared data and services.

You can achieve an internal SOA effort in pieces, allowing simultaneous access using legacy interfaces while a migration toward fully integrated service delivery is under way. But that doesn't mean it will be easy. Many internal systems were designed or acquired with a proprietary, silo-centric mind-set that lacks the interoperability required for SOA. Plus, this mind-set may pose budget challenges. SOA's cost justification is most difficult when the data appears voluminous and was generated for a specific department or enterprise. Internal SOA efforts require costly system or data migrations, making it difficult to justify or accurately measure ROI. You need a strong project sponsor and top management commitment. Related projects can last years and cross fiscal boundaries.

On the positive side, internal SOA efforts tend to conform better to functional management guidelines and controls. They encourage corporate uniformity and consistency, and they can follow a "do it right the first time" approach. Delivery time lines may therefore be longer.

Once in place, internal SOA can be adapted to multiple product offerings, managed and measured for success relative to corporate goals. You can phase projects to better manage and focus specialized resources (such as systems security or Web interface design), rather than repeating related and potentially expensive efforts. Internally generated solutions are applicable to far more diverse situations.

External efforts tend to evolve from a service delivery strategy. They gather and deliver only the content that is required to meet consumer demand or business objectives. External SOA requires that the business establish an entire delivery pipeline. The solution must often address order placement and fulfillment, security and audit, billing and payment processes, and customer profile acquisition and maintenance-simultaneously. External Web services are a common indicator that an SOA pipeline may be in place, although few Web delivery mechanisms are entirely SOA.

Page Break

It often is easier to identify and meet outside customer requirements (which are singular or focused) than to deal with the specialized requirements of divergent internal divisions and departments (each demanding that its needs take precedence). Once an external pipeline is built around SOA service concepts, you can keep the customer happy by regularly changing to meet consumer demand. More important, someone is probably paying you to develop the software. You can match external SOA efforts against revenue generation to measure ROI.

On the downside, lean, consumer-focused approaches make the business susceptible to market shifts and do not always support measurement or course correction. Duplication of system function and information content is common since there is seldom time to wait for internal system migration. Externally focused SOA less often meets the information or reporting requirements for internal departments, and operational information is relegated to secondary importance. Functional departments peripheral to the revenue stream have little say in additional SOA efforts, even if they can demonstrate potential benefits.

The concepts and components of SOA do not differ between internal and external efforts. Each approach merely attempts to tackle business delivery along a different path-hopefully, a path that recognizes and is leveraging the strengths of existing business strategy, process and technology.

Steven Fullmer is president of Blue Sphere Solutions, providing outsource CTO services to emergent and growth-oriented businesses. He has designed, developed and deployed technology solutions in the supercomputer, financial, security, telecommunications and Internet industries. He has regularly managed projects based on his analysis into practical application.