State of the Analysis

Analysis as a standalone discipline is a rather new concept. Even though all systems developed in the last decades had to be first analyzed, in the early days of software engineering, it was mostly developers who asked stakeholders what solution they needed, and then they built it. A dedicated analyst role did not exist at that time. This used to be possible because the systems were not nearly as complex as they are today, and they used to solve way more simple problems. Writing a small application in a team of five did not require special skills.
However, today's systems are complex, integrated with each other, implementing complex workflows and business processes. It is no longer possible to stop coding, ask stakeholders, "What do you want us to build?", go back and develop it. Nowadays, the question should always be, "What do you want to achieve in your business?". Only after knowing the goals, can we decide which solution would best meet the business needs.

An analysis is no longer just about software, and analysts now have more responsibilities than to listen to what the stakeholders want and give it to them. The business-oriented analysts became drivers of the change in the organization, who help stakeholders understand their problems and to see them from different points of view. Analysts can connect the dots and understand the business constraints while continually evaluating the technical limitations as well. Analysis evolved to its own discipline, it became a complex activity which could no longer be done ad hoc without applying any rules and best practices.

More Art Than Science

Computer system analysis is like child-rearing; you can do grievous damage, but you cannot ensure success.

-- Tom DeMarco

Software development is a science. Systems and applications are built using formal languages, the produced code is based on the fixed requirements, and most parts of the development are automated. Analysis, on the other hand, is more like a combination of investigation and writing a novel. Analysts spent a significant amount of time eliciting the needs, designing the solution, and trying to describe it in a form that they believe is the best for the given audience. What they often end up with, though, is something they cannot be sure it is what stakeholders really need. Besides, it is typically defined in the form which is not standardized and prone to ambiguities. Analysis is more art than a science.

Unlike development, it is not possible to standardize the process of analysis. Each analysis is different and therefore producing different outputs. An analysis is like a forest exploration, and since we usually do not know upfront what to expect in the woods, it is not possible to plan the journey through it. What could be done, though, is to standardize the outputs and terminology and put some ground rules in place so that the common parts of the analysis are done the same way no matter the process. For example, everybody should understand that describing user interface is better done visually rather than in natural language or that different levels of analysis must be interconnected so that it is possible to quickly discover dependencies.
It is exactly what Effective Analysis aims to. One of the key goals is to outline the basic principles and practices, which contribute to increasing the efficiency of the analysis efforts and improving the quality of the analysis and documentation outputs.

Skills Matter

With the increasing complexity of the systems, analysis is gaining more and more importance. Although the scope of analysis work varies from organization to organization and from project to project, analysts generally need to possess a lot of different skills, which include business skills, IT skills, and a wide range of soft skills. Business analysts must have a good knowledge of the subject matter, must be good leaders and negotiators, yet to have a solid IT background. Systems analysts, on the other hand, sometimes do a bit of IT architecture, database architecture, they sometimes even code, and at the same time, they must understand the business domain. On top of that, both analysis roles have to know basic modeling to describe things which are not suitable to be described in the text and also have to be good managers to manage the analysis and to help the project manager to manage the project scope. Analysts are a keystone to bridge all the pieces of software engineering to ensure success.

It is evident, there are a lot of skills an analyst should possess, from requirements elicitation and meeting facilitation through systems modeling to the knowledge of technologies. Gaining these skills is a long process, requiring a lot of motivation to learn and willingness to improve. It is not very common to see an analyst who does not have strong soft skills, such as presentation, negotiation, or facilitation skills, since these skills usually come with time, just by using them. For example, the more presentation analyst gives, the better each presentation will be. However, the hard skills such as modeling or requirements management can be gained only by studying or learning from somebody who already has the skill. Unfortunately, we see very little pressure being put on analyst regarding the hard skills. An analysis is still by many considered a discipline requiring just the soft skills, which is not sufficient for doing the job properly. We have seen many talented analysts who knew the domain, have been able to communicate effectively, but the lack of hard analysis skills have limited them to deliver quality results.

The Motivation to Improve

So why is it that so many analysts still think their job is to understand the business, ask stakeholders what they want, and transcript it to a 5-A4 page-long "analysis"?

1. Many analysts were recruited from either non-IT people or oppositely from developers so without proper training they do not even know what skills they should have and what techniques they should use
2. The number of analysis techniques is high (process models, requirements engineering, UML, use cases, screen descriptions, etc.), so an average analyst does not have a chance to use all of them daily and train them. This is why Effective Analysis focuses only on essentials techniques and the most critical aspects of each of them as the details are not required in real life anyway.
3. There is a significant amount of resources demonstrating the techniques, but they usually show just the abstract concepts without the context. For example, there are thousands of tutorials describing what the use cases are and how to use them. Yet, very few also show how they fit into the overall analysis, how to convert them into actual designs, and link them to implementation details.
4. Most analysts do not work on improving their skills
   While developers constantly study to keep pace with the trends, they attend meetups or webinars, there are actually not many analysts who do the same. Developers share the knowledge, they create best practices and improve the way the software is produced. We miss this in the analysis area. Many analysts still use word processors to write specifications and attach spreadsheets with requirements to it.

The Motivation to Improve

Developers realized decades ago, it is not possible to build complex systems without guidelines, rules, and automation. They use sophisticated editors to write and check the code, version control systems to store the code, advanced frameworks to structure the code, and they automate as much as possible. Hence, it is a common practice to compile, assemble, and deploy the software with just one click. Analysis, in comparison to this world, still reminds the stone age. Analysts very often use bullet points to describe complex processes, the tooling frequently does not go beyond Visio for drawing artifacts, and the diagrams are copy-pasted into Word document and subsequently sent out to stakeholders via email for review. This can be compared to developers writing internet banking in Notepad and compiling the source code using a command line.

The Effective analysis aims to fill the gaps, summarize basic principles, and provide analysts with tools and techniques which are necessary to do the job correctly. Although analysis is a creative task that cannot be unified and measured, we believe that by following proven principles and practices which are thoughtfully adapted and scaled, it could make a big difference in terms of analysis effectivity. It could be even better when it is supported by automating the routine tasks.