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.
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.
When we first look at data fields on a business document, they appear complex. However once we analyze and understand them, they become simple. This is one of the purposes for a technique called normalization – to understand data fields and their relationships.
One of the most significant characteristics of an Agile engagement is that technical and business professionals work collaboratively to grow the system. The team agrees upon the goals for the project, as well as the order in which the requirements will be addressed on each of the sprints... At least one team member should have the role of “data advocate”; a person who wears the data hat...
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.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: