We are frequently asked about connecting and tracing software architecture elements to business processes by integrating BPMN business models and software models in UML (Unified Modeling Language)... Now we will explore how to supplement business architecture with software architecture.
Many words have been written about the process of business analysis and how it can be performed on different types of projects. There are a multitude of tools and techniques which can be used plus methodologies and frameworks to suit a wide variety of circumstances. This makes it all too easy to get absorbed in the day-to-day detail and forget about the real purpose of business analysis – to fix a problem or provide the organisation with a new capability.
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!
What comes first, the business analyst or the business analyst experience? If you’ve looked at BA job postings lately, you’d probably say the experience, as most BA jobs require experience. From one perspective, you’d be correct. But from another perspective, you’d be wrong. For if every BA role requires experience, how is it that there are hundreds of thousands of practicing business analysts across the world?
Quite simply, root cause analysis is a technique designed to unearth the real, often unknown reason why a business problem is happening, and then to propose a viable solution to fix it. BABOK explains that root cause analysis “can help identify the underlying cause of failures or difficulties in accomplishing business analysis work”[1] [emphasis added] and further clarifies that it is “used to ensure that the underlying reason for a defect is identified, rather than simply correcting the output (which may be a symptom of a deeper underlying problem).”
Checkpoint Beta is not mandatory. It is, however, extremely helpful for the business analyst. Checkpoint Beta is also an informal meeting, this time with the solution team. It is held prior to committing the solution to the final, formal solution document andobtaining final confirmation from the business community.
brought to you by enabling practitioners & organizations to achieve their goals using: