Database Designer/Administrator

A database designer is responsible for determining where data should be physically stored, how it will be accessed, how it will be protected, who will have access to it, and where it will be used. These are critical decisions for an organization that have long-term effects on the efficiency and quality of information systems. Database designers and database administrators also maintain these data stores for the life of their use. They maintain backup procedures and disaster recovery procedures; they correct problems with the data values when errors are introduced.

When a project involves creation or storage of new information, the database administrator must be involved. Even if you are going to use existing data in a new way, it is a good idea to discuss this new usage with the database team. Creation of and access to data can have huge performance impacts for software users, and providing inaccurate data from a software application is the quickest way to sabotage trust in your work. Make friends with the database administrator, and check with him or her even when you think you don’t need to. As with all stakeholders, when you establish a good relationship, always act ethically, and keep the database administrator informed, you will have a valuable ally when you need one.

Vendor

A vendor is a company from which services or products are purchased. There is typically a contract relationship between the purchasing organization and the vendor organization. There are many types of vendors with which a BA may work on a project. A company that sells and supports application development software is the most common one. Examples include SAP, PeopleSoft, and Siebel™. Other vendors may be hardware vendors, consulting services companies, and outsourcing vendors.

Figure 2.2 shows the typical life cycle of a vendor relationship. As a BA, you may be involved from the beginning of this relationship or may be brought in at any point. Chapter 3 will discuss software package implementation projects and Requests for Proposal (RFPs) in more detail.

Figure 2.2: Vendor Relationship Life Cycle

There are a few key points in this life cycle where a BA can add great value: at the beginning (sales, demos), during creation of an RFP, and in reviewing the responses to an RFP. A skilled BA will help the organization select the best solution available and will expose the gaps that will occur with any package solution.

Sales people and marketing people are very good at their jobs—and no more so than in software companies. They have outstanding descriptions of the wonders of their software and describe how it will make your company more successful and your workload lighter. The demonstrations are slick and polished and make the software appear easy to customize and easy to use.

All of these wonderful claims play right into the frustrations of users and their management. Everyone wants to believe that if the company just buys this software package, all of the problems will be solved! But BAs know that there are no magic wands.

In truth, buying and implementing software does not guarantee a better chance of success than developing an application internally. There are different issues and challenges, but they are no less critical than the issues that arise during development. The experienced BA is aware that just because software is purchased doesn’t necessarily mean that:

• It will be up and running faster

• It will cost less money than developing an application internally

• It will support the business better than a home-grown application

These three fundamental assumptions are the driving forces in decisions to buy software rather than write it. These three fundamental assumptions are often wrong, and the person who can best evaluate them is the BA. Evaluate these assumptions by eliciting and understanding the business requirements, brainstorm for possible solutions, and work with the solution team to estimate cost/time. Go back to the project objectives and assess how well they would be met. Only when you have thoroughly analyzed the business and the solution options will you be able to assess the viability of a package and estimate its true value.

In terms of relationships with representatives of the vendor, treat them with the same respect as other stakeholders. Be aware, however, that it is not in their best interest to be entirely truthful with you. They will emphasize the positives, minimize the negatives (often called “features” by the vendor), and gloss over any unanswered questions that you have asked. This difficulty in really understanding what you are buying is handled well with a formal RFP process. The RFP requires the vendor to document, in writing, what it will provide. Careful development of RFPs and careful review of vendor responses is the best approach to rendering a fair and unbiased verdict on the purchase decision.