Adopting, designing, and governing SOA well

SOA Best Practices Digest

Subscribe to SOA Best Practices Digest: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get SOA Best Practices Digest: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

SOA Best Practices Authors: Jason Bloomberg, Hollis Tibbetts, Pat Romanski, Liz McMillan, Lori MacVittie

Related Topics: Cloud Computing, SOA Best Practices Digest, SOA & WOA Magazine, SOA in the Cloud Expo, Open Source Journal, Open Source and Cloud Computing, Microservices Journal, VITO Report

VITO Report : Article

The Investment Virtues of "SOA in the Cloud"

Open source SOA roadmaps produce strong SOA transition business cases - Part 2

In today's economy, an enterprise must have strong financial motives for transitioning to SOA. SOA's superior technical capabilities are a strong motive for information technology professionals to make that transition. However, enterprise stakeholders are motivated by solid investment opportunities. Software architects have learned how to express the technical virtues of SOA. What they need to learn next is how to express the investment virtues of SOA.

Software architects can learn a lot from how building architects formulate their business cases. Building architects have learned how to establish the value of their construction proposals in terms of numbers. They know how to accurately estimate the outcomes of their building projects and, to an acceptable degree, deliver what they propose. Their overall accuracy and reliability in delivering what they propose has helped the building architecture profession stand the test of time. I am not saying that they are without flaws - but they have a system and it works.

An example of that system is the following proposal. A building architect proposes to a real estate investor that he can build a 3,000 sq. ft. center hall colonial style residential home. This home can be sold by the investor for $500,000. The colonial will cost the investor $300,000 to build and it will pass all building codes. The colonial, with homeowner customizations, can be completed in six months.

If the investor is interested in making $200,000 (less expenses) and has the $300,000 to invest, then the building architect has established a business relationship with the investor. What is most significant is that the business relationship was established with a few statements. Statements with investment numbers is all the investor needed to clearly understand the business value of the building proposal. The investor's expectations for completion and quality have also been "managed" to what the architect can reliably deliver.

Contrast that with SOA proposals that frequently speak of business agility concepts, but rarely speak in terms of numbers upon which investments can be made. Motivating enterprises to transition to SOA without investment numbers is an uphill battle.

This article explains how open source SOA Roadmaps encapsulates policies that will enable software architects to make SOA business cases much like building architects do. First, it will explain which numbers (measurables) are essential to revealing the business value of SOA proposals. Second, it will explain how reliable estimates for future SOA efforts can be made. Satisfying these two objectives will enable the software architect to create a SOA business case that positions his open source SOA proposal as the best investment.

Measurables Highlight Value
It's been said if you can't measure it, you can't manage it. I say, if you can't measure it you can't sell it either. Without measurement, stakeholders have no idea of the "degree of value" SOA is to them. The less visible a SOA proposal's value is, the harder it is to sell.

If we examine the building architect's example proposal, we can see how he makes the value of the building proposal visible with measurables.

First the investment asset - the center hall colonial home - is identified and its size is specified by a square feet measure. Then the $200,000 business value is highlighted by a simple subtraction of the $300,000 cost measure from the $500,000 resell measure. Notice that the square foot size measurement is independent of the type of building proposed. It is also independent of the building materials or techniques. This independence is significant because it means that the square foot measure is common to all buildings. That is, the square foot is a normalizer that can be used to compare different buildings and different building proposal measurables.

Further examination of the example reveals how the square foot acts as a normalizer. The building architect uses the square foot to decide which elements to include in his proposal. Determining which building plans to include in the proposal is made easier by comparing the revenue potential and building cost associated with each building plan. The revenue per square foot and cost per square foot qualities of each building plan are compared to select the best building plan. Determining which building contractor to include in the proposal is also made easier by comparing the responsiveness (agility) of each building contractor. Responsiveness is the amount of time from the start of construction to a completed building. Responsiveness is calculated by a rate. The building architect uses this responsiveness rate to compare the agility of different building contractors. In this example, the building contractor with a responsive rate of 500 square feet per month was selected. Comparisons to competing architect's building proposals can also be made. With those comparisons, the building architect can use rates to select building plans and building contractors that outperform the competition. Therefore, the square foot and the rates normalized by it have enabled the building architect to create a proposal that positions him as the best investment.

A square foot is a metric - a system of measurement that consists of a set of rules, policies, and practices that ensure the reliability, integrity, and consistency of a measurement. Another way to look at a metric is that it is a formula used to calculate a measurement. It would be nice if such a metric existed for software to normalize SOA proposals. Turns out, such a metric does exist, and it's called a Function Point.

