A/D Trends: Architecture Drives Tool Choices
My 17 years in the AS/400, S/3X market have always dealt with application development in some way. From APAR jockey for the S/36 COBOL compiler, to business manager for AS/400 AD, I’ve been "inside" the AS/400.
For three years at Cognos, we pioneered the "opening-up" of the AS/400 through bleeding-edge porting projects with C code and Unix files. We sold third-party 4GL tools in the heyday of AD/CYCLE.
For the past seven years, Astech Solutions has conducted hundreds of AD studies for customers and vendors alike. We even qualified all 35 development tools for inclusion in IBM’s AD program and trained more than 1,000 business partners in AS/400 technologies.
It’s not surprising, therefore, that the question I’m asked more than any other is: "With all you know about tools, which is the best one?"
The honest answer remains the same: "It depends on what you want to do." The implications of this answer, however, are not fully appreciated. Most customers are driven by their tool choice as if the purchase of the "best" product will guarantee their good fortune. Conversely, selecting the "inferior" product guarantees doom and gloom. Of course, the vendor community plays on this fear, playing product against product, feature against feature.
From a vendor perspective, it’s all about enticing customers to choose their product over that of the competitors. However, from a customer perspective, this is truly putting the proverbial cart before the horse -- you shouldn’t be selecting tools until you have a blueprint. Then you select the one that fits the need.
Who out there advocates good architecture over tool? Good IT management should. Because if it doesn’t, one of two things happen:
The business eventually runs hybrid (and disjointed) applications with distributed, heterogeneous (and inconsistent) databases, clients and servers; or
The business is not able to meet requirements, and thus procures additional products and inherits responsibility for their integration (see above).
What is a good architecture then?
It begins with taking stock of what you currently have, including hardware, software and the connections between them. Included in this inventory list are the applications, versions and databases used in your organization, along with the protocols, middleware standards and APIs. What tools and programming languages are in use? Do you have all this mapped out on a single page?
Then you need to know where you are going. What functions do users require? Is it a thin- or fat-client model? What client will be selected? How is it connected to servers? Which servers exist to provide what function? How is transaction integrity maintained? In the organization, who does backup and recovery?
Now the well-architected solution will have the following characteristics:
- Relational data is structured using an RDBMS standard.
- Access to the data is appropriate for the application type, consistent across the organization, performs to specification and maintains integrity of transactions.
- As much work as possible is factored into the database (stored procedures, referential integrity, trigger), thus saving efforts in code development.
- Data distribution, propagation and synchronization is managed at a single point of control.
- Unstructured data is coupled using a single messaging/workflow standard.
- Legacy applications are "black boxed" providing consistent, callable interfaces;
- Client user interfaces are standardized.
- A systems management architecture is instituted.
This usually has the effect of "normalizing" your IT systems. For every critical aspect, have a single standard. Where multiple systems are required, utilize a standard "middleware" or API to effectively layer the architecture.
There is no easy way to accomplish this, no magic wand. No single tool enforces this standardization (remember AD/CYCLE?).
After we have the architecture, it’s time to select tools. What you may find is that despite the temptation, no single tool will satisfy all the requirements driven from the architecture. As a result, one customer can be using ILE RPG, Delphi, Crystal Reports, Lotus Domino and Synon [now Sterling] and be doing exactly the right thing. Another customer uses the exact same products and has chaos. Why?
If the product meets the architectural requirements and "fits" the architectural hooks, it will work. If products are arbitrarily chosen: chaos will surely develop.
Send me an e-mail about your favorite AD tool, and tell me about the architectural points it covers. What are the pros and cons? In a future article, I’ll share your feedback.
Mark Buchner is president and founder of Astech Solutions Inc. (Aurora, Ontario), which applies technology to the practical needs of the AS/400 market. [email protected]