With any technology and process change programme there are two choices
- Change the technology and process to fit the business
- Change the business to fit the technology and process
- The process and people changes to ensure successful adoption
- What the technology can do, and fitting the process and people to that
This also means that you'll want to change your seating plans so the business and architects are sitting together and talking together as a normal part of the day. You'll want to change your requirements process to be based around services, the testing process and the deployment and monitoring processes.
The technology is about understanding what there is now, and just coping with that. Don't build your own for the sake of it creating a death by technology problem just cope with what is there are look to the standards and roadmaps to understand the evolution that you have to go under. Refocus IT towards the business goals and language and learn what is really required and important and what is technology for its own sake.
Successful SOA adoption should be thought of as a change programme in the same way as vanilla SAP or Oracle is thought of. Get the technology in where it delivers value and change the organisation and process (in this case the IT delivery organisation and processes) to make it successful.
Adopting SOA technologies and not changing the practice ensure that the benefits will either be minimal or you will get the equivalent of a heavily customised package, massive overspend, reduced benefits and a nightmare upgrade cycle.
Too often I see people lob in the technology first and never have an SOA change programme. The smart companies are the ones that look at people, process, culture and technology as one thing and recognise that the largest impact comes from changing IT to fit this new approach rather than treating it just as a technology solution.