A function point is a unit of functionality delivered to the user. Function points can determine the size of software assets; that is, a proposed SOA asset such as a SOBA (Service-Oriented Business Application) could be described in terms of function points as a measure of its size. That number enables enterprise stakeholders to compare the size of a SOA proposal with the size of a non-SOA proposal. Further on in this article we shall see how - when used as a normalizer - function points will enable measurable business value comparisons.

SOA Measurement Policies
Let's say an enterprise architect wants to propose a SOA effort that integrates a hotel's Vacation Activities Packaging SOBA with the activity management applications of local vacation activity vendors. The business motive for this proposal is based on the proven benefits of packaged activities. Packaging activities is a proven way to sell more activities to hotel guests. The business motive is also based on the ineffectiveness of current manual packaging methods. Manual packaging methods miss many opportunities to sell more activities. The proposed SOA assets would enable the hotel and local vendors to eliminate a good portion of those missed opportunities. That said, there may exist a portion of missed opportunities large enough to justify the investment in the SOA effort.

An open source SOA Roadmap diagram is the perfect mechanism to visualize this "Integrated Vacation Packaging" open source SOA proposal. You may remember from my first article (SOA World Magazine, Vol. 9, issue 2) that open source SOA Roadmaps deliver deployable SOA assets in increments called Milestones. Figure 1 is an open source SOA Roadmap diagram that shows those milestones. The implementation schedule of that diagram shows the delivery of a Vacation Activities Packaging (V.A.P.) SOBA in Milestone 1. The implementation schedule also shows that in Milestone 2, the Vacation Activities Packaging SOBA will be integrated with the legacy Vendor Activity Management applications by the "Front Desk (FD) Sector" (an enterprise software integration).

This is an opportunity that the enterprise architect would like to pursue. However, he will need concrete numbers to justify investing in the SOA assets (SOA software assets and/or SOA software development practices) needed to automate "Integrated Vacation Packaging."

The open source SOA Roadmap has been designed to help the enterprise architect gather the numbers needed to make the business case for the "Integrated Vacation Packaging" open source SOA proposal. Function points as the size and normalizing measure for SOA assets is a policy used by open source SOA Roadmaps. Function points are the normalizer that provides the objectivity necessary for setting value objectives, quantifying value, comparing value and estimating value. [1] [2] Why? Function points are independent of software development techniques and technologies and therefore can be used to make comparisons between SOA and non-SOA Information Technology investment proposals.

An open source SOA Roadmap would first declare what the overall approach shall be to gather the numbers the enterprise architect needs to make this business case. Second, the open source SOA Roadmap would declare which measures to gather to make this business case.

An example policy for the overall approach is to first gather measurements in milestone 1 of the Roadmap. The objective of these measurement activities is to establish a history of measures that can be used to predict the performance of Milestone 2. The second overall approach objective is to gather measurements in milestone 2 to prove the estimated predictions for milestone 2 performance (delivery date, costs, etc.) were accurate.

Policies for measurement gathering typically fall into three categories: SOA efficiency measures, SOA agility measures, and business value measures.

Each of these measurement categories uses metrics (formulas) to determine measurements. Metrics are particularly useful for making business cases because they enable enterprise architects to trace measurable business impact back to SOA asset and SOA software development practice measurements. This means SOA asset and SOA software development practice measurements are elements of the metric (formula) used to measure business value.

Each of the SOA measures listed here use function points as an element in the metric (formula) used to calculate a measure. It is therefore the policy of open source SOA Roadmaps that function point size measurements for SOA assets shall be counted in accordance with IFPUG (International Function Point Users Group) standards. The IFPUG standard maintains the integrity, reliability, and accuracy of the size measurement. Also, given that our measurement goal during milestone1 is to gather historical data that can be used to calculate estimates for milestone2, each of the SOA measures listed here are for rates.

SOA efficiency measures assess the performance of and set performance goals for SOA assets (SOA software assets and or SOA software development practices). Delivery rate (or hours per function point) is a typical SOA efficiency measure. During development of a SOA asset, delivery rates measure the productivity of the development team. The meaning of delivery rates is the fewer hours a team spends to deliver a function point (i.e., a SOA assets), the more efficient the team is. Another common SOA efficiency measure is defect rates (or defects per function point), which measures 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. Financial SOA efficiency measures are cost rates (or dollars per function point). The meaning of cost rates is the lower the cost to produce a function point (i.e., SOA asset), the more efficient the team is in managing the investor's money.

SOA agility measures are also used to assess performance and set goals for SOA assets. However, when considering the agility of SOA asset performance, all measures are concerned with elapse time. Specifically the elapse time from when a request is made for a SOA asset to when the requested SOA asset is delivered for production use. IBM and SAP refer to SOA agility measures as a Key Agility Indicators. [3]

Speed of Delivery Rate (or function points per project elapse time in months) is a SOA agility measure likely to be specified in an open source SOA Roadmap. The meaning of speed of delivery is the more function points per month (i.e., SOA assets) the team can deliver, the more agile the team is.

