Now let's go into a bit more detail and discuss a possible way to introduce SOA. Be aware that this is just one possibility; it is more an example of an iterative establishment process than a guideline for how to adopt SOA. However, it might give you some ideas for how to find your own appropriate procedure.
A necessary first step for introducing SOA is to understand it. SOA is hype, and therefore a lot of stupid things are said about it. Don't introduce SOA because your major business analyst recommends that you do so; do it because you see the benefit. Unfortunately, the benefit is not always easy to see. Learning about the differences between small and large systems and between central and distributed control is key (see Chapter 1 and Chapter 4, for example).
In addition, before you begin down this path, it's crucial that your management accepts that SOA is a strategy, not an out-of-the-box solution, and knows about the possible consequences of implementing this strategy (especially what it means to have distributed processing; see Chapter 8). Of course, on a management level, you can't necessarily discuss the details of versioning and idempotency. However, it's important that the concept of loose coupling and its consequences be understood.
Another important message is that SOA is not a silver bullet for any kind of system integration: rather, it is a concept for dealing with distributed business processes. Database replication and decoupling ...