The Evolving Role Of Business Architecture
Business architecture has become a bit of a watchword for organizations thinking about their future. It’s about all sorts of things – the “what” we do and “why” we do it. It’s about the “who with”, or more importantly “who for.” But it’s also about the “how we do it”, and “how we build engagement” to ensure we “do the right things,” rather than just “doing things right.”
Given that I focus on the methods and techniques that help organizations translate strategy into action (business architecture, process architecture, business engagement, etc.), I want to talk a little about the trends, methods and approaches that we see in the practice of business architecture.
I have to say recent engagements have been a real eye opener … some folks are very advanced in some areas – say capturing strategic intent, but then struggle to translate that into meaningful plans that energize colleagues in the business. Some are talking a good story of target operating models – focused around the experiences they deliver to their customers, but then miss the link to current day project portfolio that’s singularly focused on reducing the employee headcount. And as we saw in our recent BPM Suites Wave, business architecture principles are becoming more important at the process execution layer too.
Many business architects have put business capability maps as the core element of their toolbox, with a few different heat maps to help focus attention. When my colleagues and I review the capability maps and approaches of our clients, we find challenged common thread: Business architects often struggle to get the levels of engagement they need in the business; to be taken seriously and not be seen as some purveyors of some sort of geeky IT method.
As Brian Hopkins put it – they suffer the common IT problem of “doing it to the business” not “with the business.” Gordon Barnett and I are concerned that as much as 75% of the clients we’ve met had a fear of going to the business to discuss issues – they didn’t see that co-developing capability maps could really help them in engaging their colleagues. They were creating capability maps and present them, often without any real business context. It’s not that business folks don’t see the value in capability maps; it’s that to be relevant, business capability maps have to help solve a problem (that they care about). The two key takeaways:
- Develop your capability map with your business partners; don’t do it for them.
- As quickly as possible (in weeks, not months) put them to use addressing a problem the business cares about.
Use is the most critical aspect. To help business architects put their capability maps to use, Gordon and I will soon be publishing a Capability Assessment Toolkit (and demonstrating at the Forrester Business Technology Forums in Washington DC and London). This will enable multi-dimensional comparison and portfolio management across business capabilities in support of road map planning for a variety of purposes including (but not limited:
- Customer experience or service design efforts.
- Business process improvement initiatives.
- Application rationalization.
- Opportunities for revenue generation or cost reduction.
- Risk assessment and compliance.
The same approach can also support decision making around business shape such as:
- Whether to in-source or outsource a capability.
- Investment planning or how to prioritize acquisition targets.
Post M&A, it can also help provide a framework for alignment across the business, or even support a broader metrics framework spanning the entire enterprise. The point is that once business execs see the usefulness of business architecture, business architects will be able to close the gap between architecture models and the real world their business operates within.
Are you seeing the same gap between business architecture and execution? Do you have tricks or tools you use to close the gap?