Over the past 15 years IDIOM has conceived, evolved, and demonstrated the effectiveness of it’s ‘decision centric’ development approach, which leverages both decisioning and agile approaches to radically simplify and strengthen commercial systems development. This advertorial describes the IDIOM products and how they can be used to implement the decision centric approach.

The UML State Diagram, sometimes known as the Statechart Diagram or Static Transition Diagram, defines the entire lifecycle of a business entity or object in terms of the messages it receives and the responses it makes from the moment of creation until the moment of destruction.

Agile, formally introduced in 2001 through the Agile Manifesto, has morphed into many variations and been customized within organizational cultures and projects. After 14 years since its introduction, this article raises an important question.

Observation as a tool is used to understand people and their environments. It is a tool best used not in situations where we are verifying fairly well-understood information, but rather in situations where we do not really know what we are looking for. Observation is not about validating assumptions, but rather is a tool to find out what we don’t know that we don’t know. Observation should bring out the surprising and the unexpected. Of course observation has a purpose. But the purpose can be fairly broad.

The primary subject of this article is process, a word that is generally both indefinite and nuanced when applied to systems development. In this article we describe how process as a concept becomes both simpler and more definitive when it is integrated with decisioning. The combination of process and decisioning extends the ‘decision centric’ development concepts that we have evolved over the last 15 years. These concepts combine into a proven, practical, and robust methodology that leverages decisioning and agile techniques to fundamentally simplify commercial software development.

My purpose in writing this brief article is to give some quick insight into the BABOK V3 which, by the way, is near twice the page volume when compared to V2. Obviously, V3 requires a perusal rather than a quick scan. In the future, I am sure to reference V3 several times and gain further insight in different contexts. It is worth the read.

A product roadmap is a powerful tool to describe how a product is likely to grow, to align the stakeholders, and to acquire a budget for the product. But creating an effective roadmap is not easy particularly in an agile context where changes occur frequently and unexpectedly. This post helps you create an effective agile product roadmap using my roadmap format, the GO product roadmap.

Data migration is typically the most forgotten or underestimated component of an IT project which is the process of making a copy of data and moving it from one system to another, preferably without disrupting or disabling active business processes. On some occasions, it is not easy to understand that a data migration is needed in the project and ...

A UML Use Case is an atomic system function with a well-defined and standardized specification, which is performed by or o behalf of a system user or ‘actor’. This article describes how a UML Use Case Specification should be written.

In this article we discuss the benefits of using an appropriate template as the vehicle for delivering requirements. We also cover how a review and approval process tailored to stakeholders can help create the alignment needed to move a project forward.

So many BAs complain that their role is under-appreciated, and that their voices are not heard when they have a recommendation for the business stakeholders or the delivery team. In these types of organizations, explaining the true BA role can be an uphill battle.

I have come to realize the practitioners in this industry suffer from acute myopia regarding their work. Programmers tend to believe their part of the puzzle is the most important, as do business process analysts, data base analysts, network analysts, project managers, enterprise analysts, etc.

As of this writing, the city of Houston is still struggling with their pothole process. The point of this article is not to recommend a solution, but a path to resolution and a profound lesson learned. Not all problems are resolved by just “throwing money” at it. In fact, the lack of a budget being used is an indication of a process problem.

This article looks at practical experiences of implementing business rules using TDM and SAP from several angles, while also raising some of the questions which I find asked most frequently and insistently in my work, such as:

• Why do I need anything other than an existing rules engine to define and manage business rules?
• Why would I want specialized tooling for business rules when I already have tooling for requirements gathering?
• How does improved business rules definition help me with testing?

In parallel with my consulting work, I teach an online course for business analysts on writing better requirements. Invariably, the most skilled participants of the course are the ones who seem less confident when submitting their assignments. “Please let me know if this is not what you expected”, or “I hope I understood the assignment correctly” are phrases I typically get from these participants, while the weaker BAs typically write “here’s my assignment for Lesson 3”, without any caveats.