Skip to Content

8 SOA mistakes architects should avoid

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.

You must be Logged on to comment or reply to a post.
  • Bernhard - This blog nicely captures the key points in terms of 'common mistakes'in projects involving SOA. You have rightly pointed that successful SOA project requires that people with just the right mix of business and technical skills should be in the driver's seat. Any imbalance in the skillset (too technical, or too business) can make a difference between a failed and a successful SOA project.

    - Ranjan 

  • Bernhard,

    Thanks for the blog. I agree 100% with the "technical expertise" mistake. It amazes me that people still think this is a Business Consulting job. Business consultants should certainly be involved in mapping the business processes but not the implementation - in my opinion.

    • Alistair,

      thanks for the comment. I think that the difference between business consultants and technical people will decrease in the future as a balanced skillset is needed from both worlds. Besides I know a lot of business consultants within SAP consulting which combine both skills.

      Best regards,

  • UI is an interesting dilema. Most often, without a UI mockup - it is hard to explain to a business user. And once they se and understand, it becomes difficult to move them away from draft version to final version.

    A particular isue comes to mind - mass processing. I ran into an issue recently in CRM that all SAP provided was a mass processing RFC, and no services or UIs for it. It was an interesting debate whether SAP should support UI and services for mass processing scenarios or whether it is better done by customers implementing the solution. Mass processing scenario in this case was an industry standard, so I felt SAP shoul have delivered it in standard. But there were opoosing views on it too.

    I do have a question on how SAP develops new software after SOA became the big thing. When new functionality or modules are developed - do you still develop screen flows first and then in a future date, develop services around it? or do your architects first model the services and screen flows follow from it? 

    • Vijay,

      thanks for bringing up this point.

      For me and the developments I have been involved with it is not about UI first and then services or vice versa but process definition first and then services/ UIs. From my point of view we need to differentiate. When we speak about a healthcare network (i.e. a plattform) it is mainly about services as SAP cannot control all the UIs  (e.g. for general practicioners). If we speak about another huge development - e.g. Investigative Case Management - UI is a key element. But again the process definition is decisive and UI/ services go hand-in-hand.

      I completly agree with you if there is a standard (like HL7 in healthcare) this is the foundation so that composite applications with specific UIs could be built upon it.

      Best regards,

  • I agree it's critical to have a combination of functional and technical knowledge to deliver high value IT solutions – the combined skill is essential for any IT project justification, prioritization, business case and project success. In my experience, business analysts and enterprise architects that understand both the business and technical considerations of an IT investment provide a differentiated contribution to an organizations success – this is true with SOA but equally true for the last 15-20 years in our industry.

    What I believe SOA is providing is the ability to look at end-to-end business process from both a conceptually perspective as well as an implementation perspective and not just as isolated functional areas. The SOA standards are helping unlock the proprietary applications that remain a central part of many business operations, but allows them to be more easily integrated as part of broader business process initiatives.

    All sounds good, but equally when we expand the scope to achieve end-to-end process automation it also places a much higher demand on the business architect. Why?  Well from a functional perspective it requires the architect to look at more diverse business process requirements and from a technical perspective it increases the complexity around managing information, process integrity across different applications (SAP and non-SAP), as well as increasing the security implications across these applications that often manage their own application access. So for me, as we expand SOA across functional areas, we equally need to consider the importance of a canonical view of information, designing and implementing broader security mechanisms aligned to the functional roles within the business process, and all managed with solid design and runtime governance that reduces redundancy and promotes reuse in a loosely coupled architecture. This all gets more challenging as the mix of applications, custom builds, middleware components, databases and data models increases.

    At SAP, we’ve invested heavily into an enterprise services framework that helps overcome these challenges. It consists of a common business model, data and business components and services at a level of granularity that helps maintain data and process integrity – all managed through a design time governance framework that reduces redundancy and increases service reuse. To reiterate early comments, the Enterprise Service Bundles (ES Bundles) represent a significant opportunity for business architects to deepen their functional and technical knowledge in key areas of this SAP investment. Leveraging ES Bundles can significantly reduce the complexity and risk when developing composite IT projects, a must for any BPX/SDN community member!

    • Paul,

      thanks for adding your detailled comments. I completly agree with you. The requirement to have people who understand both worlds are not new but SOA put a spotlight on this requirement.

      Thanks for emphasizing the importance of business architects. We invested heavily in the education of business architects within SAP consulting over the last years and I spent a lot of time on this topic.

      You are absolutely right about ES bundles. That´s our differentiator and therefore SOA will remain the key topic over the next years.

      Best regards,

  • Great blog! Thanks for sharing...I agree 100% with your comments.
    In addition, SOA should not be projected as a Panacea - I've seen a few architects making this mistake.

    I agree 100% on your observation reg the UI - When you are projecting the strategy to your stake holders, have a slide on Scalability, Performance and flexibility instead...Thanks again.

    • Srini,

      thanks for your kind feedback. I could not agree more with your comment. SOA in bits and pieces is nearly impossible. You need the big picture and then you can start with a smaller part delivering quick wins.

      Best regards,

  • My comments on Vishal's blog (which I think you are referring to) do not represent the slightest bit of pessmism - quite the opposite, actually.  There have definitely been mistakes made in past SOA implementations(many of which you quite correctly identify) but there have been a great many successes as well. I am a firm believer in SOA strategies as the key to enable composition of innovative business processes, user experiences, and applications.  We all just need to take a critical look at how well we have done in the past and what mistakes to avoid/changes to make in the future.  For the record, I was implementing "SOA" long before it was in style - in 1998/1999, the software I wrote was already exposing nearly 100% of its functionality via URL/XML/RPC mechanisms, well ahead of SOAP 1.0.  The benefits of this were numerous - it allowed us to abstract the "consumers" of the services (people via a UI, business processes, other applications), it create a common internal "standard" that allowed much easier composition and consumption of services (since the semantics were self-describing and easily understood), and many others.  Bottom line is that SOA has been here a while, it is here to stay, and it has a great future!  Let's as community just agree to avoid complexity for complexity's sake (or technical elegance), to make the services understandable and consumable by the average developer/business analyst, and to avoid wrapping legacy APIs as "services"!



    • Rick,

      thanks for your feedback. No, my comments did not aim at your comments as you did not declare SOA as dead as analysts did.

      You hit the nail with your point complexity. That is really our challenge and task especially in this year.

      Best regards,

    • I am still in what I consider to be the early stages of understanding SOA, its benefits, etc, so the answers to my questions may seem obvious to experienced SOA practitioners ...

      Why shouldn't legacy API's be wrapped as services? If the resulting service meets whatever standard applies, does it matter? Wouldn't doing so allow the legacy application to be extended into the SOA arena?

  • I fully agree to the value and the learnings of this blog. It was very interesting for me to read what a had somehow in mind. From my experience I would like to add one comment concerning process centric view and SOA. I think beside or within the required business process knowledge of an architect it is important to find the right process level that needs to be enabled by service. Here is an example from my business area which is PLM and includes CAD integration. Scope 'a' could be the definition of services that manage and orchestrate native CAD files to introduce them on enterprise level.
    Scope 'b' could be the services that introduce CAD engineering components on the enterprise level to be released and handed over to production / execution.
    Although the management of CAD files needs to be solved somehow we decided to go for scope 'b' to focus on the benefits from a business process perspective. As soon as we are able to integrate CAD based Engineering components on an enterprise level based on services the value is obvious: - integrate production needs, calculation and costing, purchasing and life cycle key questions. We focus on downstream integration without any assumption of what the CAD system is about. As soon as we focus on files managing services of CAD systems (scope 'a') we stick to todays CAD model and have limited value on an enterprise level.

    Looking forward to read more blogs of this type.
    Kind Regards,

  • Hi,
    I think your article is good and for sure I can agree to most examples mentioned, I would like to provide some of my insights regarding this topic as it is reflected in SAP banking industry:

    In the banking industry SOA was always a big thing as banks are highly IT oriented organizations with very complex productive system landscapes developed around 30-40 years ago!  Today these reflections on whether SOA failed or not is valid in this industry as well and I couldn’t agree more to your statement that it is not the SOA paradigm that failed but the way we execute it.
    There are many mistakes we can talk about which could explain why most of the SOA attempts were not that successful (SAP and non SAP) or at least why it did not solve the IT world problems, I think the main reason for that is high expectations and simplification of the problems and the way they should be solved – SOA. It was amazing to see how fast people jumped at this new “star” horse called SOA and promised that it would fix all the IT world problems without the basic understanding of what it means to really build a working IT solution for large organizations. I believe that now in this “sobering up” period only the true SOA believers and competent personnel who really understand what it means to really build a working solution (you referred to it as the hands-on experience) would keep on pushing for SOA in their respective area.

    As for SAP my personal point of view is that we need to shift our discussion from SOA to a platform based approach and I’m not referring to technical platform like NW but to all the business platform which based on engines like “product configurator”, “calculation engines”, “Org Management tool”, “Authorization engines” and much more all open for usage internally and externally using native and standard API’s. This way we leverage our advanced added value over competitors who have just technical tools set for you to build the business infrastructure you get out of the box with SAP.
    We also need to provide expertise in SOA @ Industry rather then Generic SOA expertise as you well pointed the need for business process knows how. In the Banking Industry we took that approach and we formed the SOA Engineering Group which provides services and knowledge around SOA @ Banking that supplements our business application experts (functional consultants) and process experts (business consulting).

    Unlike other vendors out there (and I won’t mention names…) for SAP SOA is just another aspect of its overall comprehensive, working and ready to use business platform we should not make it “the topic” but just another way for customers to utilize what we have.

    • Thanks Nitzan for your feedback. Banking is always a good benchmark for our approach in public sector and healthcare as they share a lot of characteristics.

      You are absolutely right about the approach. The customers are not interested in SOA or other acronyms. The are interested in a plattform in the sense you defined.

      I would really appreciate if you could share some of your insights in banking projects in more detail.

      Thanks and best regards,

  • Great to read the positive experiences in the SOA area. On the subject that there's to much negative feelings towards SOA, I would say: hang in there. It was new to most of us and we had to learn how to work with it.
    In stead of focussing on services (and defining service-oriented projects), the focus should be on the Architectural approach that supports it. That is where its strength is coming from and where the long term benefits will emerge.
    Furthermore, we should stay aware of the surroundings we are working in. BPM is promissing as a fertile breeding ground for SOA. It provides not only the business link that is required to embed the architecture into the organization, but also defines (within the boundaries of the enterprise architecture) the level playing field for transforming the business requirements to IT solutions. This last step, where the business process models have to be executed, see more and more toolings becoming available (from different vendors) supporting BPM and BRM.
    It is also in this phase where the interaction from the process with automated tasks (integration scenario's) and user interaction can be defined. Within your project the UI and Integration design can be realized from this point on.
    Proper business alignment is achieved by defining the process steps and requirements through the business-defined process models, including definition of the task at hand and the data required for execution.
    It almost Begins to sound like services..... So yes, there is a thriving future waiting for SOA. Not as a standalone idea, but in the context of a proper enterprise architecture and in good relationship with BPM initiatives.
    • Thanks for your feedback. Patience is the name of the game. Especially in the public sector huge SOA projects are emerging and will show their benefits in some time.

      Best regards,

  • I agree completely with Bernhard's statements. This "mistakes" list is a great guideline for those people preparing a SOA engagement. It states clearly who should be adressed during the positioning and in which ways and what skills (high level) will be required during the preparation and design. Many thanks as well for all the replies as they definitly make this a top blog. 
  • I think this is a really good blog and I only can confirm what you say.

    But I am missing two more aspects which one of them my colleague Dieter Scheerer and myself just addressed in an own blog. Very often we see SOA and also adress SOA very strategic and just not practicable. We offer customer consulting services about strategic SOA roadmaps, governance and organizational structure instead of first trying to get a "buy in" with a small and easy to adopt scenario or "test baloon" where they easily see the benefits and also experience the benefits from such an approach. Like I say in my blog: who starts building a refinery and invests millions of Euros if he does not yet know if oil reserves are nearby?

    The second aspect is that many consultants and partners still have no general understanding where SOA in implementation projects might be helpful. Due to that we lose many many opportunities where still other technologies or development approaches or solutions are favoured. Many consultants are not sure and feel not comfortable with this topic (thinking that it is very complex and technical) and thus prefer the things they know. Just as germans would say: What a farmer does not know and grow, he also does not eat.


    • Hello Dieter,
      thanks for your feedback.

      I completly agree with you that SOA needs a grounding, a demonstration of real benefits not only visions. But from my point of view a potential risk involved is to concentrate on the small scenario and forgetting the bigger picture.

      A very good starting point in this respect is HR. Here you can combine the both aspects you mentioned. I will blog about that soon.

      By the way could you please send me the link to your blog as I would be very interested to read it but I was not able to find it. Thanks.

      Best regards,