3. Projects can contribute reusable services that are enterprise resources. If you're keen to get on the path to building a service portfolio then within the context of individual projects attempt to identify potentially reusable services: either utility services, such as an e-mail notification service; business services such as entity services (a customer service, for example); or business services such as an invoices service that provides operations related to invoice processing. The art of service identification is beyond the scope of this article, but suffice it to say that there are several techniques for identifying services that are bottom-up ("Which of our APIs can we factor into reusable services?"); top-down ("what are the domains in our business and therefore what are some potential services we are likely to need in each domain), or what we call middle-out, which delivers services by modeling several business processes and then aggregating semantically related operations into logical business services. There are also some industry blueprints for services, such as for insurance, although we've found that they offer a good starting point but require much work to realize in usable implementations.

Whatever technique you use, bear in mind that it's best to build services that have immediate use within a project. In other words, don't build a service portfolio for its own sake - such as by service-enabling a bunch of APIs - without a view to which projects the services will be used in and what the future business and, hence, IT requirements will be. Avoid building speculative functionality that may never end up being used or that's built in such a way that it won't be useful later on. Tactically delivered services in which you add reusable functionality run the risk of wasting time and effort and adding complexity while leading to little reuse, unless you know where they will be reused. To avoid this gold-plating problem create a service portfolio plan (a blueprint for your service inventory) and then use the projects as a means to accommodate/build services within that blueprint. Finally, develop an operational model for reusable service before any actual reuse happens - there are few things that stunt reuse more than poor service performance. So make sure you can ensure service levels as services are subject to greater traffic.

4. Seize opportunities for driving reuse, but don't force it. Even if you're taking the project-driven approach, it makes sense to get some kind of a cross-project view of what's going on, even in the context of a single department or group. It's often not rocket science to find opportunities for building reusable services. For example, we have seen multi-channel projects - Web, bricks and mortar, B2B - that have been great candidates for building reusable components. Consolidation efforts also offer ripe pickings for SOA. Many corporations drive consolidation of redundant and overlapping systems or have a legacy migration strategy. What better way to consolidate than to use SOA principles and build new applications based on reusable services? Business process management (BPM) projects are also good candidate projects for identifying reusable services, because they involve businesspeople who can help identify those business services and typically have high-level management backing, which can promote building and using services that support business processes that are being automated and managed.

5. When the time is right, start building a pool of resources that are reused across projects. By resources, we mean people, infrastructure, and services. If SOA nirvana (enterprise SOA) is your ultimate goal, organizational barriers have to be gradually eroded to enable greater collaboration across groups, pooling of resources, and some centralized planning, such as from an enterprise architecture perspective. So when the time is right, plan a migration from the project-driven approach to the enterprise-driven approach. For IT-driven organizations, transitioning from the project-driven approach to the infrastructure-driven approach, as a stepping point to the enterprise-driven approach, works well. All you need to do is pool a few people together and share a technology platform and related assets across a few projects. At the same time, building a few reusable foundation/utility services will show good results. From an architectural perspective, to improve interoperability, it's pretty important to have the enterprise architecture group define standards that should be adhered too, and ideally this group should be involved in scoring projects for their adherence to these standards. With careful planning, it's possible to seize synergies and increase your SOA maturity and related capabilities.

Conclusion
You can accomplish SOA by doing the same kind of things you did before, but with a better, more standards-based toolset. The more of the strategic SOA benefits you expect or need to deliver, the more you need to make some changes in the way you execute projects. You will also end up doing new things, such as service portfolio planning. The project-driven approach is a reasonable place to start, especially if you're new to SOA - and that's where we see most initiatives focused today. Anything you can do to increase the SOA sophistication and maturity of your organization will pay handsome benefits in terms of future project deliveries. If the SOA benefits you're delivering require a portfolio of services, realize that unless you make a concerted effort to build a portfolio of reusable services, it's unlikely that one will emerge.

If you feel that making the transition to an infrastructure-driven or enterprise-driven approach makes sense and is feasible for your organization, you'll want to build a roadmap that outlines what you will do to get there. The road map will typically include some project deliverables as well as broader initiatives related to delivering SOA, such as an SOA center of excellence if you are taking the enterprise-driven approach. A great way to build a roadmap is to use an SOA maturity model to assess where you are today and then chart out where you need to be over a multi-year period. What you want to be able to say is something like "We are at Level 1 today and, given our business goals, IT goals, and projects, we aim to be at Level 2 in 24 months. These are the things we have to do to get there." Finally, don't be perturbed by what other people are doing with SOA. Be clear about what you want from it, and progressively chart a path to get there. As Yogi Berra said, "If you don't know where you are going, you'll wind up somewhere else." Please don't end up somewhere else. Do SOA right!

Acknowledgments
The authors would like to thank Dave Chappell, Manas Deb, Thomas Erl, Harish Gaur, and Markus Zirn, who diligently read drafts of this article and provided valuable feedback.