Data Analysis & Modeling

Today many business analysts are creating business-oriented decision models. These decision models contain business logic for operational decisions that operate within business processes. And, it is no surprise that data quality is critical to business-oriented decision models. After all, good decision models operating with bad data are no better than bad decision models operating with good data. The surprise is: not only are decision models a preferred way for managing true business logic but they are remarkably suitable for managing data quality logic!

A data flow diagram (commonly abbreviated to DFD) shows what information is needed within a process, where it is stored, and how it moves through a system to accomplish an objective. As its name implies, a data flow diagram depicts the flow of data within a system.

At some stage in their working life, every business analyst will have some involvement with data modelling. They may need to model how data is (or will be) used or - if they only deal with requirements investigation - then someone else in the team will need to verify that the data to support new functions will be available.

 The Data Flow Diagram (DFD) provides a graphical representation of the flow of data through a system. It shows logically what information is exchanged by our system processes and external interfaces or data stores, but it does not explicitly show when or in what sequence the information is exchanged.

This article is all about putting your systems analysis into context; literally and metaphorically. It’s all about drawing and interpreting the not-quite-UML Context Diagram that is sometimes referred to as the System Context Diagram.

Transaction Business Logic is the processing required in processing database transactions to enforce business policies. It is sometimes characterized as Enforcement logic, since the transaction should be rejected if the rules are not passed. Consider the insertion of a new Purchase Order...

In this article, I explain a project completed in the financial services industry. A client asked me to lead a project to redesign a failed sub-process that had resulted in billions of dollars of backed up financial transactions. This particular financial process had a history of failed and abandoned process improvement projects. The pressure was on and, I must confess, I was not entirely sure that The Decision Model would be a good fit.

You are experiencing success with decision models even without the assistance of decision modeling software. Imagine the possibilities with proper software support!

Business requirements are usually captured in narratives and graphics that, regardless of how detailed, structured, cross-referenced and validated, are fundamentally imprecise. A data-driven approach to specifications has the potential to help avoid these problems and subsequently decrease the risk and increase the return on companies' IT investments.

Almost every business analyst uses diagramming software in their arsenal of analysis tools. According to BABOK 2.0, an analyst’s traditional purpose in using diagramming tools is to “support the rapid drawing and documentation of a model, typically by providing a set of templates for a particular notation which are used to develop diagrams based on it.” Diagrams not only make requirements clearer to stakeholders through modeling, they help clarify an analyst’s thinking on a project through the process of their very creation.

While most business analyst roles don't explicitly require static modeling expertise, developing a better understanding of static modeling concepts can be a measurable forward step for business analysts seeking to develop new competencies. Such skills can be useful in many aspects of the BA work, from obtaining a better understanding of stakeholders' information needs, to documenting those needs in unambiguous ways and communicating them more effectively to the technical team.

It is no surprise that organizations spend over $15B annually on business intelligence and data mining technologies. But despite this focus on infrastructure technologies, there is little emphasis on the art of analysis.

Analysts are being asked to assimilate increasing amounts of data into meaningful information that can be acted upon quickly. This is a daunting task as the volume of data that comes into play is staggering and crippling to most analytic tools. This article discusses three innovations in data analysis that empower analysts to explore expansive data sets and gain actionable intelligence.

Business rules should be externalized from processes and established as a separate resource. Rule Independence permits direct management of the business rules, so they can evolve at their own natural pace rather than that of the software release cycle. Other benefits include better process models, and much closer tie-in to the business side (a.k.a. business alignment). Business rules put your company on the road to true agility.

Like all professions, business analysis has its golden rules – rules that are fundamental to the design of successful business systems. They might seem like common sense but it’s surprising how often we forget them and get ourselves into hot water.

When ModernAnalyst asked me to propose an article for their issue on Enterprise Architecture, I thought about the question framework developed by John Zachman, that provides the basic building blocks of that practice.  The primary function of a Business Analyst is to ask questions that uncover requirements then to document those requirements so they may be developed into a useful, useable system.