How is SOA doing?

So how is SOA doing? There are so many products in store with the SOA sticker on the box. Great! This reminds me of the good old times when everybody claimed to have his or her software implemented strictly object-oriented. I don’t wanna be a bean counter. But I do have a couple of main characteristics that must be met to call the product “service-oriented”. First of all, essential functionalities, components and modules should be represented as services. These services must be able to talk to each other, shall be distributable and can be coupled dynamically in order to reflect business processes. This approach is especially useful for stakeholders like customers, marketing people and other sources of requirements. But I also expect more benefit from SOA for another group of stakeholders: developers and architects. A service-oriented architecture should address and support general problem domains like concurrency, persistence and a distributed approach. What I expect is that such basic functionalities should be encapsulated as services to make development faster and easier and to avoid that the same mistakes occur again and again. Sure, under the surface still exist objects, but they are covered by a service layer in order to get problems solved in a more consisted manner. If this is achieved on a broad base, developers will accept SOA as serious approach in software development.