A pessimistic approach towards SOA seems to prevail in The Future of SOA. But these opinions strike me by surprise. In the industries I am working for - public sector, healthcare and Defense/ public security - SOA is predominant and you will find only rare examples of tenders where SOA is not highlighted as the guiding principle for the whole architecture. SAP's CTO The Future of SOA has already provided the community with some very helpful insights concerning these discussions.
I just want to add some points from an architect's point of view:
From my point of view it is not the SOA approach itself which should be questioned but the way how we architects sometimes work on SOA. Some of the mistakes that are listed below I have encountered during my SOA projects. Others are based on discussions with other architects and decision makers inside and outside SAP, from customers and from partners. My intention is simple: I want to help to avoid these mistakes in the future and to strengthen the SOA approach which is for me without an alternative.
The business process know-how for the architecture is not sufficient (the knowledge gap)
Service oriented architectures require a new type of architect which combines a deep understanding of the business needs with good technical skills. Just take the example of disaster management: A lot of research has been done over the last years how to improve disaster relief operations by building SOA. In reality disaster management commanders are no-nonsense guys. You will not get in a buy-in for your architecture if you simply do not know exactly how a disaster management operation is conducted, what the key processes are, how the chain of command looks like and what the real pain points are from a commander's point of view. Just have a look of a good example how to address this challenge by the SOKNOS team. For the architects SOA means a much broader approach compared with implementation projects in the past as many SOA projects address a much broader scope of business processes.
The architect uses SOA more than twice in his initial C-level presentation (the presentation gap)
Most of us have had at least once three slides in decision maker presentations where we speak about web services and standards. Just get rid of them. Executives are either not interested in technical details or they know them anyway (otherwise they would not be C-level executives). They are interested in the business improvements which could be delivered. This leads to another area for improvements.
The architect could not explain a real business case for the proposed SOA (the business case gap)
SOA projects must have a clear business case which can be explained in one sentence. Just compare the two statements:
- a) We would like to build up a SOA for the HR business area. With this approach we would like to make it more agile and create better services.
- b) We will reduce training cost for the new product by reusing training materials which have been created in different locations and different lines of business with different systems.
Although a) also has its justifications it would be extremely difficult to get a buy-in here whereby b) would be much easier. Nevertheless the second approach is just a concrete business case for the advantages you could achieve with the first one.
The architect does not know the ES bundles on SDN
SAP's SOA approach is different. Enterprise Services already include semantics, the "business knowledge". If we just look back to the business case for the training management mentioned before an Enterprise service bundle is provided which could help the implementation tremendously. Do not get me wrong: An ES bundle does not solve all your challenges even in this limited case. But it clearly demonstrates the message: A SOA based on SAP's plattform is not only about technology but it is about business content and technology delivered by SAP. Therefore the deep knowledge of the ES workplace is a must for all architects.
The architect has no hands-on SOA experiences
Business knowledge can not replace technical knowledge for SOA projects. I have highlighted the need for better business knowledge before. But on the other hand architects must also gain experience with SOA hand-on stuff. Even if it is very probable that you will never develop a single service you will not be able to get the buy-in from the technology guys if you have no hands-on experience. How granular should an enterprise service be? Which services should work together? Just take a little exercise: Just look back at your last implementation projects before SOA with several systems working together and just try to define 5 services for a small business case (e.g. a digital invoice). And please just do not leave the ES bundles out!
The architect is concentrating on the UI in his initial design
The user experience is crucial for the acceptance of the system. All of us in the SAP community knows this statement and support it. But with SOA we sometimes need to step a bit away from it. By delivering services for a SOA we simply could not control the UIs for all users and simply sometimes even do not know how they look like. Just think of complex networks in healthcare. These networks link general practitioners, hospitals, health insurances and many others. It would be impossible to determine which UIs are used throughout the system.
The architect cares about the receiving system
In the pre-SOA SAP world I worked a lot on interfaces and integration issues. A key question repeated again and again was how the receiving system could work with the data and how it works. As SOA means an abstraction and you sometimes even do not know which system consumes the services all thoughts about the receiving systems are a bit waste of time if your service definition is correct. But old habits die hard.
The architect does not know the industry standards well enough
Industry standards are becoming more and more important in a SOA world. HL7 is just a prominent example from the healthcare area. In order to model a useful architecture with good services architects must know these standards very well. Although everybody will agree to such a statement the numbers of experts on standard issues is still limited.
I am quite sure that SOA will be more alive than ever in the next years and that those pessimistic outlooks for the future of SOA will be forgotten. The road to SOA is just beginning. As architects we should be key players for the success of SOA projects.
