SOA funding dollar competitors such as business unit application projects are effective because their value to the enterprise is easily understood and explained. They are also effective because the scope of their projects can be measured in thousands of dollars and months. This is in stark contrast to commercial SOA transitions that cost millions, take years to deliver, and whose business value is not easily understood or explained to stakeholders

Leveraging New Web App Funding Dollars to Produce SOA Solutions
The primary tactic an Open Source SOA Roadmap uses to neutralize the characteristics of commercial SOA transition is to reduce the scope of SOA Transitions down to small increments. That is, increments so small that the amount of labor and the time required to deliver the software solutions are within the bounds of an ordinary new Web application project. This means a small team of open source SOA-aware developers can deliver SOA solutions in months not years and at a cost of thousands of dollars. It's this reduction in the scope of a SOA transition by an Open Source SOA Roadmap that eliminates many of the barriers to obtaining funding. Smaller projects cost less and so have fewer competitors for funding. Smaller projects are expected to deliver fewer capabilities, and therefore, can produce tangible results sooner.

The primary tactic an Open Source SOA Roadmap uses to compete with business unit application projects is that it can delivery more business value. In the Open Source SOA Roadmap's first increment it can produce a Web application just like the business unit application project. However, in the Open Source SOA Roadmap's second increment, it can produce an enterprise layer of reusable business services. It is these reusable services that hold the key to greater business value because they are easily recognized as valuable to other business units in the enterprise - beyond the business unit that funds the first increment.

Another strategic advantage an Open Source SOA Roadmap has is that it is a mechanism for transition to license-free open source middleware. Consequently, the Open Source SOA Roadmap has the business impact of reducing ongoing operational costs. This means IT resources can be shifted from maintenance to competitive advantage initiatives.

Business Value Propositions Made Easy
SOA transitions present comprehension and communication problems that make it difficult for backers of SOA transitions to present convincing business value propositions. Understanding the value of SOA transitions in concrete terms is one of the major roadblocks to funding SOA transitions. That is, your project could produce the most valuable software in the world, but if stakeholders can't understand why the software will be advantageous to the enterprise, they're not going to fund it.

Besides understanding the issues, the ability of a SOA backer to explain the value of a SOA transition is another major roadblock. The IT budgeting process is messy and best described as a "dogfight" exasperated by the economic downturn. Funds will be allocated to projects whose backers can best explain why the software will be valuable to the enterprise. If the SOA transition's backer can't explain effectively and quickly the value of the SOA transition - it won't get funded.

Fortunately, Open Source SOA Roadmaps have a mechanism that effectively addresses the communication and comprehension problems SOA transitions present. It's called an "open source SOA roadmap diagram." There's an example in Figure 1. The open source SOA roadmap diagram visualizes the concrete steps that must be taken to transition to a SOA enterprise architecture. The example shows a Human Resources SOA Cornerstone Initiative Roadmap that shall govern the development of the HIRE Web application and technical market business services.

There are two key aspects of an Open Source SOA Roadmap diagram we'll focus on. The first is the "implementation schedule" in the middle of the diagram and the second is "business value" at the bottom of the diagram. The implementation schedule shows when stakeholder investments in the HR SOA cornerstone initiative will be realized. The implementation schedule shows that an end-to-end executable version of the HIRE Web application will be completed three months after the initiative starts.

The business value aspect shows why delivery of the HIRE app is valuable to the enterprise. That is, in the first milestone of the initiative, HIRE will cut recruiting costs, time and ongoing operational costs. In milestone 2 the concrete benefits of SOA are shown. That is, in eight months, the delivery of the enterprise accessible technical market services will enable both the R&D and IT departments to recognize and exploit technical market trends.

The Open Source SOA Roadmap diagram is a mechanism that makes it easy for stakeholders to understand - in concrete terms - the value of SOA to the enterprise. It also makes it easy for the SOA backer to explain the value of a SOA initiative to others.

Milestones: Open Source SOA Roadmap Increments
There are many Open Source SOA Roadmap patterns that can transition your organization's IT enterprise architecture from a spaghetti enterprise architecture to an integrated SOA enterprise architecture. Our Figure 1 example is an instance of the "Simple Web App" Open Source SOA Roadmap pattern. The Simple Web App pattern transitions spaghetti enterprise architecture in increments of software solutions realized by open source technologies. Each increment is called a milestone.

Each milestone of the simple Web app pattern is a snapshot of the enterprise architecture as it's transitioning. In other words, the milestone is an incremental transition of the enterprise architecture, where the business value for that increment can be easily understood and explained. Also, the size of that increment is small enough to be measured in thousands of dollars and months.

Milestone 1 of the simple Web app pattern is a snapshot of the enterprise architecture where a SOBA (service-oriented business application) Java Web application has been introduced to the enterprise architecture. Open source technologies such as Spring, Hibernate, and JUnit have been used to build this application that will run in an open source servlet container such as Tomcat or Jetty. The SOBA Java Web application (shown in Figure 2) encapsulates business services with value to the whole enterprise. The business services are POJO (Plain Old Java Objects) service components that have no dependencies on any middleware. In other words these POJO business services can run anywhere Java can. In our HR example, the SOBA Web application would be the HIRE Web application and the business services would be technical market services.

Milestone 2 of the simple Web app pattern is a snapshot of the enterprise architecture where a business services layer has been realized by enterprise integration and has been introduced into the enterprise architecture. The enterprise integration (shown in Figure 3) reuses the POJO (Plain Old Java Objects) service components created in Milestone 1. The business services are exposed to the enterprise by an open source Enterprise Service Bus such as ServiceMix or Mule. The business service proxies and remoting services components are reusable POJO resources that enable other applications to access the business services remotely. An open source application framework such as Spring would enable the other applications to include the business service proxies and remoting services via declaration (XML file configurations). Configuring software solutions to include components is much faster and more testable than inclusion by hard coding.

In our Human Resource SOA Cornerstone example, the H R sector would be the enterprise integration and the technical market services would be POJO service components.

Summary
The bottom line is that an Open Source SOA Roadmap is a governance tool that orchestrates SOA and open source technologies/techniques into a concrete transition action plan that's more likely to be funded. That is, the combination of understandable business value, plus software delivered quickly without risking large amounts of money, makes SOA Transition funding easier.

The next article in this series is entitled "Leveraging Open Source to Make a Strong Business Case for SOA Transitions." It will focus  on financial and other measurable aspects of Open Source SOA Roadmaps.

Copyright 2009© all rights reserved

Resources

• Lawson, Loraine. "The Scary Costs of SOA May Hinder Adoption".
• Gruman, Galen. "SOA Spending Up Despite Unclear Benefits".
• McGreevy, Maura. "AMR Research Finds Average Spending on SOA Software and Services Reached $1.4 Million in 2007".
• Lawson, Loraine. "What To Do If Cost Cuts Impact Your SOA".
• Rix, Marc. "Bottom Line SOA - The Economics of Agility".
• Mckendrick, Joe. "SOA Adoption - Who Pays? Who Reuses?".
• Swoyer, Stephen. "Coming to Terms with SOA's Demands".
• Germain, Jack M. "The Shift to SOA: Repurposing Priceless Business Logic".
• Seeley, Rich. "How SOA May Thrive in a Recession".
• Williams, Bob. "Introduction to GRASE".

• The Investment Virtues of "SOA in the Cloud"
• Transition a C-Level SOA Skeptic into a SOA Backer