Infrastructure-Driven Approach
The infrastructure-driven approach primarily delivers benefits only for utility services (also known as foundation services). This is because in the infrastructure-driven approach, services built in a reasoned and well-planned manner are meant to provide a solid foundation of software utilities, such as logging, exception management, and e-mail. Generally, this means that strategic portfolio planning as well as architectural and design policies will typically be limited in scope to building out and deploying these foundation services. It's very likely that services built outside of this initiative still won't be governed by these policies, standards, and best practices, meaning reduced overall interoperability, and lowered reuse.Good candidate projects for the infrastructure-driven approach are integration (especially dealing with master data management), consolidation, and mainframe migration or modernization. To ensure success with this approach, it's important to standardize on the technology platform on which these services will be delivered. Although using industry standards can help provide level, out-of-the-box interoperability, it's also vital to consider following well-defined design standards to help sustain it across changes and evolution in industry standards. One of the most important aspects is to instill the practice of designing for reusability. Of course, all this requires support from management, especially in terms of budgeting for building out the SOA platform, utility service development, and an operational model for services that takes reuse into account - after all, there's little point in getting reuse if the reused services fail to perform! Because these types of services don't directly provide business value or benefits, it can also be a challenge to justify ROI beyond reuse of a common technology platform.

Fortunately, the infrastructure-driven approach will provide valuable experience in building, deploying, and managing shared resources. You'll also learn lessons about issues and challenges involving access control, security, availability, and overall quality of service in a more controlled environment. What you won't get is a high degree of reuse and interoperability across-the-board in services created by non-infrastructure-based projects - yes, you'll get your e-mail or logging service use everywhere, but you may end up getting four different customer services, each with different operations and developed by different groups. This redundancy arises because none of these customer services were designed to be delivered as reusable services. As a result, the cost savings will be limited to reusing utility services and a common SOA platform. As mentioned earlier, because the scope isn't very broad, any projects done outside this scope won't benefit from the governance, best practices, and other elements employed for infrastructure-driven SOA.

The infrastructure-driven approach requires capabilities at Level 2 in the Oracle SOA Maturity Model. Refer to the Cheat Sheet to learn more about what's required.

The Project-Driven Approach
As the name suggests, all the deliverables are driven by requirements specific to a project. Typically, involvement of the business is limited to mandating its needs and rarely includes collaborating with IT to define business processes and services.

Examples of project-driven SOA typically include integration scenarios. For instance, consider an order-to-cash business process that requires data to be moved between a CRM system and an enterprise resource planning (ERP)-based order management system. This type of integration is not new and has been around for years using a range of technologies, from file-based batch integration to message-oriented middleware (MOM)-based integration. They are all rigid, point-to-point in nature, and highly proprietary. All of these factors meant that these solutions are costly to deliver and maintain. Using SOA-based tools such as BPEL engines or Enterprise Service Bus (ESB), it's much easier to build sustainable and flexible standards-based integration. Note that benefits derived from these projects are generally limited to ease of development and standardization of integration.

If a project uses a more standards-based SOA tool and platform to perform data integration, it's likely that any services created are very specific to the project. If the project creates any reusable assets, it's probably by accident, especially in the absence of appropriate planning and governance. Even if none of the services are reusable, these projects help establish a technology foundation as well as enhance IT skill sets.

The downside of the project-driven SOA approach is that it generally creates a new batch of silos, albeit with a service-oriented flavor. Instead of reducing the long-term integration effort, it lets integration become an ever-present headache. It's obvious that to be able to capitalize on your project-driven SOA successes, you need to plan on transitioning either to infrastructure-driven or enterprise-driven SOA. Which path you take will depend on your capabilities, your organizational readiness, and the degree of buy-in from business and management. However, project-driven SOA is a good place to start. David Chappell, Oracle's vice-president and chief technologist for SOA, touches on the importance of project selection in his blog.

The project-driven approach requires capabilities at Level 1 of our SOA Maturity Model. Refer to the Cheat Sheet for more details. Generally Level 1 capability requirements aren't onerous.

What Will Each of These Approaches Get You?
Given these three distinct approaches to adopting SOA, it's essential to be aware of the approach you're taking and articulate that to the line-of-business IT team. So now that we know the key SOA benefits from both the business and IT perspectives, as well as the enablers of those benefits, we can map them to the three SOA adoption patterns outlined previously. This mapping is shown in Figure 5.

The table makes it clear that maximum benefits are gained through the enterprise-driven approach. The corresponding benefits of the other approaches are more limited. The takeaway from Figure 5 is that it's hard to get reuse (and we've seen this in practice) with the project-driven approach, which typically presupposes little central planning or coordination across projects.

Of course, many of you who've done some projects with SOA tools will say there's no need to do anything beyond the project-driven approach to get a catalog of services (that are actually reused): just buy some tools, get each project to use them, perhaps get the EA group (if you have one) or architects' collective to define some interface standards, and then set everyone loose to build their own services. With this approach, you'll have hundreds of services before you know it. This service proliferation typically means that you'll end up with a bunch of services that overlap, because there's no central planning that addresses which services should be built, when, and by whom (governance). If that's what your vision of SOA is, that's great, but be aware of which of the SOA benefits you will typically not be able to deliver.

Without a planned approach that pays particular attention to reuse, you end up with several siloed applications, even though they were supposed to be built by use of services. The reason they are siloed is that the overarching service planning and governance aspects were absent, which resulted in production of very few or, in many cases, no reusable assets (more on this later). In other words, if projects are charged with producing specific reusable services in predictable ways, is there any hope that they will deliver anything of use to anyone else? In the long run, these service-based siloed applications may end up adding to the overall IT maintenance cost, rather than helping reduce the cost via reuse and increased flexibility.

The choice is really clear: let each project do its own thing in its own way without any oversight whatsoever, albeit with modern tools built for SOA (which isn't totally bad), or look for a better way to do those projects so that they end up contributing assets to the department/enterprise. And that better way involves incorporating some planning early on to identify reusable business services.