This page discusses the promises made by business architects. Although all roles make these promises, how each role keeps them is often different because of their responsibilities and level of authority.
Create psychological safety
Although this page is more about how the business architect creates psychological safety, it is important to attend to that business architects are often the ones who are delivering unwelcome news to teams and they, in particular, must be given safety. How different components interact with each other is of paramount importance to keep visible. This said, business architects must make it safe for different groups to point out inconsistencies in following business architecture guidelines so that they can be cleared up.
Promise: Accelerate value realization
The business architect’s role is to ensure that any impact working on those MBIs at the top of the list do not adversely affect other capabilities. Doing so would lower the amount of business value actually realized since there would also be a negative impact.
Promise: Collaborate proactively
New capabilities often affect others. It is important that different parts of the organization work together to ensure adverse effects are avoided. The business architect must ensure what is required in this collaboration is made visible.
Promise: Make all work and workflow visible
Dependencies between capabilities is often obscured or even unknown – especially when subject matter expertise has been lost. One of the business architect’s role is to make these visible.
Promise: Increase predictability
In many ways this could be considered the defining goal of the business architect. When building one capability adversely affects another capability, unpredictability results.
Promise: Keep workloads within capacity
Unseen dependencies between different parts of a system typically results in integration errors and a change in one part of the system breaking another part. This new, unplanned work (waste), adds work in process. Since it was unplanned for, it will likely overload the development groups affected and even their product owners/managers as they will likely need to get involved to sort things out. In addition, this often has a ripple effect to other groups that are dependent upon those teams directly affected who are not involved with this functionality but are dependent due to other capabilities.
Promise: Improve Continuously
Helping different groups collaborate is a never ending job.