This is a co-worker's brother-in-law (see article below). He is all over the place, including at last week's Gartner's SOA conference that I attended. I will be writing a trip report as time permits although perhaps not as lengthy as my last trip report as time is becoming a bit of a luxury. The conference was very interesting, not least of which they predict that SOA is already becoming legacy and among many other topics there is a new buzzword (since 2006, I believe) which is WOA (Web Oriented Architecture). WOA basically refers to the REST method. Gartner indicated that best practice is to adopt WOA when you can instead of SOA. One thing I did get some clarity on is that there is no such thing as a SOA architect! This may be obvious to all of you but in the past year I have repeatedly heard this label used almost as a job position. SOA is simply just a design pattern! The correct terminology is to speak of a solutions architect who employs among other design patterns, the SOA design pattern. We all know that the ESB is also just a design pattern. And now there is discussion that ESBs may actually impede progress within the SOA strategy and it is forecasted that the ESB may also become obsolete within the next two years. Speaking of obsolescence, did you know that some actually even consider AJAX as already becoming obsolete (although it will still be THE major technology for rich internet applications for the next couple of years). Anyway, I have a lot to report -- it was a very productive week as I attended two separate conferences, one on SOA and one on Enterprise Architecture (hint: we need to all learn TOGAF in addition to FEA and DODAF) -- and I will try to provide a summary of some of what I have learned by the end of the week. I have all of the PDFs if anyone is interested. I also ordered the multimedia CD from the SOA conference (not the EA one though as I thought this was all just too much money). By the way, Java and C# are out; Ruby on Rails is now the *hot* language and web application foundation with Python being a close second hot language. (I wish things would slow down a bit so I could get a good grasp *smile*) And hey if anyone can figure out what to do with Second Life, please let me know! I know IBM hosts conferences there as well as a multitude of other companies but I find it very difficult to use.

How Much Will Your SOA Cost?
By: David S. Linthicum, CEO, Linthicum Group
Tuesday, March 20, 2007

I'm consulting now...at the project and strategy levels...and thus finding that a lot of real work needs to be done to get SOAs up-and-running. For most organizations, the first step of their SOA project is to figure out how much this SOA will cost. Thus, you can budget appropriately and obtain the funding.
It’s a good first step, but most organizations that want to build an SOA don't have a clue how to approach the cost estimation process. In many cases, they grossly underestimate the cost of their SOA, hoping their bosses and accountants won't notice later. In other words, go in low to get the approval, and reveal the higher costs later after it's too late...the investment has been made. Not a good management practice, if you ask me, but a pretty common one.
So, how do you calculate the cost of an SOA? While you can't cost out an SOA like a construction project, many of the same notions apply, including: understanding the domain, understanding how much required resources cost, and understanding how the work will get done. Moreover, understand what can go wrong and account for it.
Here are some very “general" guidelines:
Budget to budget. The problem that I'm seeing over and over again is that cost estimates are provided without a clear understanding of the work needed to be done. Indeed, you need to budget some time to create the budget. This means understanding the domain in detail, including:
1. Number of data elements
2. Complexity of data storage technology
3. System complexity
4. Service complexity
5. Process complexity
6. New services needed.
7. Enabling technology
8. Applicable standards
9. Potential risks
Typically it's expressed as:
Cost of SOA = (Cost of Data Complexity + Cost of Service Complexity + Cost of Process Complexity + Enabling Technology Solution)
For instance:
Cost of Data Complexity = (((Number of Data Elements) * Complexity of the Data Storage Technology) * Labor Units))
• Number of Data Elements being the number of semantics you're tracking in your domain, new or derived.
• Complexity of the Data Storage Technology, expressed as a percentage between 0 and 1 (0% to 100%). For instance, Relational is a .3, Object-Oriented is a .6, and ISAM is a .8.
So, at $100 a labor unit, or the amount of money it takes to understand and refine one data element, we could have:
Cost of Data Complexity = (((3,000) * .8) * $100)
Or, Cost of Data Complexity = $150,000 USD Or, the amount of money needed to both understand and refine the data so it fits into your SOA, which is a small part of the overall project by the way.
If you get this, you can get the rest of the cost analysis procedure; just reapply the same notions to:
Cost of Service Complexity
Cost of Process Complexity
Enabling Technology Solution
Some things to remember:
1. This is not really metrics (e.g., function points), because we really don't have historical data to abstract here. In essence, you need to use your own project management and project costing methods; just apply them to this new approach, using the formulas I'm suggesting above.
2. Count on 10 to 20 percent variations in cost for the simple reason that we've not walked down this road before. As we move from project to project, we'll get better at costing out SOA.
3. Make sure you dial in at least 2 major mistakes, meaning, selecting the wrong vendor, or hiring the wrong architect. You may encounter more, but it will almost never be less.
4. Make sure to change cost estimates as scope creep occurs, and it always does. The nice things about using formulas such as the ones I’m expressing here is that, as change occurs, you can quickly see the effect on the budget. Moreover, as change occurs later in the SOA projects, the cost of change goes up exponentially.
Finally, here is a sensible, no-nonsense approach to costing out SOA. While the actual numeric assumptions may be debatable, it's the approach that's refreshing. It would be great to see people start using this model, sharing any data points and providing feedback so it could be refined. Clearly, this would benefit the IT community a lot. I plan to develop a much more sophisticated model in the near future. If you’re interested, let me know, I’ll post it on my Web site.

David Linthicum (Dave) is an internationally known application integration and service oriented architecture expert. In his career Dave has formed many of the ideas behind modern distributed computing including EAI (enterprise application integration), B2B application integration, and service oriented architecture (SOA), approaches and technologies in wide use today.

Currently, Dave is the CEO of the Linthicum Group, LLC, a consulting organization dedicated to excellence in SOA product development, SOA implementation, and corporate SOA strategy. Dave is formerly the CEO of BRIDGEWERX, and is also the former CTO of Mercator Software and has held key technology management roles with a number of organizations including CTO of SAGA Software, Mobil Oil, EDS, AT&T, and Ernst and Young.