Selling SOA to business stakeholders


About: This post discusses the challenges of selling services oriented architecture to business stakeholders


 


Hello,


 


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.


 


Industry Trend


 


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


 


Best regards,


Mohammad


 


 


 


 

Comments (7)

  1. Nadeem says:

    Building a POC to sell the idea of adopting SOA in the organization, is a good idea. I would really be interested in knowing what are some of the features/services that this POC should comprise of and how this POC should be architected using may be .Net 2.0 and SQL Server 2005. Thanks.

  2. Atif says:

    You mentioned quite cleanly about Advantages of SOA. It would be nice to have a post with some downside of SOA, like performance for while exchange larg amount of data, effort required for designing schema etc.

    regards

    atif

  3. makif says:

    Excellent point Atif, I am in process of writing a post on the dark side of SOA, I do think that a lot has been written about the advantages of SOA which overlooks some of the issues and disadvantages associated with this model.

  4. makif says:

    Thank you Nadeem for your comments, in my opinion a successfull POC is typically short i.e. 6-12 weeks long, has high visibility and tangible and quantifiable benefits. Ideally, it should be a microcosm of a larger portion of business and you need to be in a position to collect data pre and post POC to determine the impact. In terms of .NET 2.0, there are a large number of features in Visual Studio 2005 that will allow you to design, implement and test SOA e.g. the distributed system designers that are part of the team architect version of VS, however, do keep in mind that SOA is a technology-agnostic paradigm and although using the right tools will definitely have a positive impact on its success, selecting the right boundaries for the POC is an architectural exercise.

  5. Good grief! Not another pesky TLA? Well, not really. SOC stands for service-oriented culture—an awkward

  6. Dating says:

    About: This post discusses the challenges of selling services oriented architecture to business stakeholders Hello, So you are convinced that Services Oriented Architecture is the right approach for your IT organization, you are all set to transform you

  7. Weddings says:

    About: This post discusses the challenges of selling services oriented architecture to business stakeholders Hello, So you are convinced that Services Oriented Architecture is the right approach for your IT organization, you are all set to transform you

Skip to main content