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.

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.