Business Value Measures assess the effectiveness of open source SOA in contributing to the enterprise. A business value measurement is that portion of KPI (Key Performance Indicator) that can be credited to an open source SOA asset. A typical Information Technology KPI is "total operating cost." In today's economy, anything that reduces costs is valuable. Therefore, "reduction in total operating costs" is a measure that is extremely valuable to business. The enterprise architect can prove the effectiveness of open source SOA by directly attributing a reduction in total operating costs to open source SOA assets. The direct link from a reduction in total operating costs to an open source SOA asset is made by a comparison. A comparison reveals a disparity between the higher costs of a non-SOA asset and the lower cost of an open source SOA asset. This is especially true when an open source SOA asset replaces a non-SOA asset. The difference in cost is the "reduction in total operating costs" that can be attributed to open source SOA assets.

SOA Estimation Policies
Returning to our building example, the estimated time to complete the home was six months. The building architect was able to make this estimate with a high degree of accuracy because of the architect's choice for the building contractor. The selected building contractor has a history of building center hall colonials at a rate of 500 square feet per month. Therefore, completion in six months is a reasonable estimate for the selected building contractor to complete a 3,000 square foot center hall colonial. The underlying principle of this example is to gather historical performance measures into categories based upon qualifiers. Estimates are made by selecting historical performance measures from categories with qualifiers that match the building proposal's qualifiers. In this example, the qualifiers are type of building contractor (center hall colonial building practitioner) and type of building (center hall colonial). The selected performance measures in combination with the proposed building's square footage are used to make building proposal estimates.

Likewise, SOA performance measures should be collected into historical performance categories, where a category could be based on qualifiers such as software development practices, programming languages, predictable (something you have done before), or unpredictable (something new to you) SOA asset types. [4] Which qualifiers are used to establish a category for historical SOA performance measures is one of the responsibilities of the enterprise's SOA Center of Excellence. It is a good policy that historical performance measurements categories should be established with the help of metrics professionals.

The policies for estimation are specified in the open source SOA Roadmap. Estimation policies can be created just for SOA efforts governed by the Roadmap. The estimation policies can then be contributed to the Center of Excellence. Otherwise, if existing policies are available, the open source SOA Roadmap can reference them.

SOA estimate measurables are typically specified in an open source SOA Roadmap. Examples of SOA estimate measurables are the "size of the SOA assets," the "effort to produce SOA assets," and the "duration (in months) it will take to produce the SOA assets." The sizing element is critical to estimation because all estimated calculations depend upon it. Size can be estimated at any stage of the development process - including the stage before the completion of the requirements.

How SOA asset size can be estimated before the completion of requirements is beyond the scope of this article. However, the function point estimation practices recommended by IFPUG explain how size estimates are made with an incomplete set of requirements.

Effort and duration estimates can be calculated by multiplying the estimated size by a historical performance rate. That is, effort can be estimated by multiplying the delivery rate (hours per function point) by the estimated size. This effort calculation will specify the total amount of hours required to deliver SOA assets. Duration can be estimated by multiplying the Speed of Delivery Rate (function points per month) by the estimated size. This duration calculation will specify how many months it will take to deliver the SOA asset for use in production.

Building architects use the square footage as a normalizing metric for the measurement of building performance. Because the value of building proposals can be directly attributed to building performance measurables, the building architect is able to create a strong business case for investing in his building proposal.

The enterprise architect can use the function point metric much like the building architect uses square footage. The function point is a normalizing metric for the measurement of SOA performance. Function points that enable the business value of SOA proposals can be directly attributed to SOA asset performance measurements. The direct link between SOA assets and business value enables the enterprise architect to make a strong business case for open source SOA.

This article is Part 2 of a three-part series on the role open source SOA Roadmaps play in governing successful SOA transition efforts. Part 1 was about how to identify a SOA project most likely to be funded. Part 2 (this article) is about how to articulate a strong numbers-based business case for a SOA project. The third and final part is titled "How to Transition a C-Level SOA Skeptic into a SOA Champion." The third article will explain how to use a numbers-based business case in conjunction with reference architectures and open source SOA Roadmap diagrams to sell a SOA project to a skeptical management.


•   •   •

Copyright 2009© all rights reserved

More Stories By Robert J. Williams Jr.

Robert J. Williams Jr is Chief Enterprise Architect at Maxworks. He is an Enterprise Architect with 30 years experience that includes the Unix development team and Software Technology Centers at Bell Labs to the Architecture IPT Lead for the US Army's DCGS-A project (an Intel SOA project). He has been using ESBs / Web Services to develop SOA Solutions since 2004. He has developed distributed/ service oriented solutions since 1996 (Bell Lab's version of CORBA) and is a certified Rational Consultant.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.