During the past few years, one term has been touted a million times or more by analysts, by publications and, of course, by technology vendors. No prizes for guessing that the term is SOA or Service Oriented Architecture. Business soothsayers have only stopped short of prescribing SOA as the one magic potion that will solve all integration woes, and enable organizations to quickly change their underlying applications to match the agility of their business processes.
Barely a few months from its much-publicized ‘birth’, it seemed that every enterprise software vendor had an SOA strategy. While CIO’s were initially skeptical about SOA, they soon jumped on the bandwagon: some of these CIO’s knew exactly how SOA would help their organization, and the kind of investments, time and effort required to make SOA successful – but the majority had no clue. They simply went ahead because they did not want to be left behind.
Where’s my ROI?
As with any technology, after the initial hype has settled down, reality walks in with leaden feet. Five years of education, adoption and doubtful implementation have gone by now, and there are very few poster boys for SOA. While most organizations agree with the theoretical benefits of SOA, the situation ‘on the ground’ has been quite different. To their dismay, many of the eager initial adopters have realized that the promise of business agility through high reuse, interoperability by design, and loosely-coupled integration, and of course, cost savings – are elusive goals.
The Data Is In…
A 2007 InformationWeek web survey of IT professionals found that 32% of organizations using SOA said that the projects fell short of expectations. Of this, 58% said their SOA projects introduced more complexity into their IT environments, and 30% said they cost more than expected.
A study by Nucleus Research last year, found out that only 37% of companies have achieved a positive return on their SOA investments. The study also highlighted that while SOA drove developer productivity, it often ended up being the responsibility of the project or department. The result – SOA was deployed in silos, thereby impacting the return on investment. This is ironic when you consider that the concept of SOA came about to fuse integration between applications effortlessly, and reduce islands or silos of information.
Common factors for SOA failures
- Business drives technology, not the other way around
One common mistake many organizations make is that they approach SOA from a technology perspective. They go on to choose the best vendor in terms of features, and spend a lot of time in designing the best architecture – without involving the people who will benefit from this architecture. The result – no business buy-in, near-total disinterest and even, in some cases, opposition.
CIO’s must remember that business drives technology – and not the other way around. Till this realization dawns, disillusionment will be inevitable. Hence, strategy must drive business, business must drive applications, and applications must drive technology. IT must work closely with business, and support it with technology for implementing the strategy. Hence, organizations must start changing their business processes first, and look at how SOA can solve real business problems. The technology problems will then be relatively simpler to handle.
- Improper assessment of IT landscape
Unless organizations identify and take a detailed inventory of applications, processes and their supporting personnel, and classify which services can be service-enabled – no SOA implementation exercise is going to be beneficial. The inventory of applications combined with the business processes supported is key to identifying the Business Services – the primary basis for delivering the benefits promised by SOA. Reusing (business) services helps in saving development time, and improves business responsiveness and agility. Hence, unless organizations have a proper assessment & understanding of their IT applications and how they support business/operations, SOA implementations are bound to end up on the ‘junk’ pile.
- Lack of governance framework
SOA encourages the concept of loosely coupled and reusable services. This means that services from one process can be abstracted and reused by another business process or application. However, left ungoverned, SOA can allow any service to be invoked or deployed by any application – which in turn can lead to an unholy mess. Think of a traffic situation on a busy highway – with cars being allowed to go unhindered in different directions, with little automated (traffic signals) or manual (a traffic policeman) controls.
The lack of a governance framework can be the critical success factor of an organization’s SOA strategy. Paolo Malinverno from the Gartner Group believes that “Through 2010, the lack of working governance arrangements will be the most common reason for the failure of SOA projects.”
To successfully implement SOA, organizations must create/adopt a robust governance framework which establishes tools and practices for enforcing a common set of security, performance and other policies for every service. In short, the governance framework should govern the lifecycle of services from creation to deployment.
- Vendor lock-in
Despite the promise of plug-and-play services and a world of interoperability, we have seen every product vendor use a different roadmap with different technological approaches for implementing SOA. It is ironical that the purpose of SOA is independence from vendor lock-in, so that you can choose to add, remove or plug in components or services from different vendors, as you want. If your organization is trapped with a single vendor, it is obvious that your SOA strategy is not working, as the cost of upgrade or integration with a third party application will be as expensive and time-consuming as it was earlier. The bottom line is simple – don’t let the vendor drive your architecture.
Making your SOA implementation a success
A successful SOA implementation can significantly improve operational effectiveness and deliver considerable ROI. However, implementing SOA requires commitment and buy-in from top leadership. High-level management must articulate the common vision that promotes and explains the business case for using SOA, and effectively tackle any cultural or change management issues that are caused due to the implementation.
The architecture must be planned with a vision for the future, with detailed linkages between IT and business, and how the solutions will change if the strategy changes. Organizations must also have a leadership team to oversee implementation. This team would govern the implementation and provide direction through decision making, training, and resolving issues related to culture or skills.
SOA is not a magic potion or a silver bullet that will wipe away all integration woes. As with any technology, SOA first needs business process re-engineering, and then the technology that supports it. The bottom line - if you do not have a clear business case and a roadmap, then don’t expect too much from your SOA implementation!
About the AuthorSwati Parashar
(ArticlesBase SC #1171963)
Article Source: SOA Service Oriented Architecture. http://www.articlesbase.com/ - SOA: Where did we lose the way?
No comments:
Post a Comment