Put Fashion and the Latest Trends in the Back Seat
Let's say your company needs a step-change boost in efficiency and productivity. Top management decided the way to do it is a major new computer system. You are in charge of it. The big boss wants the "latest and greatest." Should you start by looking up reviews and ratings to find out which hardware and software are the best or most popular? Sure, if you want an expensive failure!
The Very Beginning
If you simply get whatever is currently in fashion, maybe it will run. But it may not be what you need. It may make everyone miserable for years upon years instead of helping the business.
Your first step is to ask a question: What does the business need to do? To come up with the answer, look hard. Really think about it. Then find the computer system most suitable for doing that.
Years ago, when CP/M was popular, my mother had to retype her master's thesis a zillion times. When she decided to go for a doctorate next, my father decided to buy one of those new-fangled desktop computers. A word processor would save a lot of retyping for her dissertation. So far, so good.
Then my parents tried to take a short cut. They told me about their plan, then said, "So, which computer should we buy?"
I refused to name any. I advised them to visit computer stores and "test drive" word processing programs. Back then, word processing programs worked very differently. Some used key combinations to embed formatting commands. Others used special syntax to distinguish formatting from text. My mother is a touch typist and had unusual word processing needs. Those differences would matter to her. When they identified her favorite program, then they should ask what machines could run it and buy one of those.
Let's just say my parents were not happy. I wouldn't budge, so they went to computer stores in the big city. My mother's PhD is in medieval British literature. Modern English lacks some of the alphabetic characters the language used to have. The missing characters are represented now by striking one modern letter and overstriking at a half-width offset with another modern letter.
None of the word processing programs could do that. WordPerfect could be modified appropriately. Only two combinations of computer and printer were available that could run it: a Kaypro running CP/M, and the new darling of the market, an IBM PC running DOS. The IBM system cost twice as much. They bought the Kaypro and it did exactly what my mother needed.
I have seen Fortune 500 companies make mistakes much like the one I refused to let my parent make. The most common are:
- Getting a computer system to do everything the same way it was done before, with the new computer system involved wherever possible.
- Buying a computer system that a sales agent says will do everything they need, but that does not really fit. Having spent the money, the business is forced to contort itself to fit the computer system.
Either mistake is expensive. The first spends money on the new computer system, but misses the opportunity to make workflow more effective. People who understand the workflow in a business rarely understand what a computer could and could not do. My mother could overstrike two different characters at a half-kern offset easily on her typewriter and had no idea it would be almost impossible for the latest, greatest word processors.
The second mistake is worse. After shelling out money to buy the new system, the business has to twist its procedures to suit the convenience of a software vendor. Productivity can actually decline!
You will escape these mistakes and others similar to them if you begin by getting a clear understanding of not just how your business does everything now, but what it really needs to do. Like my parents, you need to consider that thoroughly, not just at a surface level. Small details like the characters that are no longer part of English can be essential. Step through what your business does to wire a house, or make and ship rolls of carpet–whatever your business does. Find the bottlenecks. Step through modified versions of the procedure until it satisfies you.
At that point, you can figure out exactly what you want a computer system to do in the revised workflow. Then, and only then, you can look at the hardware and software available, because at last you know what you want it to do. You have made yourself no longer an easy mark for polished sales pitches. Instead, you can evaluate what available systems can do with an eye toward whether it suits the desired new workflow.
You may find, like my parents, that you have a choice between the latest and most fashionable, or an older system with a solid track record that can do the same job at lower cost or higher reliability. (Remember, the newest systems often still need some glitches resolved.) Also like my parents, you may find the market does not have a perfect match, but something you can get "off the shelf" can be tailored to fit well enough without the need for entirely custom software. Put fashion in the back seat. Let your company's real needs drive your choices, and your project can be a great success!
Where to Start if It Has To Be Custom
Not Every Solution is Available Off the Shelf
Now let's say you've done the first step and found that nothing already on the market can do what you need. You'll have to build a custom system. There's no way around it–what you need done by it is mission critical.
Obviously, your next step is to choose the platform and tools to be used for building the system. Chances are that you will not build the whole system yourself. Your technical team will build it–perhaps the team you already have, perhaps a team you bring in to do the project.
Choosing the right foundations and tools are among your most critical decisions. Hardware is probably not your starting point. Just as in the first step, think about what your system must do. Then think about the resources you have for building it.
Strictly speaking, as you decide which trade-offs to make, some of your decisions will not be directly about demands of your project. Some involve the future availability of upgrade paths, spare parts and expertise. Yes, it is easiest to find expertise for the platforms and tools that are most popular right now–but if those tools do not suit your needs, readily available labor will not magically cure shortcomings in the tools.
The Foundation is the Operating System
The foundation for a house may be a concrete slab, piers, bricks… Some people think the foundation for a software system is the hardware it runs on, but software designers and programmers will tell you that the foundation for software is the operating system it runs on. The operating system you choose will narrow the range of hardware and tools you can use. A few options:
- If rebooting once or twice a month to install patches is acceptable, you may want something ubiquitous and comparatively inexpensive like Windows.
- If processing speed and low overhead are important, and you have access to the right technical expertise, you may prefer UNIX.
- If the system must handle enterprise-class communications and data volume for business applications, you may want AS400 on a mainframe.
- If downtime is intolerable, you may need a special disaster-tolerant platform.li>
While you consider, try not to limit your thinking to the newest products. Why? Here are a couple of examples from within a few months of each other in 2001:
When the World Trade Center collapsed, CommerzBank's headquarters were less than a hundred yards away. CommerzBank ran its most essential banking applications on a properly configured OpenVMS wide-area cluster with shadowed (mirrored) disks. In an OpenVMS cluster, multiple computers operate like a single computer. Processing and storage are spread across and shared by the member computers. The bank could lose a data center without a noticeable blip, so it had no interruption in service. With appropriate hardware and communication lines, computers in a cluster can be up to 500 miles apart–great for disaster redundancy.
OpenVMS is roughly 30 years old. It is highly secure. It commonly runs for years between reboots. Many recent computer science graduates have no idea what it is, cannot imagine running five years without rebooting, and have never seen a "more modern" operating system capable of doing what the CommerzBank cluster did.
By contrast, Tropical Storm Allison caused flooding and a fire in Houston, Texas, that killed both the primary and backup power sources for a major electronic funds transfer system. It ran on a more popular, lower cost operating system. Disaster recovery plans were in place and a disaster data center was ready in the Dallas area, but bringing the secondary data center up took days. The outage took down a large percentage of automatic teller machine and point-of-sale service in 22 states.
Now you know why the platform for your new system is terribly important. You also know why you should double check your technical team's recommendations about the operating system, programming language, database engine, and other tools to be used in building your system. Double checking is especially important if your staff is young or has a tightly focused range of experience, because they may not be aware of the best option for your needs.
There are limits to how much anyone can learn in a given period of time, and computing is a vast field. No university can teach its computer science graduates everything about computing. For that matter, even the most experienced top notch computer expert can't know it all, either–but experienced experts have been learning much longer. Independent experts see a wider spectrum of technologies and ways of applying them than people in typical jobs, because independents get to see how more companies and groups approach their projects and how the projects turn out.
Choose Tools that Suit the Operating System and Your Goals
Take as much care choosing the rest of your toolset as you take in choosing the operating system. A programming language may be your next choice.
Object oriented programming languages are great for such things as user interfaces, where the software needs to do work in an unpredictable sequence. Object oriented software tends to have higher overhead than procedural code. If your system needs to run very fast and do its work in predictable sequences, a procedural language would be more efficient and not require as much hardware.
You also must decide how high or low level the language should be. The C language is low level, great if you need software that can directly manage hardware–but if you do not need to be so "close to the hardware," a higher level language costs less to maintain. For well designed, well built software, you can expect about 20% of its lifetime cost to go into creating it. About 80% of the cost is maintenance and enhancement. Using tools that are easier to maintain can save money year after year.
Choose Your Team Carefully Too
You may be wondering whether to use a young team to build your system, or a more experienced team. There are good reasons to want youth on the team, such as energy, creativity, and comfort with some of the latest software tools. In addition, if your team is young when they build the system, you have the potential to keep original expertise on hand for a long time.
But if you can blend youth with experience in your team, you can have the best of both worlds. Experienced team members can keep the project from repeating mistakes that happened in earlier projects.
Doublecheck All Foundation, Toolset and Architecture Choices
Even if you use a blended team, don't skimp on double checking your team's platform recommendations. Your entire system will stand on the platform. It's worth your while to bring in a consultant to look at what you want to do and give you some advice. Even if you don't keep the consultant involved for the whole project, at least the consultant's breadth of knowledge and perspective can help you make sure you're going to use the right foundation.
When you're tempted to skip any of these initial steps, just think about how much a shortcut can cost in the long run. The right decisions now will save you from endless and costly headaches later.
Choosing a Programming Language
As an example of how to make these decisions, take a closer look at some of the factors to consider when choosing the programming language to be used in writing source code for your software.
Languages are Not All the Same
If you are multilingual in spoken and written languages, which of these languages would you choose to write a love poem: French, German, Italian or Dutch? Why?
Similarly, when you think about what you want your software to do, some languages will be obvious misfits and others will be appealing possibilities. Then it's just a matter of deciding among the ones that are appealing. Make a list of the answers to these questions:
- Will the software be doing predictable sequences of work, or unpredictable sequences?
- Must the software squeeze as much performance as it can out of the equipment or network?
- Are specialized interfaces needed between the software and hardware devices (such as device drivers), or between the software and operating system (special hooks to operating system internals)?
- Is the software a small, medium, large or very large application? Is it complex?
- What hardware platforms must the software be able to run on?
- What operating systems must the software be able to run on?
- Is availability of expertise an issue?
There may be additional factors you want to include, but these are enough for most projects. Now it's time to see which languages are the best fit for your needs.
Strengths and Weaknesses
Make a column for each language under consideration. For each language, go down the list of factors and make a checkmark if the language is well suited for it. If you don't personally know the strengths and weaknesses of each language, get help. It's important to fill in your spreadsheet based on factual information, not fads or personal feelings. Here are some general examples of language differences that should jump out at you from the completed spreadsheet.
- Languages that must be compiled and linked to generate an executable program, such as C, C++ or COBOL, make much faster-running software than interpretive languages such as the original BASIC or Java, but must be recompiled and relinked for every target operating system.
- Procedural languages produce relatively fast-running, compact executable programs with low overhead for predictable sequences of work. They are cumbersome for unpredictable sequences of work such as responding to human users in a windowed user interface.
- As mentioned earlier, object oriented programs excel at handling unpredictable sequences of work, but require relatively high overhead, so they tend not to be as fast-running as procedural programs.
- High level languages such as COBOL, FORTRAN are more easily readable by people, are easier to maintain and debug, and are designed to reduce the likelihood of such errors as memory leaks. They are not as flexible as low level languages such as C, so they cannot easily manipulate bits within a byte or directly command hardware.
- Low level languages such as C (procedural) or C++ (object oriented) can work almost as "close to the machine" as a computer's native assembly language, so you can do nearly anything with them. It is perilously easy for programmers to make such mistakes as memory leaks in these languages, and they are difficult to maintain because they are so cryptic.
When you finish filling in your spreadsheet, some languages should have a lot more checkmarks than the others. Those are your finalists. If you are lucky, the finalists might be similarly capable for your project. In that case, you can use the language among your finalists that is most comfortable for you.
Typical Documentation Sets
Documentation is not just for show, and not just for the sake of people who work with a system after people have forgotten the details about how it was built. Putting together the documentation helps organize everyone's thoughts and make sure nothing important is accidentally omitted.
A typical good-sized software project includes the following documents or sets of documents. You may be able to combine some of these, or skip some of them, if your project is small. For example, you may be able to combine all of your requirements into a single requirements document.
- Business Requirements
- Functional Requirements
- Functional Specifications
- High Level Design (architecture, heavily functional with some tech detail, 50,000 foot view)
- Low Level Design (detailed design)
- Test Plan
- Test Design (test cases, tools, etc to execute testing)
- Test Results Report
- As-Built Documentation (often a final update of the Detailed Design)
Most of these documents are linked together by a Requirements Trace Matrix. Every requirement is listed in the matrix. Columns beside the requirements keep track of which sections discuss the requirement in each document, including the tests. By the end of the project, this matrix should be very full. Any requirement that stops getting entries in the matrix–for example, does not appear in detailed low level design–has fallen out of the project and is not getting done. In large projects, you may have additional documents to help you keep track of which people are assigned to do each piece of work, when they are scheduled to finish each piece, and whether they are slipping behind.
An Example of How to Start
Process Improvement Workshop Example
Click here to go to a description of a quick exercise that demonstrated how to figure out what a business needs from its IT systems–and its human procedures.