About: This post discusses the challenges of selling services oriented architecture to business stakeholders
So you are convinced that Services Oriented Architecture is the right approach for your IT organization, you are all set to transform your IT systems to SOA but before you move forward you need to sell ‘SOA’ to the business stakeholders. Offering advice about how to deal with business users is difficult as every organization has a unique set of dynamics, culture, relationships and history, however, there are certain concepts that are applicable to most organizations. Here are some of the ideas to consider in your quest to sell the virtues of SOA to business stakeholders.
Translating the benefits of SOA
Resist the urge to sell ‘SOA’ as a concept to the business stakeholders; you need to translate the benefits of services in to consequences that are important for the business. Please note that some of the benefits listed below may also be realized without implementing SOA as aspects of SOA are an evolution of good OO principles, however, SOA facilitates in realizing these benefits. Some of the many benefits of SOA include
1) Business agility
Services oriented architecture results in systems that are loosely coupled allowing IT to respond faster to the directives of business stakeholders. SOA allows for a more natural depiction of the business processes, real life events and system boundaries in software, improving the ability to respond to changes in the business. In addition, closer modeling of reality allows for relevant and actionable business data and loose coupling between services reduces the ripple effect of changes.
2) Better service and quality
SOA can improve the business stakeholders’ ability to provide better services to their users in a number of ways. A major advantage of SOA is significantly reduced cost and complexity for integration of disparate system, this reduction in costs and complexity can mean better, faster and cheaper alignment with more partners. In addition, reducing the number of point to point solutions and silos improves the overall quality of the systems.
3) Best of breed solutions
SOA improves the ability of the business and IT management to choose the right solution to serve business needs as it is easier to integrate these solutions with the existing infrastructure. For example, using a services oriented architecture based approach, it is much more possible and easier for J2EE and .NET systems to co-exist and interact with each other.
4) Reuse and Standardization
I have mixed feelings about including reuse and standardization as a business benefit. SOA allows for systems based on open industry standards and creation of reusable IT assets. However, at the end of the day that argument works better for IT management than the business community as they are much more concerned about providing the right services to their user base than the systems’ potential for reuse. If you are going to use the ‘reuse’ argument, talk about it in terms of how it fits in one of the three buckets business users really care about, these buckets are “Faster, Better and Cheaper”, reuse and all your other arguments about SOA need to fit in to one or more of these three buckets.
5) Evolution vs. Revolution
Business users are suffering from IT revolution fatigue; SOA is not a revolutionary idea, however, the advances in technology and cooperation amongst IT vendors have made it much easier to implement now. In many ways it is a natural evolution of the object oriented architecture and design.
Big Bang vs. Crawl-Walk-Run
Some organizations have taken a big bang approach where a massive multi million dollar effort is announced and undertaken to implement SOA whereas others have designated SOA for new development, specific projects and adopt SOA in a more gradual manner. In my experience organizations that have implemented a combination of the two have been most successful. Due to the variables involved, it is a good idea to have a long term strategy that has measurable success criteria in the short and medium term, avoids detailed long range planning and where the first SOA enabled solution that the IT organization implements is NOT a large and complex system. Remember, the reality is always different from the hype and irrespective of how many seminars you attend and articles (and blog posts) you read, experience remains the most effective teacher.
Proof of concept
One of the best things you can do to sell SOA to business stakeholders is to implement a proof of concept even before you go in front of the big bosses. It is important to choose the right POC that can help you make a case for a larger investment from business users. Do not choose a POC that is extremely hard to explain, has no front-end impact and takes six months to realize. Something that is tangible, measurable in terms of ROI and can be done in about six to eight weeks can be a good learning experience for the IT organization and be a great marketing tool.
Business stakeholders care a lot about what their partners and competitors are doing, make sure you have your data and statistics. For example, a leading IT research & analysis company is going to release the results of a survey shortly that shows a dramatic increase in SOA implementations at large enterprises in the past year. Having data and studies that show that your organization is not the first and the only one to implement SOA would be extremely useful.
Vision and Roadmap
Nothing worries business stakeholders more than an IT presentation that does not seem to be well-thought and does not consider future. It is a good idea to present a vision for SOA and a roadmap that shows how you plan to get to the vision by completing quantifiable milestones.
I wish you the best of luck in your presentation, remember some of the usual presentation techniques apply to this meeting as well, knowing your audience is critical, knowing what matters to them (rather than you) and enrolling key people in advance usually makes the difference. It is hard to oppose something that someone has had a chance to review and provide input before you presented to the larger group.
In the next two weeks I will be writing about some of the negative consequences of implementing SOA and some of the organizational changes that are required to realize the benefits of SOA