Operating Systems

BAs need to be involved in infrastructure changes to assess user impacts

An operating system manages computer resources and provides applications with an interface to access those resources. A BA needs to be aware of the operating systems used in his or her organization. Common operating systems are Microsoft Windows®, Linux, Mac OS X®, and Solaris. This knowledge is important on projects where the operating system becomes part of the requirements. For example, when searching for packaged software applications (commercial off-the-shelf), the vendor response to a Request for Proposal must specify the operating system(s) on which the package runs.

Operating systems are occasionally changed or upgraded. Operating system changes are usually prompted by the increased functionality available in the new version. These changes are often implemented in a project referred to as an infrastructure project. Infrastructure projects implement changes to the underlying IT architecture to improve system characteristics like performance, security, or reliability. Ideally, the infrastructure changes are transparent to the business users, and because of this assumption, business analysis professionals are often not assigned to these projects. This is unfortunate because many times infrastructure changes do impact end users. A simple change like a new system menu impacts business workers and should be communicated before the change is made. Encourage your management to include business analysis in all infrastructure projects. A BA is the best person to assess the impact of a change on the business community. The BA can communicate changes to the business and prepare users for any possible issues.

Case in Point

As a project manager on a vendor-supplied commercial off-the-shelf upgrade project, I faced an operating system issue. The version of the application that was currently in production ran on Microsoft Windows, and the newer version was available to run on Windows or IBM’s Operating System/2 (OS/2). The IT manager had decided that we should use the OS/2 version because it was reported to be faster and more reliable. When I joined the project, which was already under way, the focus of the analysis effort was on the updated functionality. We knew that many new features would be available to business users and were documenting and testing those changes. The operating system change had not been analyzed or evaluated. We were conducting tests on the Windows version of the software.

As I began documenting the project and business risks, I learned that this organization did not have any current applications using OS/2. We needed to add tasks to the project plan to include purchasing a new server, purchasing the OS/2 software, and training an IT support person to maintain this system. I listed this as a risk since the company had no prior experience with this operating system. I suggested we order the new server and software immediately and begin testing in this environment. I knew from prior experience that even though a vendor tells you that an application works exactly the same way on both operating systems, there are often subtle differences. As we began the research into what type and brand of hardware were needed, we began to learn that OS/2 had specific requirements and some limitations. Research also prompted us to investigate the cost of all of the new equipment. If we decided to stay with the Windows platform, we could use the existing server and avoid significant costs. Once we put together all of the facts along with the risks of maintaining another IT architecture, we reversed the decision and stayed with the Windows version.