- House Building Is Like IT!
- Establishing the Foundation
- Change Control and Quality Assurance (QA)
- Best Practices
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Establishing the Foundation
The foundation of the house must be firmly in place before you start to build the main part of the house; in the same way, it's essential to get the technical and applications architecture of an IT system in place (not just designed—it should be built and tested) before you start to build any code on top of it.
Everyone involved in the project must be fully aware of the "rules" of working on the project. When building a house, this might include applicable building standards; boundaries (exact placement) of floors, walls, and doors; shape, size, and style of bricks, glass panes, or other components; paint colors; etc. It's also important that everyone knows which tasks must be complete before other tasks can be started, so that a logical order of construction is established.
Similarly, in an IT system, everyone must know the rules of development and the boundaries of the system. For example, if the project is using the (highly recommended) Model-View-Controller (MVC) design pattern, each developer must know the following:
Which components form part of the Model—Enterprise Java Beans (EJBs), COM+ components, etc.
Which components form part of the View—HTML, WML, Swing, XML, JSP, .aspx files, and so on
Which components form part of the Controller—typically controller JSP or .aspx.cs files
NOTE
See this web forms design discussion for details on MVC.
It's also important that the designer and developer are well aware of which components (EJBs, COM+ components, stored procedures, JSPs, etc.) belong to which of the application services. Security, authentication, database connectivity/transactions, and so on are often handled by the application server itself, although sometimes custom code is needed to extend or replace some of these services.
The next level of application services—personalization, localization, chat, discussion forums, newsfeeds, alerts, and so on—may be partly provided by packages (for example, portal software packages such as BEA WebLogic portal, Plumtree Portal, or Yahoo!/TIBCO Portalbuilder). These days, even some of the highest level of application services—presentation services—are being provided for developers; for example, .NET provides form validation features and allows the developer to largely ignore the physical platform, as it automatically converts the interface into the appropriate view for the device on which it's being viewed—WML for a cell phone, HTML for a web page, and so on.
The presentation services application layer is likely to require the most change, maintenance, and rework, because it's the layer with which the user interacts directly. The underlying architecture—security, database, application server, and so on—is unlikely to be subject to frequent change. Just as in the house-building scenario, the things most likely to change most often are things like the curtains and wall paint—not the depth of the foundations or the size of rooms. Just as contractors need to know what size of bricks, doors, and windows to use, developers must know what "shape" of components should be used in each type of development—when to use JSPs, when to use EJBs, and when to use stored procedures.
The contractor needs to know the exact color code of the paint to use on each wall, the exact stock code of each plumbing fixture, and the standard size of the windows in the house to meet the customer's requirements, and the developer who is responsible for the View code must be fully aware of the exact customer requirements with regard to the user interface. (In both situations, of course, the expert can provide a bit of guidance to the user who may not be aware of the implications of his or her expressed preference.)