What are some common business architecture pitfalls and how can you avoid them?

In my experience there are to many “lets re - strategize” efforts and to many “lets try a new method” efforts. And both are usually happening in concert??♀?

There is the vision and scope of a business architecture engagement, of its existence as a standing function, and it’s longer term potential. All three are important. Just because a Bus Arch function is stood up to support one particular service doesn’t mean it can’t, and shouldn’t grow to do far more to capitalize on economies of scope. To grow requires investing in selling its services to other business sponsors over time. The alternative is that other Bus Arch teams (often by other names) will emerge to tackle other Bus Arch services and you have a siloed practice that is inefficient, destructively competes, and lacks the scale to be successful and provide its true ROI.

Fully in agreement with Richard, to sell its services to other business organisations is vital for the function and value to survive. I found that this practice is still too much staying in their little bubble, a team, a business division finds that it is valuable to do it for them and they support it but they don’t realise that at the end, doing it for only that part of the organisation will give a partial view and an incomplete value.

Being output instead of outcome focussed is one of the most common examples I see. Occasionally the vision / scope is missing, but more often than not it's rather than people are not aligned on common goals and outcomes. Defining the vision properly and getting buy in is the first critical step to achieve business change.

In my experience, it is imperative that any previous lessons learnt on similar projects are reviewed to help frame actions to improve communication with the stakeholders.

In my experience Architecture practices always get the tooling wrong. Are you tooling to support you EA practice or are you tooling to support the EA you have developed

I agree with Karrie on tooling and it can also pull you into a rabbit hole of doing far more detail than you need (because the tool supports it). As long as you have a way of sharing & collaborating your work simple diagramming and tabular data collection (dare I say Excel) can be enough.

Again keep it simple and keep checking back with "the business" they need to recognise what you're doing; ideally they should take ownership of it and be the custodians going forward. Things like business capabilities at least at the highest levels will not change much over time rather it will be the ways they are performed that will; this means it's not onerous and if as it's should be it's useful in strategic planning it will continue to evolve to be more accurate and complete. BTW on completeness this comes down to the Vision piece if you set a bounded context for a piece of business architecture work you may have to accept it will be incomplete at those boundaries.

Although SAFe the framework contains a lot of overhead there are some good principles that underpin it. - Strategic Themes - Value Aligned Teams - Regular alignments to align on roadmaps and dependencies. - Leading / Lagging Indicators to measure the impact of the change against it's intended value.

Also important to know the altitude your BA practice is aiming to fly at and how it will integrate with other "business architecture" types of disciplines flying at other altitudes. Will it be aimed at improving strategy & planning or design & execution? Will it be enterprise in scope, domain specific, or down at the solution level? One organization will not be positioned to do it all. How will it partner with other disciplines and practices such as product owners, design thinking, lean portfolio managers, processes improvement teams and various frameworks/methodologies (SAFe, scrum, waterfall, etc)? How will you permeate BA concepts & practices into all that the organization does in regard to strategy/planning, design & execution?

Beyond integration with other architectural domains, consider how you can effectively integrate business architecture concepts (and its outputs, partices, models, artifacts, outcomes, etc) into your operational processes for strategic business planning. Business Architecture is a set of concepts that is meant to optimize business/technology alignment and maximize business outcome value, and doesn't need to be treated as a silo discipline (or organization) that is seperate and distinct from business strategy & planning. BENEFIT those stakeholders by weaving BA concepts into the way your organization plans and decisions business & technology initiatives/investments. Use BA to help them and the org make better informed decisions!

Business Architecture is the KEY part of your Enterprise Architecture and while personally not a fan of TOGAF in the whole it does give a framework for how you can hang these elements together. Most EA's fail because they actually skim over the BA part and focus on technology & data that are best addressed "just in time" as part of Product development. I have found a Capability Canvas can be very powerful in documenting how these elements come together, i.e. how IT, Processes, People and Data support a Business Capability (or don't).

This comes down to the first part set a Vision and Scope; don't try to eat the whole elephant in one go -- or if you do then do it as a very high level and then choose one key (for you business) area to deep dive ideally so you can trace one or more value chains, show how they contribute to business success and how they can be improved (with process, people, training, technology, data or other improvements). If you can't put ￡/$ on it you'll not get traction IMHO.

This can be applied to everything and again it's sad how often it is said and how often it's ignored. In the case of business architecture it has to be built into business decision making -- once it proves useful it will naturally be kept up to date.