Interface Analysis

When a project is intended to provide a technical solution, it frequently will need to interface or communicate with existing systems. Very few business systems operate in a vacuum. Interface analysis is a technique for identifying interfaces that may impact or be impacted by the current project and planning the changes necessary to smoothly integrate the new solution into the existing environment. Identifying existing interfaces also helps to identify stakeholders that use and support those interfaces. They will be important subject matter experts as you work to design the changes. Ideally, interface analysis will be done using system documentation and procedural manuals, but if these documents are not up to date, traditional requirements elicitation and analysis must be used. When the existing system involves software, you may want to use reverse engineering tools to derive a logical understanding from the actual program code.

Learn the current (as is) system

A very common question among BAs at the beginning of a project is: “Should I learn and document the current business procedures before I start looking for a solution to the problem?” This is an excellent question that should be part of the business analysis planning work (see Chapter 7) on every project. The answer is not simple or straightforward and will differ depending on the project characteristics.

First, the BA must understand the business area in detail before even thinking about making any solution recommendations. One of the worst mistakes that a BA can make is to tell a stakeholder how to fix a problem when he or she doesn’t really understand it. The stakeholder will be annoyed and lose faith in the BA. Think of how you would feel when you have been struggling with a technical problem for several hours and the person at the help desk suggests that you reboot the computer. You tried that in the first five minutes and know that it won’t help!

Do whatever you need to understand the business as quickly as possible. If that means drawing workflow diagrams of current procedures, draw them. The diagrams may be rough, handwritten drafts, just enough to aid in learning and to generate follow-up questions. If you learn through understanding information or data, sketch a data model. If the business area has complex rules, make a list of business rules. The document/diagrams are the means to an end— your understanding. Once you truly understand the current environment, these notes may simply be filed away. Remember that the business system is more than just the software. Sometimes an analysis of the existing software is needed. This is referred to as reverse engineering.

A second consideration is whether anyone other than the BA needs to understand the current procedures. If the answer is yes, then you need to produce some professional deliverables from this activity and plan carefully around what those deliverables should be. See Chapter 6 for suggestions on deliverables.

There are several reasons why a project team might decide to formally document the current or as is business system:

• Having a clear definition of the old procedure along with the new will help the organizational change specialists understand the extent of the change and its ramifications.

• It highlights processes that need further analysis by identifying gaps and problems.

• A clear solution has not yet been identified, so alternative solutions will be compared to the current state.

• During an interim period, the old system may continue to be used in conjunction with the new.

When you have the opportunity to brainstorm on possible solutions and make recommendations, be sure that you completely understand: (1) the core business requirements and (2) the current how—the system and procedures currently used to accomplish the work (see Chapter 6 for the core requirements components). Understanding the core business needs independent of how they are currently performed allows for creativity in solution brainstorming. Understanding the current procedures prevents you from redesigning the same system.

On the other hand, there are some analysts who are strongly against learning the current system. There is a concern that once you understand the current system, you will be unable to creatively design an excellent system.