What does a business analyst need to know about technology?

There are some fundamentals of technology that every business analysis professional must understand. Regardless of your background, keep learning more; keep asking questions. You must have a high-level understanding of how things work in order to be an effective analyst. The better your understanding, the more likely you are to make excellent suggestions for changes and improvements.

Areas/terminology with which you should be familiar include:

• Software development/programming terminology

• Software development methodologies

• Technical architecture

• Operating systems

• Computer networking

• Data management

• Software usability/human interface design

• Software testing

Software Development/Programming Terminology

Know your developer’s programming language

Does a Business Analyst Need to Know How to Develop Software?

At one of the first industry conferences for business analysis professionals, held in 2005, Business Analyst World™, a speaker listed programming as a skill needed by the BA. This caused quite a stir at the conference as BAs were asking each other, “Do you think that we need to know how to program?”

Many industry experts quickly said no, but the answer is not that simple. In the current business environment, can you think of any business today that is not utilizing technology? Many business activities are supported by technology, so a BA must have more than a superficial understanding of what technology can do and how it is built. Without some fundamental understanding of programming, a BA will have a difficult time communicating with his or her IT team members and may miss excellent solutions to business problems.

While writing The Guide to the Business Analysis Body of Knowledge® (BABOK®) for the International Institute of Business Analysis (IIBA™), the committee listed technical awareness as a core BA competency. There was unanimous agreement that BAs need to know something about technology to be effective. But how much? BAs who have not worked in a technology area should use this chapter as a guide to continuing education for career development. You don’t have to be a “programmer,” but you should have a high-level understanding of what programmers do and why they do it.

To help you understand the complexity of the work involved with programming or coding, think of the analogy of writing a series of documents that must fit together to form a cohesive package (e.g., a book with chapters or a requirements package with sections), as illustrated in Table 5.1.

Table 5.1: Comparison of Writing Software to Writing a Document
Writing a Series of Documents	Writing a Software System
The entire document cannot be written in one sitting. It takes many hours to write and revise.	A developer cannot write a whole system in one sitting.
When you change a concept or term in one place, you have to go back and review the entire document for inconsistencies.	When a developer changes the definition of a data field, it may need to be changed in several places.
Making sure that each chapter or section leads to the next requires complex integration.	Integrating complex object components can be very difficult.
As the author, it is difficult to see grammatical errors in your own writing.	Developers have a tough time finding defects in their own code.
Even after many reviews, there are often “bugs” (typos, grammar errors, inconsistencies).	Even after extensive testing, software often con-tains defects.
Readers will not recognize the diligence required to put a document together.	Users often do not appreciate the complexity of their requests.

Thinking about this analogy helps to understand why a developer’s product is not correct the first time or even the second time. It also helps us to understand why it takes so long to complete a deliverable. If you have never written or reviewed any program code, ask a developer to show you one of his or her programs for a specific business feature that you understand. Ask the developer to walk through each line of code and explain its function and relationship to the rest of the software. You will only have to listen for a short time to get a quick understanding of how complex software development is. You will probably be overwhelmed and want to get away from this code as soon as possible! This will re-enforce the reasons why requirements must be detailed. Programming languages and software systems do not assume anything or do anything automatically. If you want a field on the screen to be highlighted when the user forgets to fill it in, the developer has to write several lines of code to tell the screen to display a highlight. When the user enters the information on the screen, the developer has to write code to tell the screen to turn off the highlight. Every single action that a user wants must be coded exactly. How can developers do all of this detailed work when they are not given clear direction about what is needed? It is the BA’s role to communicate this direction with an appropriate deliverable like a use case.

The most important work of the BA is communication. If you can’t talk with a developer in his or her language, he or she may discount your value, and this will undermine your creditability. If you worked in the construction industry, you would have some understanding of how things are built; take the same approach with IT.

Take time to learn if your developer is working with a procedural language like COBOL or an object-oriented language. Learn object-oriented terms like encapsulation, inheritance, and abstraction. When you hear a term that you don’t know, find a high-level definition. Find out if your organization has programming standards, screen design standards, and other governance policies to which your developer must adhere. These standards impact the developer’s time to complete work, which should be factored into project time estimates.