Jaa

The SOA and simplification paradigm shift

  • Artikkeli

In order for SOA to deliver in its promise, we need to change the way that the requirements analysts approach problem solving. This is critical.  I can prove it.

When I gather requirements from the user, I can't just ask "what do you want?"  The question is meaningless.  I have to

  • understand what is going on, then
  • envision a new process, then
  • suggest the new process with alternatives. 

In that process, I am making assumptions about what constraints to apply to the process.  Is there anything I cannot do?  The only constraints are to reduce costs or automate manual processes.  That is not enough.  

When a company decides to implement a commercial software package to solve a problem, a different approach takes place.  It goes like this:

  • understand what is going on, then
  • compare it to the process favored by the tool, then
  • decide where it is feasable to extend the tool, then
  • suggest the tool's process with possible extensions. 

In order for SOA to work, in order to gain flexibility and agility and reuse, we need to follow this second process, even if we are solving a problem with composition of existing services... even if we are not purchasing software... even if 100% of the components are home grown.

THESE STEPS MUST APPLY.

It is this second process that assumes that the company already has an answer. It is this second process that requires teams to solve their problems by FIRST considering whether an existing answer is "good enough" and SECOND considering the cost of extending it.  We will never achieve simplification without doing this first.

Training the requirements analysts to think this way may be the single largest shift towards SOA.  It may be the most difficult thing to do.  Yet, I am convinced that this is the only way to accomplish it. 

Proof: The project I've joined is staffed with truly intelligent, earnest, hard-working people with good intentions.  However, they followed the first process above.  They developed a "shiny new" process and that drove the needs for a "shiny new" tool, even though the company already had a couple of tools for the exact same thing.  They never ever considered looking at those tools, or constraining their solution by those tools. 

We must constrain our solution to existing tools first.  Those tools don't have to be something we are buying.   They can be, they must be, the things we already own. 

SOA depends on creating services that will be reused.  Unless we choose to reuse them, then that promise of reuse will never be fulfilled.

Comments

  • Anonymous
    July 13, 2006
    The processes you describe don't apply only to SOA, but should apply to all projects - and also should start even sooner, like with the project inception.  What do you want to do?  Is there a tool available which can be leveraged or do we build/buy a new tool?  Justify answers accordingly.

    Technologists in general tend to prefer to reinvent as it allows us to play with new tools and new toys - even when a passable or even preferable solution exists.  The key point here is simplification.  This doesn't just apply to the requirements analysts - and  probably more likely can't really (unless they are REALLY good), simply because they don't tend to know the backend systems that well.  Ideally, your iterative process should be for the requirements analysts to capture the requested requirements and work with the development team to find the best approach within the given system constraints.  If the decision is to build - with what technology standards, etc.  If it is to buy, then what tool and what processes are to be leveraged.  The idea, SOA or otherwise, is to simplify processes and make tasks reusable and flexible.  IE - adaptable to change, thereby getting the most out of the existing system for the longest possible time at the least amount of money.
  • Anonymous
    July 13, 2006
    The comment has been removed
  • Anonymous
    July 14, 2006
    I'd say you might also have a step in the second group that asks if any of the process can change to fit the tool in places where there is a large impedance mismatch. If a companies is doings things a certain way 'just because', and that way doesn't fit with the majority of the industry (for no good reason) then there is value in presenting a different way of doing things because it'll save them money by elminating tailoring and workaround.