Business and Systems Analysis

Analyzing various problems the organization may be facing can have multiple forms based on the context in which it is performed. Depending on what is actually the subject of the analysis, the most common naming is business analysis and systems analysis. While the former focuses on elaborating business needs, possibly resulting in solutions composed of both system and non-system components, the latter type of analysis is IT-oriented and produces mainly specifications for developing new or modifying existing systems.

Business analysis outputs do not need to reach the IT department at all - this is what differentiates business analysis from systems analysis.

Differences

The business analyst usually starts with a high-level business problem such as "With the increased volume of orders, payments processing starts to be very slow which causes order delays" and analyzes how the organization needs to change in order to solve it. In other words, BA recommends possible solutions to help the business meet its goals. In the above example, the BA evaluates whether the process itself is inefficient or if it is the payment system that slows everything down. After that, the BA outlines possible solution alternatives and evaluates them with stakeholders. BAs are not usually asked to design integrations between systems, they do not create database models or user interface specifications. More often, they evaluate and improve processes and translates business wishes to solution requirements. They act as a liaison between business stakeholders, such as management or end-users, and the implementation team.

Systems analyst, on the other hand, does not inspect much the business drivers behind the requested system. SA needs to be aware of them and understand them, but the responsibility is to determine the capabilities of the particular system rather than to analyze the missing capabilities of the whole organization. For example, BA found out that from the system performance perspective, the speed of payment processing is fine. The delays are caused by imperfections of the engine, which pairs payments to orders - too many payments are not paired automatically and are left to be processed manually. BA understood the problem, and together with the payment officers, they designed two new pairing rules, which will decrease the number of manual pairings to the half.
These two rules represent the input for the systems analyst. Since the rules are implemented in the payment system, systems analyst takes the rules, analyzes the IT impacts, and prepares the specification in a form which enables developers to implement the change. So even though SA understands the business problem that caused the need to develop the rules, she just accepts the rules as they are and implements them without any deep evaluation.

Business analysis determines how the organization needs to change in order to meet its needs.

Systems analysis determines how the system or the IT architecture needs to change to meet the business goals using IT solutions.

Although there are apparent differences between these two types of analysis, since they mostly overlap, it can't be clearly defined where the business analysis ends and where the systems analysis starts. Sometimes business analysts also do basic systems modeling to verify the outlined solution. Contrary, systems analysts may be required not only to design the system but also to verify whether it really provides value to the organization and whether it supports business goals. Since both analysis types also require analysts to possess very similar skills, they both are often carried out by a single person. For all these reasons, the line separating business analysis and systems analysis is not sharp. But it actually does not matter. Your goal is to deliver a solution and not to meditate if you're doing business or systems analysis. Your only goal is to bring value to the stakeholders.

It gets even more complicated when we look at how organizations call the analysis roles. Although business analysis is a widely adopted term, the particular role performing it is called differently across organizations. The business analyst is simply anybody who performs the business analysis regardless of the role in the company. Therefore, business analysis tasks are carried out by business architects, enterprise analysts, process analysts, product managers, or requirements engineers. Because of the overlap, especially smaller companies do not even create two separate roles, so in these companies, it is very common to see a technical business analyst role who is expected to possess the skills from both worlds.

The more technical analysis roles do not have a unified title either. Throughout the industry, you can come across the following names: systems analyst, IT analyst, IT business analyst, business systems analyst, technical business analyst, applications analyst/specialist. All these roles should be more technical than the business analyst, but as stated above, the name of the role is not really important. What is important are the skills that help analysts to solve business problems.

SYSTEM VS. APPLICATION

What might also be confusing is whether the systems analyst is the same as the applications analyst/specialist. In general, the system is something different than application:

System	Application
A class of software that provides services to other software.	Software that is primarily designed to be used by people.

Although systems can have a user interface, it is the applications that are primarily intended to be used by people. Systems are more complex, serving multiple purposes, providing services to applications and other systems. It is then natural to distinguish between frontend applications which users interact with and backend systems that process data and execute transactions. But for simplicity's sake, let's assume that all the terms are interchangeable.

Typical Responsibilities and Activities

Even though there is no fine line separating business and systems analysis and a lot of activities are shared between them, on both opposite ends, the activities differ:

Examples of business analyst activities:

• Facilitating meetings with stakeholders to understand the business goals
• Describing and analyzing business goals
• Evaluating business processes and proposing changes
• Defining in which systems the business requirements will be realized along with the expected impacts on these systems
• Specifying system features from the user perspective
• Analyzing business rules and algorithms

Business analyst has a deeper knowledge of the business area and business architecture of the organization and helps to achieve its goals, mainly but not exclusively, using IT systems.

Examples of systems analyst activities:

• Facilitating meetings to understand the requirements for the system
• Analyzing and evaluating requested changes to IT systems
• Discussing the system changes with architects to ensure the changes are aligned with the overall IT architecture
• Developing specifications to enable solution implementation
• Overseeing implementation, coordinating tests and evaluating the released solution

Systems analyst has a deeper knowledge of technologies, IT architecture of the company, and architecture of the specific systems. They are also often responsible for technical design, such as defining system components, designing databases, or system interfaces. They do it themselves or in cooperation with systems architects.

Analysis and Agile

