CERN Accelerating science

Top 8 Architecture Tips for Distributed Computing by Richard Monson-Haefel

1.Use a relational database. Use relational database systems for persistence. They are ubiquitous, proven, standardized, maintainable, robust, and well supported by third- party tools. While Object-Databases are a better fit for object-based systems, they are not well supported by third-party tools like reporting systems and data warehousing systems. In addition, standardization in OODBS is not as mature as it is in relational database systems, so applications tend to be less portable across database products. Finally, the pool of professionals that know relational database technology is a magnitude larger than that for OO databases at all levels, which makes it easier to staff projects.

2.Normalize the relational database. Normalize the relational database without regard to your object model. The object model is ephemeral; the data is permanent. In other words, its more likely that your relational database will last into the next decade then your OO application. A properly normalized database will be compatible with any system, not just the OO system. The database will be accessed by unanticipated systems and outlast the system that inspired its creation.

3.Buy, don't build, a reporting system. Do not develop your own reporting system. They are enormously expensive to develop and rarely outperform commercial alternatives. Reporting products that query RDBMS and provide HTML output, WYSIWYG development, scheduling, and distribution are commercially available. Most homegrown reporting systems fail to meet expectations and are eventually replaced by commercial products.

4.HTML is the preferred user interface. HTML user interfaces--generated by Servlets and/or JSP--are easier to develop, faster to market, and simpler to maintain than Java applets or applications with GUIs (graphical user interfaces). JavaScript and applets can be used (sparingly) to enhance the user interface where necessary. While it's true that GUIs provide more flexible presentations for the client, the complexity of GUI interfaces adds significantly to project costs, including both maintenance and development. HMTL interfaces, using JSP, can be developed more quickly and maintained more easily. In addition, HTML interfaces avoid firewall problems, which are a serious problem in B2B and other Internet applications.

5.Flexibility vs. performance. Weigh the flexibility offered by vendor-neutral abstractions against the performance offered by high-fidelity vendor-specific products. Vendor-specific products tend to perform better then vendor-neutral abstractions because the vendor-specific product is tightly coupled with less layering and abstractions. However, vendor-specific products create vendor "lock-in," thus removing choice and tying the success of your system to that of the vendor.

6.Understand technology. Study technology at its lowest levels. It's not enough to understand what technologies do or how to use them. Software professionals must study technology at its lowest levels in order to understand when it's applicable and what its limits are. Study TCP/IP protocols, operating systems, databases technology, compilers, etc. Your studies will better enable you to make informed decisions about what technologies to use and when to use them.

7.Hire an experienced architect. Software is expensive to develop and a huge investment for organizations, yet we continue to hand off the responsibility for architecting systems to unqualified individuals. Organizations don't use the bookkeeper to handle their IPO, they don't use the night watchman to draft legal contracts, and they shouldn't use senior programmers to architect their information systems. Scout out the best architects in the business. Hire someone experienced, someone mature, and someone who not only talks a good game but also has a good track record. Be prepared to pay a lot for a good architect. You'll save ten times their salary by avoiding a failed architecture.

8.There's no panacea. Whether its EJB, Servlets, CORBA, JMS, or the OO paradigm--no solution is a panacea for solving every aspect of a business problem. Study the business problem, understand the technology, hire an experienced architect, and choose to build systems based on appropriate technologies.