David S. Linthicum: When SOAs Fall Down

By David S. Linthicum

November 1, 2007 —

It’s just one of those things. Technical projects fail, and SOA is no exception. So, how do these failures occur? Like they always do: as a result of poor planning, lack of understanding or the inability to execute—and that’s the short list.

Truth be told, SOAs are not that difficult to define, design and build. It’s just an architecture leveraging a bunch of technology that any good technologist can get to work together. However, getting the architecture in an optimal and functional state that best provides value to the business seems to be the difficult objective to achieve.

In order to get SOA right, you must carefully consider the business drivers and your own problem domain (in detail), and learn how to determine the problem patterns so you can thus determine the solution. Seems simple, but many enterprises get this wrong, and then declare “SOA was a failure,” when in reality the people failed and not the technology or the approach. There is a huge difference.

There are three major reasons SOA projects, or the first steps toward SOA, fail these days. They are: • Lack of understanding • Lack of planning • Lack of follow-through

Lack of understanding is the core issue here. Developers and architects do not take the time to understand the essence of SOA, including what it is, how to do it properly, and how to grow it into the enterprise architecture longer term. While some take time to learn, most empowered with the project budget drive forward with very little perception as to how a SOA will meet the needs of business. Indeed, most of these guys “manage by magazine,” making critical decisions based upon popular “technology” culture.

For instance, I’m always taken aback by the number of project leaders who jump out and pick some SOA technology before they even understand their own issues. A typical question would be “Which ESB?” when the correct question is “Why an ESB?” Many jump on some technological bandwagon only to find the technology they selected was perfect for some enterprises, but not theirs. Thus, they have to run around at the last minute and look for new technology, or worse, just press forward with the wrong technology, which is sure to kill the SOA.

In any event, the trick to create the right SOA for your enterprise is really no trick at all. Understand your business issues, determine the ROI, create a semantic-, service- and process-level understanding of your domain, design your services, create your governance model, and then, and only then, pick the technologies that will work for you. Typically, the result will be a bunch of different things purchased from a bunch of different vendors, in order to create an optimal solution.

Lack of planning is really an extension of lack of understanding. There is no notion that the A in SOA is for architecture, and architecture takes some time and effort to figure out in the context of all of the business demands and drivers.

The reality is that building a good SOA means going through a set of processes so you can understand the core issues within your organization and take formal steps to correct them, all the while improving on IT efficiencies, thus effectiveness. There are several threads in this plan that you need to consider, including: • The business plan, or how you think SOA will impact your business longer term, including return on investment, and how technology and business can work better together going forward. • The technology plan, or how you think you should approach the requirements, design and eventually the SOA technology you’ll need. This means defining a solid methodology around building a SOA for your enterprise, including a semantic-, service- and process-level understanding of your own problem domain before you attempt to toss random technology at the problem.

Lack of follow-through refers to the problem that many who create a SOA don’t take the architecture to its logical conclusion. This means that they stop after completing a tactical project, and don’t take SOA to a level where it’s driving systemic change for the better, including better agility of the architecture and reuse of key IT assets. However, if only a portion of the architecture is SOA-tized, then the value is limited, perhaps nonexistent, considering the larger architectural issues.

SOA is a core change to the way we do enterprise architecture, thus it’s an architectural pattern or approach, and you can’t just stop after you complete your first domain. Indeed, core to this is long-term planning around the architectural changes that need to occur. If you skip that step, your SOA efforts won’t have the strategic advantages you’re looking for.

What strikes me about all of the reasons SOAs fall down is the fact that this all relates to practical and logical things. There are no secrets to pulling SOA off, just some upfront work, planning and careful execution and evaluation.

David S. Linthicum is a managing partner at ZapThink. Reach him at david@zapthink.com

Share this link: http://www.sdtimes.com/link/31280

Windows & .NET Watch: Shun the Gantt, embrace the burn-down For software development projects, burn-down charts are more accurate and useful than Gantt charts.

David Lyman named publisher of SD Times BZ Media promoted David Lyman to publisher of SD Times, the newspaper of record for the software development industry. Lyman heads up advertising sales and marketing for all SD Times vehicles, including the print and online publications, e-newsletters, webinars, supplements, banners and lead-generation programs.

David S. Linthicum: Roles Shift in SOA World Lately, a number of debates have erupted around who does what when it comes to building and operating a SOA....

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST