SOA C-level skeptics come in all shapes and sizes. They can be in any industry or any government agency. They can be close friends who "really like you" and no matter what, will invite you to their backyard barbeques. However, despite their differences or that fact that they may be you friends - C-level executives must have confidence the enterprise architect can deliver on what he proposes.

All C-level SOA skeptics are thinking: "That sounds nice - but what makes me think you can pull this off?"

There is a lot about converting stakeholders - who won't return your phone calls - into investors who trust you with their money - that software architects can learn from building architects. Building architects realize that stakeholder conversion is a process that first starts by gaining a stakeholder's attention and ends with the actions that exceed the stakeholder's expectations. That is, building architects follow a conversion pattern of actions for gaining a real-estate investor's attention, then his interest, then shepherding the decision to invest in the building architect's proposal. The final part of the conversion pattern is the set of actions the building architect must take to exceed stakeholders' expectations and gain their trust.

An example of that conversion pattern is as follows. The building architect first gains the attention of the real-estate investor by expressing the value of a building proposition in terms of numbers the investor understands. For example, a building architect proposes that he can build a 3,000 sq foot center hall colonial style residential home that can be sold by the investor for $500,000.00 in six months.  Clearly, the thought of a $200,000.00 dollar profit in the next six months is enough to get just about anybody's attention.

Once the building architect has gained the real estate investor's attention, he creates interest in his building proposal by showing the investor a drawing of the building and a building schedule. The purpose of the drawings and schedule is to demonstrate to the investor that enough thought has gone into this proposal to merit a second look by the investor and his technical advisors.

Now that the real estate investor is interested, he will seek the advice of gatekeepers (experts in the field of building that the investor trusts) before he decides to invest. The building architect gains the approval of the gatekeepers by showing them blueprints for and a model of the proposed building. The model and the blueprints enable the gatekeepers to see, in concrete terms, what the stakeholder is investing in. The building architect also uses the building model to plant in the investor's mind an image of what the proposed building will look like. Planting that image in the investor's mind establishes a picture of why the building architect can "pull this off." It also eliminates countless misunderstandings that can kill investor relationships.

Once the project has been approved for funding and construction begins, the building architect takes actions that ultimately will convert the real estate investor's attitude from skeptical to "sold out." That is, the building architect realizes that once money has been allocated, all investors are skeptical until the investment has been realized. The building architect understands that deliberate actions must be made to address the investor's concerns during construction - if the investor is to be ultimately "sold" on the building project and the building architect.

Typically, the building architect creates a plan of action for onsite inspections by the investor and his gatekeepers. These onsite inspections occur at key construction milestones so that the investor and his gatekeepers can see tangible progress. By planning for these inspections, the building architect does three things that position him for success. First, the plan established expectations for what tangible results are and when they should be realized.

Second, the building architect can produce results that exceed the expectations established in the plan. Third, the plan can specify a milestone very early in the building process that addresses investor concerns sooner rather than later. This last point is very important because the sooner investors have "warm and fuzzies" about a building project, the more likely they are to continue funding the project.

In comparison, the typical SOA process for establishing credibility with C-level executives is to focus on the virtues of SOA technologies and plan for expensive SOA development with the promise of business value years from now. Clearly this is not the way to establish early "warm and fuzzies" in the hearts of IT investors. In today's economy the longer it takes to establish confidence, the more likely a project's budget is going to be cut.

This article explains how open source SOA Roadmaps encapsulate an AIDA (attention, interest, decision and action) pattern for transforming a C-level SOA skeptic into a SOA backer. First, it explains how to use software development performance measurements to gain a stakeholder's attention. Second, it shows how an open source SOA Roadmap diagram can be used to establish interest. Third, it demonstrates how a SOA reusable reference architecture can be used to gain gatekeeper approval for an investment decision. And last, it documents how open source technologies and techniques can be used to exceed stakeholder expectations.

Gaining an IT Investor's Attention
Start by identifying a business synergy an IT investor is likely to recognize as valuable to him. For example if you are in the hotel/vacation industry, IT investors are very likely to recognize the value of packaging hotel-provided vacation activities with local third-party vendor-provided activities to sell more vacation activities to hotel guests.

Having identified a recognizable business synergy - packaging hotel and third-party vendor vacation activities - the enterprise architect should create a numbers-based business case for a vacation activity packaging SOA proposal.

Given that a function point (a unit of software functionality delivered to a user) is a normalizing measure for the size of software efforts much like a square foot is to a building construction effort - an enterprise architect can formulate a compelling business case in a few words.

That is, for the first milestone of the SOA initiative, the enterprise architect can say "I can build you a 600 function point vacation activity packaging SOBA (service-orientated business application) web app for $300,000.00. It will take me six months to build. When completed, it will generate $500,000.00 in additional annual sales." Next the enterprise architect can say for the second milestone: "In the following four months I can build you a 250 function point enterprise integration for $125,000.00 that will generate an additional $450,000.00 in annual sales." Part 2 of this series (The Investment Virtues of SOA in the Cloud) contains more details about how to make a numbers-based business case.

