For any large-scale project, making certain that costs are justified relative to the expected benefits is essential. You also need to determine whether or not the project is following good project management disciplines based on the organization’s methodology and quality management standards.
Only by auditing your project, can you ensure that both of these criteria are met. However, a third type of review, while undertaken less frequently, is equally important.
When developing large, complex, Web-based applications, verifying that the proposed architecture will perform as expected is critical. This can only be achieved by conducting a thorough technical audit.
Such an audit can be conducted when the initial architecture is proposed. However, the ideal point is when the first working prototype has been supplied to the users. At this point, a review of the architecture is not intended to second-guess the designers, but to apply a fresh, external perspective to make sure that the proposed approach will achieve its objectives.
This article explores some of the issues we considered during a recent audit conducted over ten-day period.
Architecture: The architecture was reviewed to ensure we were following industry best practices for distributed architectures. We also needed to determine if we were making good use of middleware products, and to see if we could take advantage of any WIN2000 improvements. We were concerned we might have introduced unnecessary complexity. As a result, we discovered we were using too many (seven) different programming languages because of the different tools we had selected.
Scalability and Load Balancing: Web applications are typically more difficult to tune than mainframe applications for the simple reason that the collective experience of our industry in building Web-based applications, and the tools for modelling the applications, are not as mature. Accordingly, we reviewed our application to ensure it could scale to support thousands of simultaneous users and provide good response rates. We also evaluated the proposed configuration for database and application servers for optimal redundancy and concurrency. As well, we looked for obvious ways to tune the data schema for SQL queries and the efficiency of stored procedures.
Integration: A key architectural factor affecting application performance is the number of discrete components that have to be interconnected. In our application, we planned to use a number of components such as forms software, I-Payment through CyberCash, PKI through Entrust, Exchange, Oracle Application Server, and MQ-Series. We reviewed the architecture to ensure multiple interfaces among the components would not cause performance bottlenecks or delays at anticipated peak usage. We also wanted to be sure the tools would work together efficiently as a multi-threaded, coherent whole.
Reliability and Recoverability: Although the application we are implementing does not need to be fault tolerant, it does require high availability, particularly during business hours. To meet these requirements we reviewed the architecture from the viewpoint of system availability, server redundancy, fail over, and recovery.
Security: We also reviewed the architecture to ensure it provided high levels of protection against security breaches through the firewall as well as authentication of users no matter if they were submitting data via the Web site or via e-mail. In particular, we reviewed how we were planning to use the Entrust public key infrastructure.
Maintainability and Testability: Finally, since we are building an application to be used for many years to come, we wanted to ensure the software was designed to be easy to maintain and enhance. We considered such factors as code structure, error and exception handling, support for testing, and documentation. And while we did not review the architecture from the perspective of UI and human factors, this is an area you may want to look at for your project.
As a result of our audit, we were able to simplify our architecture while ensuring the solution is easier and less expensive to maintain. It also allowed us to make certain the development team had a common understanding of the architectural vision.
The final word: technical audits are worth the time and effort, as they can make the difference between the success and failure of your project.
Hughes ([email protected]) is a client delivery executive with EDS in Toronto. He is currently project director for Ontario’s Integrated Justice Project.
