At the management and staff levels, the people requirements for successful SOA are even more fundamental. Although many would love to have the existing team drive them to the new world of SOA, the harsh truth is that many in that team won't have the skills or the aptitude. You need to make some hard decisions up front as to who will take you forward. This means you must replace people or you must augment staff. Either approach is costly.
Many companies employ mentors or consultants to help learn the new ways of SOA. Others invest in SOA training, or even bring in entirely new teams as either consultants or employees to assist in "the change."
No matter what you do, never, ever try to drive SOA with the wrong people; it just won't work.
Processes: SOA requires a change in how you develop, manage, and test applications
Approaching SOA means changing how you approach architecture and systems development. In the past, many companies have approached systems by dragging whatever seemed cool at the time into the enterprise to solve a tactical problem. Of course, tactical problems lead to other tactical problems, and these companies kept digging a deeper hole in terms of architectural complexity and efficiency.
Thus, you need to approach SOA using a well-thought-out, practical process that lets you break the architectural domain down to a functional primitive, then build it back up again as a SOA. Unless you're the smallest of enterprises, you also need to break these domains into achievable chunks that can be worked on in sequence, or later in parallel.
Then it's time to do some real work, including looking at the information within the problem domain, meaning application semantics and metadata. This takes a ton of work, because most enterprises typically don't have a good semantic-level understanding of their enterprise systems. Thus, this effort is usually not a process of reviewing common artifacts, but of creating new ones. Many SOA efforts skip this step, which cripples what they end up delivering.
From the information step, you move to the services: defining existing and new services that will make up your SOA. This is all about figuring out what you have, determining what you need, and then normalizing the services into a usable and well-defined grid. You need to make sure you define and document the services, and then link them back to the metadata model you've created.
Keep in mind that most of your services will be existing services, externalized through some sort of middleware mechanism. Most people think SOA is about building all-new services, but that's almost never the case. Many SOA efforts fail because they become excuses to reinvent the wheel, not solve pressing business needs.
You then need to define and create processes that bind the services together into business solutions. There are three approaches here you can use. First, you can create service-oriented business applications, a way to programmatically bind services together into processes or applications. Second, you can leverage an orchestration layer, such BPEL, to bind services together to form business solutions. Third, you can leverage traditional process integration tools to bind services into solutions. No matter what approach you use, you need to make sure to include requirements as well as design.