SOA: Does it deliver its promised value?

Brian Orrell sent me a link to a David Chappell (the SOA expert, not the comedian) blog post titled “Is SOA Failing?”.  In his post, Chappell states plainly that the “value [of SOA] is nowhere near as large as we’d hoped.”  He goes further in a podcast by saying that “SOA is failing.”  Overall, Chappell delivered his usual dose of thought-provoking content and it was a solid message. Key points:

• SOA is failing because services are (often) not reusable
• The failure is largely human – technology can deliver, but humans struggle to design or consume services in that form
• SOA works better when it delivers highly-technical services (e.g. identity management) or when it delivers raw data

…and as a separate nugget, he included a distinction I had not thought about yet:

• SOA usually describes services consumed by technologies or developers
• SaaS describes consumer-facing services

I wholly agree with David Chappell:  SOA is limited in its ability to create value for an organization.  Recently, I spent time at a large non-profit organization creating services (and implementing MSE) to centralize user authentication & authorization for a number of .NET applications.  Our team developed and exposed new services so that applications could call into a central system for identity management.  We also used services to expose raw data: states, countries, members, etc.

The architecture worked well, but the value was elusive .  First, abstracting security logic from each application and centralizing it sounds simple, but in practice it was challenging to reuse identical logic for all applications.  A bigger limiter was that it took a substantial effort to train and transition the client staff from an “I need to build my own…” mindset to a “I need to go find…” mindset.  Arguably, there was significant value lost in translation.

SOA delivered a solution for our need, and the software is serving the organization well.  But, SOA did not deliver the enormous value that experts like Chappell once touted that it would.  SOA is useful, but I am not convinced that it is game-changing.

What do you think?  Is SOA failing?

The Cost of ‘Good Enough’

A recent Visual Studio Magazine article (The Cost of Static) hints that offshore development can have costly downsides hidden in the form of missed requirements or poor implementations. While I agree that offshore development (or any level of offshore/onshore/nearshore/remote development) can be costly, I think the author missed a bigger risk.

The real cost is the cost of “good enough.” When developers slack and deliver software that is merely good enough, companies lose the opportunity to capitalize on excellent work. Excellent work can attract new customers, lower operating costs, build brands, or help the companies achieve other critical objectives. Errors, re-work, or missed intent can cost companies dearly. Not only do these problems force businesses to invest additional funds, they also jeopardize organizational relationships and goodwill.

Good enough won’t cut it. Unfortunately, there are many developers who deliver “good enough” regularly. This article highlighted one such example. Similar results could have come from a local contractor or an offshore firm. Location is irrelevant. The real caution for businesses is to hire the best talent available to meet business objectives and deliver quality software.

Delivering Quality Software

Coworkers who know me well will tell you that I am passionate about delivering quality software.  I have a mild obsession with unit tests, code coverage, complexity statistics, FxCop analyses, and the like.  I get a geeky satisfaction when I pop open a code coverage report during a code review and see coverage stats up in the 90s.  And few things are more professionally satisfying to me as a developer than a good code review session where we boil a seemingly complex ball of logic down into a few simple lines.  Ah, great success!

Now, I’ll admit that I’m a rare breed.  I write lists for everything, I love my Quicken account registers, and I spend an inordinate amount of brain cycles thinking about efficiency (my car-packing skills are the stuff of legend!!).  But, while these traits may explain my attention to detail, they don’t explain why I care.

Delivering quality software allows me to innovate faster and deliver more than others who don’t monitor quality. 

As a creator/architect/designer, I can try new ideas with the confidence of knowing that bugs will surface immediately.  If my code breaks something, automated unit tests will fire error notifications and I will know about the problems – fast.  These messages give me the information to address problems quickly before additional logic complicates the fix… and they also give my team the guilty pleasure of asking me to don an obligatory “you broke the build” pink  cowboy hat.  (We geeks love our build rituals.)  As a result, I can try new ideas without investing hours or days in manual regression tests for each trivial change.  Effective unit tests take time to write, but they pay me back with dividends.

Since I can innovate faster, I can deliver more.  Naysayers and change-phobes no longer can persuade me that it will “take too much time to make a change.”  I can refactor with courage and deliver better software.

Plus, it’s fun…