So what's hot these days in the world of SOA? Governance, registries, orchestration...? Nope. As folks looking to implement SOA seek that first killer project the emphasis is on what to do, not what you use, and that's exactly the right way to think. As SOA becomes more of a reality among the Global 2000, the focus on discipline as a concept will be as important as solutions, perhaps more important than many expect. Let me explain.

This is a clear trend that I see in the SOA space, those charged with building SOAs in their enterprise are working on establishing approaches to the implementation of their SOA instance, and aren't yet looking for "key enabling SOA technology," at least not yet. This means that they are setting up methodologies, defining deliverables, and how all of these artifacts are related. What's more they're focusing on education, understanding just what they're doing before they do it. We've learned from the past that quick movements towards a technology trend, without the proper amount of upfront thinking typically means failure.

If you ask me this is a good trend. While SOA is attractive as the hot new technology, or perhaps the reinvention of existing technology, most enterprise architects view SOA as a key strategic initiative, and aren't willing to risk failure. This is evident in the SOA's slow uptake, now accelerating, as larger organization do some advanced planning as well as get a bit smarter in dealing with the notion of SOA, keeping in mind that it's really a journey not a destination.

Finding an approach isn't that easy, however. There certainly is a great deal written on the topic by some very smart people, but the right approach for your particular organization may be a bit different from the generalized approaches/methodologies you see around today. In other words, you'll be doing some planning to create the plan. For instance, when I wrote the 12 Steps to SOA a few years ago, I was creating a general-purpose checklist of both tasks and deliverables to assist organizations in implementing their SOA. However, now I'm finding that some organizations have expanded it to 14 steps, and other reduced it to 11, again customizing the approach to their specific requirements, and that's okay by me.

What this trend will result in, just you wait and see, is a focus on design and planning tools more than implementation technology. Truth be told, there aren't many design and planning tools out there for SOA, and the ones on the market aren't impressive at all. Hopefully, we'll see some creative and well-funded start-ups in this space soon. Categories of planning tools should include:

1. Modeling and implementation. Holistic modeling of the SOA and all of its working parts.
2. Security design and implementation. The ability to figure out how you're going to secure and govern your SOA.
3. Semantic understanding and metadata modeling. The ability to identify all application semantics and define a common metadata model.
4. Service design and implementation. The ability design services properly, implement them, and track them.
5. Orchestration and process modeling. The ability to model processes and implement them directly from the model.

So, if you're focusing on what you need to do, you're in good shape. Those that jump directly to "what to use" are fooling themselves into thinking that a lack of understanding of the problem domain will be overshadowed by killer technology. That never works.