3: Constructing Your Goods
The construction phase of an IT project involves individuals who have disparate skills and areas of expertise within IT, as well as interests from without, and managing a "build" requires tracking complex interactions.
The author prescribes a three-step process:
- Identify the required level of availability.
- Determine the design specifications.
- Proceed with construction steps.
Identify the Required Level of Availability
The author addresses "availability" as a key concept for IT projects.
The basic level of availability identifies the core product with no "safety features" at all, such that it satisfies the system's functional requirements and nothing more (all systems are operational ,input is good, and nothing unexpected happens).
A high level of availability is defined as having sufficient error handling and redundancies to recover from defined faults or unplanned outages. The goal is for the system to recognize the outage, warn users, stop processes that cannot run until the situation is resolved, and recover as quickly as possible.
A continuous level of availability enables the system to remain available, inasmuch as possible, during planned outages such as upgrades or backups, such that the system doesn't need to be taken offline for routine maintenance.
A fault-tolerant level of availability provides backup methods for performing mission-critical tasks even under adverse circumstances (the example is given of NASA's mission computers that had multiple redundancies so that if one component is damaged during a mission, the craft can still function). This is often achieved by having multiple servers or connections, such that processing can be shifted to another system (and data to another cable) should the main one fail.
Regardless of the level of planned availability, be aware that things go awry. The author turns again to the example if the Titanic, which included many redundant systems to ensure it was "unsinkable" - but in the end, it sank nonetheless, and the disaster was all the worse due to overconfidence (e.g., the number of lifeboats was not increased because the investment in all other safety features made it seem unlikely they would be needed).
Determine the Design Specifications
The author identifies three sets of specifications:
External specifications include any interfaces to the system, including both the user interfaces and any intercommunication with other systems.
Internal specifications indicate what the application or system does, in and of itself.
Manual specifications indicate the need for training and support (think "user manual" rather than "done by hand")
Proceed with Construction Steps
The author defines steps in construction:
Define the building blocks.
Currently, most organizations have a myriad of different information systems for handling various tasks, and the challenge is identifying which existing systems will be touched by a new project, as well as what new systems will need to be implemented.
The author identifies a handful of "alternatives" for construction:
- Off-the-shelf: A solution that is put into place largely as-is.
- Configurable Solution: A solution that cannot be modified (black box), but a developer can create customizations by using bolt-on applications or middleware
- Custom Packaged Solution: A solution that can be modified (developers can tinker with the code of the solution itself)
- Custom Development: An application is developed for the project
It should be self-evident (but is explained nonetheless) that the less that must be done to customize a solution, the cheaper and faster it can be put into place, but the less likely it will be to meet the specific needs of the business, both when it is initially purchased and in the future, as the needs of the business evolve.
Procure, collect, and stage materials.
Once the "Blocks" are defined, it's necessary to undergo a procurement process to obtain them. This can be a complex process, as vendor solutions may vary, and you must evaluate the options for each "block," both in terms of the capabilities of the software and the relationship you will have with then vendor who provides it.
Lay in the main pieces
In general, system development begins with the largest pieces: the hardware and major software components are installed, configured, and tested (the testing here is called "unit testing" as you are ensuring that a database functions, in and of itself, rather than in combination with other code).
Lay in the filler pieces.
After the major components are in place, additional work is necessary to connect them and ensure that they communicate and share data as necessary to the goals of the project, and taht they pieces work together harmoniously.
Lay in the cosmetic pieces
The author addresses user interface and training materials as the "cosmetic" elements - once the systems work perfectly, then provide access and instructions to the people who will use the system.
(EN: I find this dismissive and ill-advised. If the users who will benefit from the system, and the individuals you must count upon to make the system operate properly, are the very last thing you consider, almost as an afterthought, then the project will fail to accomplish its objectives, no matter how well the machine "works" by purely mechanical and technical standards.)