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.
Of course, there are other process things to do, including the creation of test plans and selection of testing tools for the services. Also, you need to create a SOA governance strategy, determine the governance process based on that strategy, and select tools to support the creation and enforcement of governance policies.
Architecture: The core of SOA is usually given short shrift
The "A" in "SOA" is "architecture." Most people forget that, opting instead to jump right into the technology. Why? Because architecture requires a huge effort and is boring, whereas playing with cool technology is fun and fast. Unfortunately, you really have to spend the time to plan and lead the enterprise in the right directions. Create a strategy, processes, architecture, links to business realities, budgets, and then -- the most important action -- lead the technology teams in the proper directions.
Although architecture is fundamental to SOA, it is often neglected in so-called SOA efforts. That's because most enterprise architects within the larger enterprises don't have the authority and reach they need to drive the technology in the right directions. In most cases, they try only to influence and inform, and are more "ivory tower" guys when you get right down to it. This disrespected, powerless approach to architecture won't drive change in the long term unless there is true dynamic leadership to back them up.
What typically happens due to the low respect and profile of most enterprise architects is that tactical short-term needs trump any long-term strategy, as people try to run their business from one technology fire drill to another, dragging in all sorts of technology into the company with no clear plan as to how all of this stuff will work together.
What are called enterprise architectures are often no more than layers upon layers of these disjointed tactical efforts. Those kinds of "architectures" are too complex and too difficult to change as new business needs arise.
But if you focus on the "A" in SOA, you are much likelier to succeed. Being architecture-focused does require driving changes in how the IT department thinks about technology -- having it do so in the context of architecture, and never with the technology being the de facto architecture. This is a significant cultural shift that most IT staff won't make unless forced to. Making this change happen comes down to the leadership within the company and its support of the strategic activities. Here's why management should support the change: The current approaches waste millions of dollars a month right now. The challenge is that this waste has become the normal way of operating, so its costs are hidden within the "standard" overhead and lost opportunity costs.
Technology: Your technology should follow the requirements, not drive them
There is no one-size-fits-all SOA technology solution for all enterprises. You have to understand your requirements and match the requirements with the right technology. It's that simple.