Do architects need to practice business architecture in order to deliver true business value?
I sometimes speak with architecture teams who say apologetically, “We haven’t gotten to business architecture yet – we’re still very technical.” When I ask them why they are (seemingly) unhappy about this, they may say something like, “well, that’s where the real business value of architecture is.”
This seems like a logical association. Business architecture equals business value. It’s also misleading.
Think about it. Many architecture groups focus on technology. Are they not delivering business value? If not, why would a company pay them?
Before I continue, let me define business value. I prefer a very simple, common sense framework;
- Revenue (or mission outcome, for nonprofits/military/governmental)
- Cost (i.e. efficiency)
- Risk (reduction, transparency)
- Customer satisfaction
If we put these objectives at the top of an impact map, we can derive various routes to value for architecture:
In Forrester’s experience, architecture groups tend to start on the right and move left in their quest for value. But there is business value on the right. It’s hard to argue that there’s no “business” value in reducing the enterprise’s vulnerability to security breaches. Improving staffing efficiency, reducing incident risk, improving vendor leverage – these are all business benefits. They are not merely “technical” (whatever that even means).
Am I deprecating business architecture? Not at all. Business architecture centers on business capability mapping, value stream analysis, the EA interface to business strategy, and (depending on who you’re talking to) managing enterprise ontologies. These all are important — and their relationship to the value impact map is complex and nuanced.
For example, at the bottom of the impact map, we might start with technical capabilities (compute, network, storage, middleware, etc) and later move into business capability mapping (product, sales, supply chain, your specific vertical capabilities). So the very foundation of the practice evolves as you expand into business architecture, which will inform your efforts across the full range of enterprise value outcomes and impacts.
While you can rationalize a technical portfolio based on technical capability mapping (we have too many flavors of database), in order to rationalize an application/service portfolio, you need business capability mapping (we have three purchasing and two HR systems due to acquisitions). And notice that rationalizing an application portfolio has “technical” benefits – you can start to roll back the sprawl and tech debt. “We no longer have those ancient on premise servers with unpatched vulnerabilities because we sunset the legacy HR system and moved to a SaaS option.” It’s all an integrated, holistic analysis.
Ultimately, architecture in all its forms (business, data, application, technical) is about longer horizon value, making the right decisions when decisions are expensive to change, managing technical and organizational debt in many forms… the important things that are too easily overlooked in our urgent day to day work. The challenge for every architecture group, no matter what its focus, is to clearly articulate the value propositions it is committed to delivering, and hold itself accountable for them.
