State of the Analysis

Analysis as a standalone discipline is a relatively new concept. Even though all systems developed in recent decades had to be analyzed first, in the early days of software engineering, it was mostly developers who asked stakeholders what solution they needed and then built it. A dedicated analyst role did not exist at that time. This was feasible because systems were nowhere near as complex as they are today, and they solved much simpler problems. Writing a small application with a team of five did not require specialized analytical skills.
However, today's systems are highly complex, deeply integrated, and responsible for executing intricate workflows and business processes. It is no longer viable to stop coding, ask stakeholders, "What do you want us to build?", and then go back to develop it. Nowadays, the question should always be, "What do you want to achieve in your business?". Only after understanding these goals can we determine which solution will best meet the business needs.

Analysis is no longer just about software, and analysts now have far greater responsibilities than merely listening to what stakeholders want and delivering it. Business-oriented analysts have become drivers of organizational change, helping stakeholders understand their problems and view them from different perspectives. Analysts can connect the dots, understanding business constraints while continually evaluating technical limitations as well. Analysis has evolved into its own discipline—a complex activity that can no longer be done ad hoc without applying clear 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 fixed requirements, and most parts of the development pipeline are automated. Analysis, on the other hand, is more akin to a combination of investigation and novel writing. Analysts spend a significant amount of time eliciting needs, designing solutions, and trying to describe them in a format they believe is best for their given audience. What they often end up with, however, is something they cannot be entirely sure matches what stakeholders truly need. Furthermore, it is typically defined in a non-standardized format that is prone to ambiguities. Analysis is more of an art than a science.

Unlike development, it is not possible to standardize the process of analysis. Each analysis is unique and therefore produces different outputs. Analysis is like exploring a forest; since we usually do not know what to expect in the woods upfront, it is impossible to plan the exact journey through it. What can be done, however, is to standardize the outputs and terminology, and establish ground rules so that common parts of the analysis are executed consistently regardless of the overall process. For example, everyone should recognize that describing a user interface is better done visually rather than in natural language, or that different levels of analysis must be interconnected to quickly discover dependencies.
This is precisely what Effective Analysis aims to achieve. One of its key goals is to outline the fundamental principles and practices that increase the efficiency of analytical efforts and improve the quality of documentation outputs.

Skills Matter

With the increasing complexity of modern systems, analysis is gaining critical importance. Although the scope of analytical work varies from organization to organization and project to project, analysts generally need to possess a diverse set of skills, including business acumen, technical knowledge, and a wide range of soft skills. Business analysts must have a deep understanding of the subject matter and be strong leaders and negotiators, while still maintaining a solid IT background. Systems analysts, on the other hand, often dive into IT architecture, database design, and occasionally even coding, while simultaneously needing to understand the business domain. On top of that, both roles must master basic modeling to describe concepts that are not suited for plain text, and they must be proficient enough to manage the analytical scope, helping the project manager control the overall project boundaries. Analysts are the keystone bridging the various pieces of software engineering to ensure success.

Evidently, there are numerous skills an analyst should possess, ranging from requirements elicitation and meeting facilitation to systems modeling and technical proficiency. Gaining these skills is a long-term process that requires strong motivation to learn and a willingness to improve. It is rare to see an analyst who lacks strong soft skills—such as presentation, negotiation, or facilitation—since these naturally develop over time through regular practice. For instance, the more presentations an analyst delivers, the better each presentation becomes. However, hard skills like modeling or requirements management can only be acquired through structured study or mentoring from an experienced practitioner. Unfortunately, very little pressure is typically placed on analysts regarding these hard skills. Analysis is still widely considered a discipline that requires only soft skills, which is simply insufficient for doing the job properly. We have seen many talented analysts who understood the domain and communicated effectively, but were severely limited in delivering quality results due to a lack of hard analytical skills.

The Motivation to Improve

So why is it that so many analysts still believe their job is merely to understand the business, ask stakeholders what they want, and transcribe it into a five-page document labeled "analysis"?

1. Many analysts are recruited either from non-IT backgrounds or, conversely, directly from development teams; without proper training, they often do not know which skills they should develop or which techniques to apply.
2. The sheer number of analytical techniques is overwhelming (process models, requirements engineering, UML, use cases, UI descriptions, etc.), meaning the average analyst rarely has the chance to use and refine all of them daily. This is why Effective Analysis focuses exclusively on essential techniques and their most critical aspects, as exhaustive details are rarely required in practice anyway.
3. While there is a vast amount of resources demonstrating these techniques, they usually showcase abstract concepts completely isolated from context. For example, thousands of tutorials describe what use cases are and how to write them. Yet, very few demonstrate how they fit into the broader analysis, how to convert them into actual designs, or how to link them to implementation details.
4. Most analysts do not actively work on improving their hard skills.
   While developers constantly study to keep pace with industry trends, attend meetups, and participate in webinars, very few analysts do the same. Developers actively share knowledge, establish best practices, and continuously improve how software is produced. This drive is sorely missing in the analytical space. Many analysts still rely on basic word processors to write specifications and attach disjointed spreadsheets for requirements tracking.

The Tooling Gap

Developers realized decades ago that it is impossible to build complex systems without guidelines, rules, and automation. They use sophisticated editors to write and validate code, version control systems to store it, advanced frameworks to structure it, and they automate as much of the pipeline as possible. Consequently, compiling, testing, and deploying software with a single click has become standard practice. Compared to this world, the state of analysis often feels like the Stone Age. Analysts frequently rely on plain bullet points to describe highly complex processes, their tooling rarely extends beyond Visio for drawing artifacts, and diagrams are routinely copy-pasted into Word documents to be emailed to stakeholders for review. This is the equivalent of a developer writing an internet banking application in Notepad and compiling the source code via the command line.

Effective Analysis aims to bridge these gaps, summarize foundational principles, and provide analysts with the exact tools and techniques required to do the job right. Although analysis remains a creative task that cannot be rigidly unified or measured, following proven, thoughtfully scaled principles and practices can fundamentally transform analytical efficiency. This impact is amplified even further when routine tasks are supported by automation.