One of my favorite sayings is, "if you don't know where you're going, any direction will do." While in many cases people take that as license to do whatever they feel like, what it really means is that before you embark on a journey, you should plan your destination. You know, get out the map, plot your direction, find out where you want to go, and what you want to accomplish along the way.

SOA is a journey, and also a destination. For most organizations, SOA is the end goal of the IT organization. They've begun to realize that SOA is the way that they will ultimately run their organization's software (and to a certain extent, hardware too). Their vendors have all begun shipping their software as services, and they may even be using web-based software as a service such as Salesforce.com. So it's now time to understand the destination.

In order to do that, a wise organization creates a Roadmap. Just as you might consult an atlas (or MapQuest these days) to see where you are going, understanding what the stops are on the journey toward full SOA implementation and planning on how to reach them is also critical. Just as you might decide to take a scenic detour for your own enrichment (who doesn't like seeing the changing leaves on some windswept country road over the weekend rather than driving down a soulless interstate), your company may very well choose to take a road less travelled for strategic, tactical, functional, or even financial reasons.

It's one thing to take the road less traveled upon careful planning. It's another entirely to miss the street sign and go off road - it causes detours and rework, not to mention annoyances and loss of credibility with colleagues and the executive committee.

For many reasons, a roadmap for SOA is important, perhaps even critical to the success of the journey, or at least of the team making it. A roadmap for SOA has many aspects. It has foundational elements that include network and hardware, as well as operating solutions. In the modern age, this includes capacity on demand, virtualized containers, and occasionally connected computing. In addition to being the platform that the SOA will run on, these foundations often expose services of their own that enable the creation of more complex business logic or exception handling.

Other elements are also important on the roadmap. The Enterprise Service Bus is a key architectural element - without it you have a point-to-point wiring issue that ultimately becomes even worse than the problems we were trying to solve in the first place. This is an area where companies seem to take detours frequently and one where, in most cases, they really should stick to the roadmap. It's a lot easier to put in an ESB and adapt to it when you start then after you've done a number of implementations.

One area that needs to be considered is the overall maturity of the organization with respect to SOA. There are multiple dimensions of maturity - you can look at technology, standards, security, governance, and management. All of these areas have different qualifications and levels associated with them that lead to an overall maturity level.

A typical roadmap identifies these dimensions as well as the projects that will be undertaken to get to the end goal. In security it may be a first project toward single sign-on that will eventually lead to the basis for security as a service as part of the underlying infrastructure. There may be a discussion of core IT services that should be provided as part of the infrastructure. There may be a rationalization project to help align redundant business processes or applications. A good roadmap is multi-dimensional and includes a timeline. It may even (dare I say it) outline the dependencies each project has with respect to one another. Finally, a good roadmap is hard to create. It takes insight, it takes commitment, and it takes leadership. Before you take another step, ask yourself: "Do I know where I'm going?" If not, it's probably time to get out the map.