In a few statements the enterprise architect has garnered the IT investor's ear with the possibility of generating an additional $950,000 of vacation activity sales from an $450,000.00 investment.

Establishing an Investor's Interest
Now that the IT investor is listening to the enterprise architect, the investor's interest in the SOA proposal has to be firmly established so that the investor will be willing to spend the time and people resources required to make an investment decision.

Continuing with our example, the enterprise architect shows the investor an open source SOA Roadmap diagram (see Figure 1) for the vacation activity packaging proposal. The implementation schedule in the middle of the "Integrated Vacation Activities Open Source SOA Roadmap" diagram documents when IT investments will be realized as working code. A deeper explanation of open source SOA Roadmap diagrams can be found in the first article of this series ("Securing SOA Transition Funding Made Easy").

The enterprise architect's objective for showing this diagram is to quickly communicate to the investor that enough thought has gone into this proposal to merit a second look. The combination of business case numbers and the thought the enterprise architect has given to this effort is likely to convince the IT investor to have his technical experts review the proposal.

Shepherding the Investment Decision Process
The IT investor's gatekeepers (IT experts the IT investor trusts) will want to see more technical proof that the SOA proposal will be a sound investment.

The open source SOA Roadmap policy to employ Reusable SOA Reference Architectures is designed to provide the proof gatekeepers are looking for.

Reusable SOA Reference Architectures are end-to-end executable software solutions that embody technical solutions to most - if not all - the types of technical issues a category of software solution present. An example is a reusable reference architecture for a SOBA (service-oriented business app).

That is, all the technical issues for security, data persistence, rich user interfacing and enterprise interoperability would be addressed by the reusable reference SOBA architecture.

Reusable reference architectures also include the design documents used to produce them. These design documents clearly specify the design decisions for design patterns and a technology mix that will be made to address the technical issues associated with realizing the stakeholder's investment. The reusable reference architecture then is the equivalent of the building model. Both enable the investor's gatekeepers to examine the proposal in a concrete way.

The combination of running end-to-end code and design documents that clearly explain why technology and design choices were made - create a situation where gatekeepers are comfortable with approving an investment.

Actions Designed to Exceed Expectations
After the SOA proposal has been funded, the enterprise architect will have to make deliberate actions to keep IT investors and gatekeepers happy with the project. If they don't feel "warm and fuzzies" about the progress of the SOA project, then there is a possibility that the project's budget will be cut - especially in this economy.

Fortunately, open source SOA Roadmaps include polices for actions that will keep IT investors and gatekeepers happy. Policies for measurable software performance, risk mitigation and open source technology mix help to position the enterprise architect for success.

First, the enterprise architect can establish expectations for software performance via measures for quality, cost and delivery rates that are based on function points. That is, values for the following rates can be established as expectations for the performance of the SOA project:

• Defect Rates (or Defects per Function Point) that measure the quality of a SOA asset. The meaning of Defect Rates is the lower the amount of defects a delivered Function Point (i.e., SOA asset) has, the higher the quality is.
• Cost Rates (or dollars per function point) are financial SOA efficiency measures. The meaning of cost rates is the lower the cost to produce a function point (i.e., SOA asset) the more efficiently the team is in managing the investor's money.
• Speed of Delivery Rate (or Function Points per Project Elapse Time in months) is a SOA agility measure. The meaning of speed of delivery is the more functions points per month (i.e., SOA assets) the team can deliver, the more agile the team is.

Second, the enterprise architect can exceed software performance expectations by employing agile open source software development practices and technologies. For example, by employing test-driven development techniques and open source automatic testing frameworks, the Speed of Delivery Rate for the SOA project can be greatly increased. As the "Automated Testing" diagram (see Figure 2) shows, the use of automated test frameworks like JUnit and Jmock foster parallel development because "mocking" a "serving" component means a "client" component can be built before the serving component is completed. As the diagram shows, parallel development is much faster than serial development.

Third, the reuse of reusable reference architecture means the enterprise architect will be able to produce end-to-end working code as proof of project process very early in the project life. Nothing gives IT investors and their gatekeeper "warm and fuzzies" like working code. As you know, the earlier IT investors and gatekeepers have "warm and fuzzies," the less likely they are to cut the budget. Therefore, because the reusable reference architecture addresses many technical risks and the risk of losing your budget - it is a key risk mitigation policy.

Summary
This article is Part 3 of a three-part series on the role Open Source SOA Roadmaps play in governing successful SOA outcome. Part 1 was about how to identify a SOA project most likely how to be funded. Part 2 was about how to articulate a strong numbers-based business case for a SOA project, and the final part is about how to sell SOA to skeptical management.

•   •   •

Copyright 2009© all rights reserved

• More SOA Transition Bang for Your IT Bucks
• The Investment Virtues of "SOA in the Cloud"