Re: Application design & architecture

Trevor,
 
Thanks!  
I think you're saying that decisions regarding granularity can be done based
on system intent.  I support a wide variety of dissimilar systems that have
intersecting data requirements.  Those intersections change so the
temptation is to make the components as grainy as possible but then you have
a potential performance issue.  It's a balancing act that usually gets
determined by the urgency of the request...unfortunately.
 
Eventually there are patterns that you see in building components that
become a guideline but there are always those stinking exceptions....of
course with smaller, more distributed pieces to worry about the new concern
is the impact you'll have over the system instead of on a particular
program...but that's because global rule changes can be made once instead of
potentially hundreds of times.
 
The next question is if those rules belong in files or programs.  I used to
think files but finally, after arguing for them
http://c2.com/cgi/wiki?WelcomeVisitors
<http://c2.com/cgi/wiki?WelcomeVisitors> , I think that too depends on the
application.
 
(time to head home)
bill
 
 
 
----- Original Message ----- 

From: Trevor Perry <mailto:tperry@xxxxxxxxxxxxxxxxxxxxx>  
To: Midrange Systems Technical  <mailto:midrange-l@xxxxxxxxxxxx> Discussion 
Sent: Monday, May 08, 2006 3:08 PM
Subject: Re: Application design & architecture


Bill, 

These are great questions! 

IBM has developed a product called IBM WebSphere Service Registry and 
Repository. It is designed to provide governance of your SOA - simply put, 
it is a list of the services you have available. If IBM are doing it, then 
you know the change management vendors will not be too far behind providing 
us with better ways of knowing what we have available. Aldon have written a 
white paper outlining their support for your SOA efforts. MKS are also 
working in that arena. 

The question of "when to stop" is not an easy one to answer. However, that 
is what a good Services-Oriented Architectire is designed to answer - that 
is, what level of granularity should be adopted. Obviously, a file "get 
record" is too granular for a business process oriented architecture. And, a

customer order entry system has many processes involved and is not granular 
enough. And choosing how to build services based on parameter requests is 
scary - do I write one for all 200 pieces of information about a customer? 
or, do I write one for each type of information request I have? or, do I 
write one every time I need to get some combination of customer information?

Deciding the level of granularity, and which forms it will take, should be 
answered by the SOArchitecture. 

I think the issue has been that in the System i world, we have never 
encountered a Systems Architect. Getting used to the concept of having an 
SOA Architect is going to be a difficult transition. 

Trevor