Data Analysis & Modeling

This is a complete example of a Business/Systems Analysis Model using UML and including: Use Cases, Activity Diagrams, Context Diagram, and more.

Of all the reasons for data quality problems, I find user interface design issues to be the most interesting. This may be because it is tied to the software requirements, and I have worked as a requirements analyst for a number of years.

The TDM business glossary is the home for naming conventions, data types, and domain values that are meaningful to, and defined by, the business audience. Best of all is that resulting decision models are exactly as the business community wants and in the business’s own terminology.

Now we delve into data modeling, one of the core model types. We choose to start here because data requirements are an important foundation for most information technology projects. If you are a business analyst and not doing data modeling today, you should be able to at least read them to validate requirements against what a data modeler has created and our bias is that business analysts can and should be doing “functional” data modeling.

In the real world, good decision modeling is always a balance between science and art. The science is systematic decomposition of a structure (of data or logic) into a set of smaller structures based on the definitions of successive normal forms. The art, on the other hand, is a general decomposition into a set of smaller structures based on factors not related to detecting and correcting normalization errors.

The purpose of this brief article is to provide a simple example on how to link and verify four models: use case, data flow diagrams, entity relationship diagrams, and state diagrams. Note the word verify, not validate. Verify in this context means that the technique is consistent and complete, not that it reflects correct requirements.

Today, it is very common for organizations to use The Decision Model for managing DQ logic. The results are impressive and also deliver unique advantages over other approaches. In some cases, organizations represent DQ logic in The Decision Model as part of requirements deliverables. In other cases, organizations create DQ logic in TDM-compliant software which validates the logic against TDM principles, generates and executes test cases, and sometimes deploys to target technology.

Have you ever been confused about why you were not allowed to do what you tried to do? Been judged or evaluated in a way you didn’t expect? Stumped by the result or decision a business system produced? If so you are a ‘why victim’.
 

 Analytics drive key strategic decisions in major corporations every day. However most legacy tools and solutions that help companies make these critical strategic decisions, simply aren’t built to deal with the reality of today’s modern business environment. Below are some essential questions to ask as you assess the potential benefits and limitations of new strategic analytic platforms for your organization.
 

Predictive Analytics can play a massive role in the simplification of Big Data. The role it plays comes down to getting the most out of this Big Data, and it starts with what some people refer to this as the fourth “V” of Big Data (Velocity, Variety, Volume), and that is Value. Predictive Analytics takes all of the data available and can pull the most important elements of that data, helping to create a predictive model or create an ideal profile to help organizations in many different aspects of the business.

A missing ingredient in most current approaches to IT requirements and business rules is developing a standard business vocabulary, a concept model. Every business analyst should be familiar with the technique – it’s simply about clear thinking and unambiguous communication. What are basic constructs in developing a concept model? This article discusses four prefabricated elements of structure, ones that will enable you to build a complete and robust business vocabulary.

All paths to organizational decision modeling encounter a common question: How do you introduce The Decision Model into an organization? More specifically, how do you gain management attention for delivering decision models as a standard practice? This month’s column addresses that question.
 

This article describes the Entity Relationship Diagram that allows you to document the structure of a database in terms of persistent entities and the relationships between them.  The Entity-Relationship Diagram (ERD) provides a way of graphically representing the logical relationships between entities in order to create a database schema to persist those entities.

This means that The Decision Model is at the center of a serious shift in the way we perceive and manage the business rule and logic dimension. So, this month’s column highlights the shift, starting with 2009 and ending with 2012. At its core are the seven observations indicating that a shift is happening. More important, each observation contains corresponding article links to related Modern Analyst articles.

This month’s column is not a debate about decision table theory versus decision model theory. Instead, it focuses on current practices for decision tables and those of The Decision Model. It covers (1) Four Benefits of Decision Tables (2) Decision Tables in Practice (3) The Decision Model in Practice (4) The Science Behind the Transformation Steps and (5) Wrap Up: A Leap in Maturity.