An Organization’s Informal Standards

It is more likely that an organization does not use a formal methodology. An organization may have one, and may profess to use it, but if it is frequently ignored, then it virtually does not exist.

In the absence of a formal methodology, the BA should examine the informal standards and processes that have developed inside the organization and consider them when planning his or her analysis work. Many informal standards and processes are very successful because they have been developed over time by trial and error.

If you take an informal survey of stakeholders about their previous experiences with requirements, you will hear things like: “That thing John wrote was unbelievable. It was 100 pages long and he expected us to read every word!” or “Mary didn’t make us look at anything from her last project, but then the screen didn’t really work the way we needed it to. Hmm—maybe we should have looked at it.” or “That consultant who was here last year—what was his name—Kevin? He drew a really great flowchart of our whole process and then highlighted in red the areas that were going to change. We all really liked that. I still have it tacked to my office wall!” These types of statements, while ignored by 99% of the corporate population, are like gold to the BA. They hold clues to what the stake-holders liked and what they didn’t. Success breeds success, so if Kevin was successful, take advantage of his technique and use it. You might even tell the subject matter experts: “I learned this technique from Kevin and he said that it worked well.” Don’t be shy about giving credit and using other people’s ideas. The whole point here is excellent communication. BAs need to communicate in the most efficient way possible.

Technical Architecture

Know your organization’s standards and basic architecture

There are many components that make up a software system. The foundation of the computer system is often referred to as architecture. This is a great way to describe the design and construction of a system because people can visualize a building’s architecture. A BA does not need to understand every possible component or architecture that is available. He or she needs to understand that software is made up of a group of objects or components that work together to accomplish a goal. These components may be built by an internal development team, built by an outsourced team, purchased or acquired and used as is, customized, rented or leased, or accessed remotely. The interconnection between these components is much of what makes a software system so complex. Each component interfaces with others and expects the others to perform. Many of the components are very small and on their own do not appear to do anything or have any purpose. When combined with other components, however, they provide powerful functionality. The advent of more and more independent, reusable components makes software development faster. Developers can use pieces of code from various sources and combine them into a new, working product. A simple analogy would be the inventory of a hardware store. Each customer who shops at the store may buy a different combination of parts, lumber, and fasteners and go home to build a completely different product. There are an infinite number of products that can be built with the components that are available.

One of the important things to understand about software architecture is that there is no one common design. Each organization’s technical architecture has evolved over the organization’s history and is unique. Often, there are many different brands and versions of hardware, networking software, operating systems, communication systems, and packages all running simultaneously to support the organization’s goals. BAs should consult with IT architects at the beginning of their projects to discuss the feasibility of solution options. BAs who are aware of the complex web of old and new technical components will make more intelligent recommendations and more clearly communicate the possible ramifications of changes to their business stakeholders.

Business stakeholders use software applications. A software application is a software system that supports a particular business area or function. Common examples are enterprise resource planning (ERP), customer relationship management (CRM), and general ledger. When you are learning about an application, your first questions should focus on when and where the application was designed. Knowing the operating system on which it runs, the language used to develop it, etc. will give you valuable information about how difficult it will be to change or interface with. Software systems have lasted much longer than anyone anticipated, so in a large organization it is not unusual to find an application that is 20 years old running next to an application that is 5 years old and another that is brand new. This collection of different architectures makes IT maintenance an expensive and time-consuming function in many companies. Most IT organizations have an architectural “road map” which describes their long-term strategy for building and maintaining software. Learn as much as you can about this plan, and work to incorporate all of your projects into the plan.