|
Hi Rob,Thanks for your input and your interesting thoughts on the subject. I spent a bit of time on your website and will go back to it very soon to finish what is an indeed thought provoking read on a rather unusual approach for the IBM midrange world. I will also contact you privately when I have finished going through the info on your website, in order to request access to test drive Erros.
The scope of my original post was much more humble and did not necessarily extend to reviewing accepted standards like the use of a relational database for example. I however totally understand and agree with your definition of architecture in that context. My definition of architecture in the previous post was in fact merely describing the design of components (and the layer they belong to) and their interaction. As for my aim with this post, I think I was hopping to get feedback on the pros and cons as well as the best ways and practices when extending modularity to an n-tier model.
Most shops today use a certain level of modularity, but not necessarily to the extend of totally separating the presentation from the business logic and the data access. I believe that an n-tier architecture model is a worthwhile step forward, but its attractiveness seems to hide a fair number of questions which I hope would be discussed here by people who have attempted such a move or who are currently contemplating an n-tier model in their future developments.
<Rob> Can we design an architecture that will make us more efficient? If enough people are interested, it might be a useful discussion. </Rob>I really hope this will lead to useful discussion where ideas and concepts as well as technical options and issues can be part of the debate. Isn't Efficiency a nice ideal?
Maybe we should carry on on two fronts in order to get the most from both threads:
- On thread purely related to n-tier model in an RPG environment,- Another thread on Application Architecture in general where broader concepts could be discussed.
G4! Rob Dixon wrote:
I am sure that quite a few people would be interested in a discussion on architecture, but we have to decide just what we mean by that. For instance, I would consider your example of file maintenance using a subfile as implementation, not architecture. Nor do I think that architecture is about choice of language although of course a Java implementation would be very different from one written in RPG. Discussions on architecture should start at a higher level, beginning with system specification and design and this can only take place after we have worked out our objectives. What are these? What are we trying to to do?I suggest that we are trying to create systems that meet end user requirements and that we are attempting to do this within reasonable time and cost scales and without risk . What is more we must be able to keep these systems up to date in time with the ever evolving world of the end users. The systems must be robust, scaleable, and, for more and more companies, internet enabled and available 24/7. All applications must be totally integrated, sharing an integrated corporate database over which we have real control, with proper security, audit trail, high availability, etc. I could go on.Our chosen architecture will be influenced by the type of database that we 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 to progress.In addition, such a discussion should consider how we might overcome some of the most basic problems of building systems, such as the problems of changing systems once they have been put into production, and the difficulty of integrating applications. Both of these problems are the result of the architecture. Another example is the need for a finely detailed specification before we can start implementation. We shouldn't need to do up-front physical database design. How much better if we could do incremental development as we go along without trying to anticipate future requirements which in general is not possible.One of the largest problems in the industry is the amount of time that developers/programmers spend re-inventing the wheel. I consider that programming is the most inefficient process ever devised by mankind in any field of human endeavour. It is fine for masochists and I may be one, but it is horribly inefficient. Before you protest, if you are a programmer, just look back at your previous few days work - you may be proud of what you have achieved and justly so, but what actual difference 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
midrange.com
___________________________________________________________
Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
