The common and most important problem of enterprise IT architecture is to integrate siloed applications, inflexible data structures and technology-specific platforms. SOA is technology independent. Thus there are several possibilities to implement a service that can be accessed by a service consumer via the service bus.
The structure of the legacy systems may also be a problem as they are often siloed applications and separated from other applications.
Unpredictable twists and turns in an ongoing project to suppliers, customers or the environment are not an exception but the norm. These risks are well-known, because they frequently occur in many ongoing projects, as well as in the execution phase. Nevertheless, they often do not get a close attention. Problems are then blandished as challenges, but they are occurred risks. Only if those risks are known, we can handle them.
Even though the principle of the separation of concerns is important for creating reusable software and realizing an SOA, it is often violated for many reasons. There are internal and external reasons. An internal reason is the amount of work. It takes time to create software that meets the requirement of separation. Some try to avoid the additional effort and sloppy solutions win over sustainable solutions. The disadvantages of this behavior will appear in the future and many people repress them in the present. An external factor is the behavior of IT vendors that want to lock the business logic of their customers to their proprietary technology. The separation of concerns may reduce their profit, so an organization should not blindly trust on their vendors’ technological recommendations. Their greed will prevail over technical advisable solutions. Companies should use open standards to remain independent.
Big IT projects usually fail because too many participants operate over a long period of time on a project and everyone works on his hidden agenda. Starke and Tilkov, SOA experts, suggest determining a strategic direction and a fast implementation of smaller projects. Feedback loops of the projects’ experience lead to an adjustment of the strategic direction. They emphasize particularly a solid governance.
Many SOA projects were not as successful as the SOA infrastructure vendors promised. The technical requirements are not the problem. These are solved perfectly. The main problem is a missing methodical approach to identify the business services that exist in a company.
The service oriented approach is not a pure IT issue. It means that the business processes need to be designed service-oriented. That is the main problem of many SOA efforts. The entire company has to get involved in this new way of thinking and abandon established habits. It is clear that this is not a piece of cake. When an SOA project fails, it is most probably not in the technology but in the communication and the lack of willingness to compromise. [1851-FOM_ILD_Arbeitspapier_Bd27_Online_12_12_18-01_01.pdf]