Agile software development is a software development approach that prefers a progressive strategy in modeling and implementation of the solutions. It aims to reduce the risk of implementing something which does not provide value by limiting the upfront analysis and design to the lowest extent possible. It produces only the minimum amount of artifacts that are necessary for the implementation and produces it just in time it is needed, moving the specification phase as close to the development as possible. It is typical for agile to put a lot of focus on collaboration between the development team and the stakeholders, and it tends to use lightweight analysis and modeling techniques that are easy to use. We suggest you read about agile, for example, on Wikipedia and also get familiar with the Agile Manifesto.

In the traditional software development process, analysis is a phase in the project lifecycle, typically being performed at the beginning of the project. After the project kick-off, somebody goes ask stakeholders what they want to solve, selects a solution, design it, and hands it over to developers who implement it according to the specification:

There are two issues associated with this traditional "waterfall" approach. First, in most cases, several requirements have already changed before the specification is completed, implying more or less specification rework. Second, it is impossible to describe the whole solution upfront, so as a result, stakeholders will start coming with new requirements and modifications right after they see the first version of the solution. Prototyping could help a bit, however, if the prototype does not become a part of the final solution, it was a waste of time. For these reasons, agile analysis is not a phase or a task. In agile, analysis is incremental, meaning that the whole solution does not need to be analyzed in one go, but is instead specified in small chunks which are implemented very soon after that. It is also highly iterative. The high-level analysis is not separated from the low-level system design, but instead, these activities rely on each other. High-level requirements serve as input for the system design, but the design decisions and constraints may back influence the requirements. In combination with using lightweight techniques such as whiteboard sketches or simple, informal diagrams instead of formal models and specifications, together with putting emphasis on collaboration and personal communication instead of producing tons of documents, agile analysis is a modern, effective, and highly recommended approach.

Agile also changes the traditional way of structuring implementation teams. Traditional teams include highly specialized roles such as analysts, developers, testers, or project managers. Agile, on the other hand, even though it is still a somewhat utopian idea, especially in big corporations, prefers to compose the teams of crossed-skilled people, usually referred to as T-shaped people. Such people are then able to analyze the business needs, read or even write the code, test it, and also present and verify the solution with the stakeholders. No doubt such a team of supermen is the most effective possible, they are also costly and rare. This topic is out of the scope of the Effective Analysis and Documentation, yet we would like to elaborate on that issue a bit in the next section.

Dedicated Analyst

Having the team of T-shaped people who have the skills no only to develop the solution but also to manage requirements, brought agilists to an idea no to have a specialized analyst role at all. Or in other words, all team members are analysts in some way. Although this may surely work on certain projects, it would be dangerous to widely adopt this practice. At first sight, it makes a very good sense, because the broader set of skills the people have, the less information hand-over is needed and the team members can mutually back up themselves. It is indisputable that having such individuals in a team is a great benefit. Having a team composed of individuals who have the business knowledge, can define business needs, transform it into the technical specification, and can also write code is a dream. People who can suit up and facilitate meetings with the top management, understand their goals, propose a solution, and also describe the solution in the form which is implementable, are immensely valuable. There is then less documentation hand-over, and the whole development process is less error-prone and more effective.

So far, so good. But in reality, it is not that easy. Gaining all necessary T-skills requires a lot of effort, and only really dedicated people could achieve this level of seniority. It takes time to become a professional and skilled analyst, and only a few people could be rock star analysts who, at the same time, could work with code. People simply cannot be top-notch in all areas, so with generalizing specialists, there is always a risk they will be "all and nothing."
It is definitely a plus when the systems analyst who understands the systems also has knowledge of the business domain and the business needs. Only then could they validate whether their solutions are aligned with the business goals and whether they provide value to stakeholders. It analogously applies to business analysts. Becoming a great business analyst requires a lot of experience and a lot of training, both in terms of hard skills and soft skills. Business analyst with the polished facilitation, presentation, and negotiation skills, knowing all company products, business processes, and decision-makers, will never be able to understand complex SQL queries and technical details of the core systems. Whatsmore, in big enterprises, the amount of information is so significant that it is simply not possible for one person to understand the complex business domain and also be able to understand the IT architecture, let alone the design of each system. On the other hand, it is definitely necessary for business analysts to be up to date with current technologies, be aware of fundamental architectural concepts, and have knowledge of software engineering in general. It helps them foresee technological problems right in the early stages of the project, make better decisions, and also they are more respected in the development team.
We would really like to always work with the best T-shaped people. Still, it is, and always will be, a sci-fi to think that an IT guy in a big corporation commits the source code modifications, changes his Linux t-shirt for a well-fitted shirt and goes analyze a huge regulatory requirement. They simply don't have the right skills, and they actually don't need to have them. Most developers just enjoy coding, they are good at it, and they don't give a damn about talking to business people.

Prefer systems analyst with both knowledge of business and strong technological background.

Prefer business analysts who are subject matter experts at the given domain and who can come up with the solutions which not only bring value to stakeholders but are also efficient and verified from an IT point of view.

To sum it up, go for agile, prefer T-shaped people, but considering the amount of knowledge and skills analysts need to know in combination with more and more complex business domains, we are not likely to see dedicated analysts to disappear. It will more likely be the opposite.

Conclusion

There are two different types of analytical activities on the way from the business problem definition to the implementation of the final solution, requiring different skills, techniques, and tools. Although it is essential to know them and understand the differences, don't waste time meditating which one of them you are actually performing and what your job title should be. Until you write the source code, it is an analysis, and it just depends on the perspective. What you just need to know is, what activities you are supposed to perform, what qualities you need to possess, and what outputs you are expected to deliver. For these reasons, we are going to use the term analysis for business analysis and systems analysis & design.