//Rant: Avoiding the Problem Duck Hunt

Rant: Avoiding the Problem Duck Hunt

Just a rant.

“I’ve got me a shotgun… let’s go find a duck!” 

I call that a “problem duck hunt.”  You have a solution, and you go hunting for a problem.  When a flock of “problem ducks” fly by, you fire away, hoping to hit something.  Doesn’t really matter what you hit. 

Software vendors do it all the time.  It doesn’t matter what the tool is, the tool vendors will shop around for general problems and attach their tool… Look at all the good things our tools do!

My view: Tools do squat.  People do work.  Tools help them. 

If the people aren’t aligned, incented, supported, and empowered to solve a problem… the existence of a tool will make very little difference.  The lack of a tool can slow them down, but the presence will NOT speed them up.

So when I saw this banner ad, from a competitor, I had to post this blog.  I blotted out the names of the competitor and the analyst that they used.  I suppose we do it too.  I’m ranting about the tactic. 

BPM_SOA_ad

In case you can’t read the ad, the headline says “Business Process Management and SOA” and in small print, “Follow the SOA Roadmap, learn from <analyst> and others how to tightly couple your IT efforts with business goals.”

SOA and BPM are good, but they don’t align IT to business.  People do.  Those people are performing a function.  The function is called Enterprise Architecture.  A SOA tool is used by an Enterprise Architect.  A BPM tool is as well.  Nice when they are together.

But the tool doesn’t solve this problem.  The people do. 

Technorati Tags: , ,
By |2008-04-30T17:14:00+00:00April 30th, 2008|Enterprise Architecture|3 Comments

About the Author:

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

3 Comments

  1. Paul Wallis April 30, 2008 at 9:39 pm - Reply

    Nick,

    The blurb for an upcoming conference about SOA in the UK states that “The question is no longer ‘Should we go SOA?’, its ‘How do we measure the value?’” and that “SOA is changing everything.”

    The amount of hype about SOA getting silly, even by IT standards.  

    I’ve made an attempt to go back to basics and explain simply how SOA works, how it can be used and, with the use of a real-world example, describe why a properly planned and implemented Service Oriented Architecture can create a flexible way of aligning business and IT, here:

    http://www.keystonesandrivets.com/kar/2008/04/understanding-s.html

    My take is that even though SOA could generate huge flexibility and long term savings, there is an associated increased cost to large SOA implementations over and above non-SOA solutions.

    You might also be interested in my recent post about Cloud Computing, which has been another "victim" of too much hype lately, where I try to put it in historical context:

    http://www.keystonesandrivets.com/kar/2008/02/cloud-computing.html

  2. Richard Veryard May 2, 2008 at 11:36 am - Reply

    Nick I completely agree with you. It’s the people who do the work.

    But then the question is this. How do you cost-justify the tools to allow people to do a decent job? What proportion of any benefits is it fair to attribute to the tools?

  3. NickMalik May 3, 2008 at 5:42 pm - Reply

    Hi Richard,

    Excellent question.  I’m frustrated with the "tools-first" approach.  You are right, of course, that there is a need for tools, and they are not free.  

    Tools enable and improve the work of people.  If you NEED to cost justify a tool, then have then do their job without the tool for a while.  Then, use estimates of the improvements in speed, efficiency, effectiveness, quality, consistenty, and compliance in order to justify the tools.

    This is not to say I’m supportive of ROI as the only measure.  Some things you spend money on improve quality and consistency, or help you to be more compliant with policies.  But if you don’t know what it is like to do the work without the tool, how will you know how much the tool is worth to you?

    So that’s where I’d start.

    — Nick

Leave A Comment

nineteen − sixteen =