How do you keep business architecture artifacts consistent across agile teams?

In my opinion, the creation of business architecture starts way before one even forms an agile team to deliver a solution. Typically in pursuit of a solution for a business problem. It requires some strategic thinking, shaping the business demand/challenge, and a vision to solve it. Therefore, irrespective of agile methodology, one needs to define the business architecture in order to communicate very clearly across all the stakeholders the problem that is being solved and conceptually how it will be solved. The agile teams can then leverage the business architecture to define their solution architecture in detail using some kind of common framework, terminology, methodology, standards, templates, and governance.

For establishing a common framework - * A standard set of template documents and standard guidelines can be created. * The template document may contain documents that would be used for creating any system architecture along with properly marked sections, contents, and any other deliverables. * The guideline provides instructions about the deliverables - that is what deliverables should be present for a particular business architecture, diagrams, any spreadsheets, or any other documents necessary to consider a system/business architecture as done

I agree. This is also a hard sell to those who see Agile as a way to avoid/neglect useful documentation. In my experience, most artifacts are used for compliance or approval purposes, and not for creating or maintaining solutions. Those are almost never accurate. Nor useful outside of those “check the box” cases. IMHO the bottom line is: each artifact should be rigorously defended as absolutely necessary before requiring it. If arguments don’t hold up against a barrage of thoughtful dissent from all parties, the org will find ways to avoid producing those artifacts or will apply lowest effort or even sabotage.

To align the business architecture artifacts with agile/scrum methodology they should be part of the scrum process. Creating artifacts (documents, diagrams, excel) should be part of scrum deliverables. the process that comes out of those documents can be followed as part of a sprint review/retrospective to see if the team is aligning with it or not.

A business architecture should always be considered something that would keep changing over time based on the needs of the business. One of the best ways to increase collaboration would be to use some kind of central document management system to store the architectures. This could be done by systems like Sharepoint. There should also be a team who can act as auditors/trainers who make sure that the business architecture is properly implemented across the organization

Don’t let it become more about the tools than about the solution. Tools can bring an org to its knees, even if implemented with the best intentions. Tooling must suit the organization’s maturity. Don’t aim for a high fidelity digital twin if you don’t even have a solid system inventory you can trust as a starting point. Training on tooling is key. Consistent use is also important for building the tooling expertise.

Scrum/agile itself believes in the idea of empirical learning and no learning and improvement is possible without failing. So it is important for business leaders to ensure that the company has a culture where failures are not stigmatized. Scrum does have the Sprint Retrospective which can be a great tool to identify the learnings and implement them in the process for making it better.

AI fail?: This is both a topic and a summary. The summary part should probably be a separate entry. Or excluded because it is not providing additional value. Topic: although possibly implied, celebrate the learning from failures too.