Re: Application design & architecture

Isn't that 'mechanism' a registry of objects?  We have modules and service
programs that perform many almost atomic functions but finding the ones that
will do what you need quickly is a problem.  It's not just naming
conventions, it's available parameters; desired output; and
specialization...and finding the particular components that will help you
build the information you need from the data you have.  In that sense, CASE
was the right tool at the wrong time.  I've built a system to register our
modules and service routines to make it easier to find building blocks based
on category and function and it sure does boil down to a subset of a CASE
tool.
 
Another problem is knowing when to stop!  Perhaps there are articles that
define this better but that question is always an issue when modularizing
components.  There's a line somewhere between what is functionally
necessary, what is necessary for the business, what is necessary for the
data storage and information gathering, etc.  The line extends through the
programming staff because many want to write a program that completes a
request instead of writing or picking modules that complete a request.
 
But that's a different problem...back to knowing when to stop; how much
information should be returned in a single request?  How specialized should
a request server be?  Sounds like easy questions but in practice, even after
careful analysis, there are always those requests that don't fit the mold of
many standards that are attempted.  So then write even smaller pieces and
fit them together?  Back to CASE we go then?  Or back half way at
least...especially if we're able to think in terms of unlimited machine
time.
 
 
bill
 
 
 
 
 

----- Original Message ----- 
From: Walden  <mailto:WaldenL@xxxxxxxxxxxxxxx> H. Leverich 
To: Midrange Systems Technical  <mailto:midrange-l@xxxxxxxxxxxx> Discussion 
Sent: Monday, May 08, 2006 2:05 PM
Subject: RE: Application design & architecture


>Moving a wall and adding a toilet CAN be SOA. 

Yes, it CAN be. Heck, I'll argue perhaps it SHOULD be. But for may 
iSeries shops the reality is they're not allowed to use something simple 
like a trigger, or SQL because too many people wouldn't understand it, 
and it would take "too long." SOA isn't going to be on the table for 
years. 

SOA is going to have the same problem CASE tools and OO design had 
before it. The payback -- and it's a big one -- doesn't come on the 
first and second use, it comes on the 10th and 11th. Many shops are 
pressed for enough time to "do it right" using the tools they have now, 
to get enough time from management to do something that _will_ add to 
the timeline for the first use (even if it saves _huge_ time and money 
down the line) is a nearly impossible sell. 

SOA also has an uphill battle because it's not visual. I don't mean 
there aren't visual tools to help you, I mean SOA is an architecture, 
not a presentation (as you well know). This makes it hard to sell to the 
"higher-ups." I've seen numerous cases where web applications (and 
client/server before it) were frowned upon until some programmer stayed 
late and make a crappy, but cute, visual interface to sales inquiry. He 
showed it so management and they literally saw the light. SOA has no 
such sales mechanism.