Re: Application design & architecture -- MIDRANGE-L

I am sure that quite a few people would be interested in a discussion onarchitecture, but we have to decide just what we mean by that. Forinstance, I would consider your example of file maintenance using asubfile as implementation, not architecture.Nor do I think that architecture is about choice of language although ofcourse a Java implementation would be very different from one written inRPG. Discussions on architecture should start at a higher level,beginning with system specification and design and this can only takeplace after we have worked out our objectives. What are these? What arewe trying to to do?

I suggest that we are trying to create systems that meet end userrequirements and that we are attempting to do this within reasonabletime and cost scales and without risk . What is more we must be able tokeep these systems up to date in time with the ever evolving world ofthe end users. The systems must be robust, scaleable, and, for more andmore companies, internet enabled and available 24/7. All applicationsmust be totally integrated, sharing an integrated corporate databaseover which we have real control, with proper security, audit trail, highavailability, etc. I could go on.

Our chosen architecture will be influenced by the type of database thatwe choose. Can relational databases, the only choice on most systems,model the ever changing complexity of the multi-dimensional real world?I believe that they cannot and that they are a severe limitation toprogress.

In addition, such a discussion should consider how we might overcomesome of the most basic problems of building systems, such as theproblems of changing systems once they have been put into production,and the difficulty of integrating applications. Both of these problemsare the result of the architecture. Another example is the need for afinely detailed specification before we can start implementation. Weshouldn't need to do up-front physical database design. How much betterif we could do incremental development as we go along without trying toanticipate future requirements which in general is not possible.

One of the largest problems in the industry is the amount of time thatdevelopers/programmers spend re-inventing the wheel. I consider thatprogramming is the most inefficient process ever devised by mankind inany field of human endeavour. It is fine for masochists and I may beone, but it is horribly inefficient. Before you protest, if you are aprogrammer, just look back at your previous few days work - you may beproud of what you have achieved and justly so, but what actualdifference has it made?


Can we design an architecture that will make us more efficient?

If enough people are interested, it might be a useful discussion.


Rob Dixon
www.erros.co.uk
www.boarstall.com