There has been a lot of chatter lately about SOA failures, the “Death of SOA”, and Big SOA vs Little SOA. Many IT departments have been struggling to deliver the ROI that they promised their executive team when they raised the capital to start their SOA initiatives. There are two major reasons for these lack of desired results. First and foremost, is a lack of focus on architecture. Second is a lack of a well defined roadmap. Many, including myself, have written articles about the lack of focus on architecture. In this article I will provide a strategy for putting together a roadmap.
A roadmap is a vision of what the future state should look like some point down the road. It takes a collection of projects and/or deliverables over some defined period of time, usually a few years, to achieve the true promise of SOA. Without a well thought out roadmap, companies risk losing focus over time of the desired future state. Think about the current efforts to break our dependency on foreign oil. Everybody understands what that future state vision is, but without a roadmap to get there over the next 10-20 years, we will likely just spin our wheels and throw more good money after bad. SOA is no different, it will take a number of years until a true service-oriented enterprise is established so somebody needs to put together the steps to lead the organization to the end goal.
I have seen many good examples of roadmaps which help prioritize the order in which services are constructed so that the candidate services with the highest potential for reuse are moved earlier in the roadmap. That is a smart thing to do. However, the roadmap needs to take into account more than just technical aspects of the SOA journey. The most important artifact is the roadmap for the business. What new products and services will the business get and when? What will be retired, if anything? When will they start seeing the business drivers (increased sales, operational efficiencies, reduced costs, etc.). After all, if you are not doing SOA for the sake of business drivers, you shouldn’t be doing SOA at all.
SOA initiatives are transformational. They require new skills, communication across business and IT silos, new processes, and usually a different approach to building software. The organization must change and mature throughout the SOA journey. There is too much change to expect it all to occur up front. Organizational change management must be another piece of the SOA roadmap. Included in that roadmap is planning training and skills development, changing the makeup of the talent pool over time (both business and IT), broadening the adoption of SOA, etc. This is another area where many companies start to fail. The underestimate the impact that change has on human behavior. Organizational change management must be planned and budgeted for up front or you will be battling resistance and chaos more than you will be delivering business value.
There needs to be a governance roadmap too! By now we should all be aware that SOA without a good governance model spells disastrous consequences. But governance is a big initiative to undertake. Like SOA, one can not expect to deliver governance as a single project. Governance is a journey through time. Early in SOA projects, the amount of governance required to build, manage, and maintain a handful of services is minimal compared to the amount of governance required by year three where a company might have hundreds of services being shared across multiple business units.
And finally, there should be a roadmap for the implementation of software and infrastructure that is needed to deliver the business, transformation, and governance deliverables. What do I mean by that? Well if the vision of the future state includes isolated layers for business rules, business processes, data services, security, mashups, etc., nobody in their right mind would buy all the hardware and software required on day one. The roadmap must highlight when to expect these layers to be worked on and when major milestones will be achieved. This allows the team to budget properly for training, skills acquisition, hardware and software procurement, transformation efforts, and so forth. A good analogy is the scenario of building a house. The builder would not buy all of the materials, bring in all of the specialists, and rent all of the equipment on day one. Instead, these activities are planned in a logical sequence the maximizes the use of everyone’s time and controls costs over the life of the project.
Once all of these different views of the roadmap are decided upon, the next step is to communicate the roadmap. The roadmap needs to be understood by people at all levels, from the most senior management to the most junior employee. The best way to communicate to a large variety of people with diverse skills is through visual representation. The roadmap should visually depict the key milestones from the business, people, governance, and technology perspectives to show the organization the expected journey from current state to future state. I have found that visual roadmaps are the best way to communicate because people can understand a future state vision much easier than reading or being walked through text heavy documents. Through the SOA journey, the roadmap will likely be the most widely recognized and most used tool. It represents what the company invested in and expects to be delivered. Use it as a tool to keep focused and divert distractions. Along the way celebrate the successes as milestones are reached. This keeps things exciting since the future state is usually a long way off. While you are at it, why not throw in a few planned celebrations on your roadmap? Use an icon that represents a celebration near the key milestones. This will keep the employees motivated as they move closer and closer to the future state.
In conclusion, creating visual roadmaps is a key strategy for communicating to people at all levels what the goals of the SOA initiative are, what needs to be done and when, and what the organization will look like when we get there. Roadmaps also help us forecast the budget for the SOA initiative and help keep the organization focused. Roadmaps should include many perspectives. After all, SOA is about enabling the business, it is not about IT.
