Introduction
Before we start thinking about the reasons of failed SOA efforts, let’s define what the SOA is.
The SOA (service-oriented architecture) is basically a collection of services that communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. At the same time, some means of connecting the services to each other is needed. In most cases, the connection technology of SOA is the one of Web Services technology. SOA can be also defined as a loosely-coupled architecture designed to meet the business needs of the organization.
One of the keys to SOA architecture is that interactions occur with loosely coupled services that operate independently. SOA architecture allows for service reuse, making it unnecessary to start from scratch when upgrades and other modifications are needed. This is a benefit to businesses that seek ways to save time and money.
So, what is it that most SOA failures are due to people issues more often than due to technology issues?
People tend to fail in explaining SOA’s business value
SOA needs to solve real business problems, but very often IT people approach SOA purely from a technology perspective. They spent a great deal of time and effort on architecture, governance and vendor assessments, but keep forgetting what problems SOA is to solve. Lots of time and money is being spent to build the architecture only to find that when it is done, nobody in the business understands the benefits and is not interested in the technology.
This is exactly what we, at EvergoPartners, encountered multiple times working with our corporate clients – too much effort is being put focusing on specific technology, instead of understanding what the value for the business it would generate. So, what’s recommended is to start by showing the business how SOA would solve a particular business problem, and then go on to addressing technology issues.
The impact of organizational change is being underestimated
As with any transformational initiative, resistance to change is a project killer. SOA brings massive amounts of change to an organization. Fear of the unknown is the greatest contributor of resistance to change. People need to understand and why changing their ways is good for both them and the company. The challenge is that people at different levels within the organization are affected in different ways. Each level of the business has concerns which need to be addressed which must be solved at an individual basis.
One of the solutions to such a challenge could be hiring an external organization change management expert to help the leadership team of the SOA initiative to deal with change.
People attempt to do “budget” SOA, without having required skills to deliver it
It would be very difficult to implement SOA with limited budgets. In addition to all of the middleware that is required, there are huge investments in governance tools, training, consulting, infrastructure and security.
Managing SOA in a production environment is challenging because of its distributed and loosely coupled nature. Some companies will try to take on SOA projects without any outside help to shave off the high cost of consultants. There are many specialized roles and skill sets required which probably do not exist within the organization. You need SOA architects, business process modelers, administrators of the tools, data architects, and many other skills. These positions are not cheap. Unless you are loaded with people experienced in SOA, trying this without outside help in order to save money can be a recipe for disaster.
To get the needed money, create the financial justification for the entire SOA initiative and show the most important financial indicators for the company. Show a vision of the long term benefits that SOA will bring to the company. If you build a good enough business case, there should be enough money to fund the initiative. Also, to reduce the overall costs of your SOA implementation, several great open source products are available.
Lack of a sound SOA governance
SOA promises unlimited agility and organizational flexibility. However, achieving these benefits is entirely contingent upon the ability to effectively manage the SOA environment across the enterprise.
SOA governance provides the ability to measure returns and articulate the ongoing value of SOA at every level within the organization to encourage adoption and buy-in. It allows you to see what services are being consumed, enforce policies and SLAs, troubleshoot, analyze performance and manage all assets. In addition, as SOA adoption increases, without Governance, SOA assets can become unmanageable, and reuse of services will diminish in favor of custom development. Even worse, modifications will be made to your existing services that break other business processes.
To mitigate the above, you should treat the SOA governance as an initiative that runs alongside of your SOA implementation. There should be a dedicated team within Enterprise Architecture with its own road map and long term vision. It will take time to reach a high level of maturity. As your governance matures, so does your SOA.
Vendor’s lock-in
SOA is about what your organization needs – not what a vendor tells you that you need. Relying too much on vendors can be a disaster. The vendors’ goal is to sell you as much stuff as possible. Your goal is to implement SOA successfully and to provide your company with maximum benefits at minimal cost. Don’t forget that your needs aren’t just a list of systems that need to work together – your solution needs to make things easier for your developers and users, too.
It’s been our (EvergoPartners) experience that some of our corporate clients still use their fully operational legacy systems successfully. Replacing them with just one “right” solution and committing to just one vendor could be a huge mistake, possibly generating unnecessary short term and long term costs.
