Well, I think it has improved – I prefer the treatment of governance now, and packaging a multiplicity of business capabilities into a business system (more in the “systems thinking” meaning than in the “IT system” sense) gives a clearer picture of how they string together with both end-to-end business processes (think Order to Cash or similar) as well as lower-level sub-processes contained within capabilities.
As much as I’d like to, I’m not sure there’s “space” left in the diagram to display the idea of business services, which can be useful for describing boundaries for top-down vs. bottom-up process change, technical services (as in Service-Oriented Architecture), and data/process stewardship decisions. That service boundary definition exercise is much clearer on the Business Capability Model; trying to do it here may be mixing abstract and concrete concepts.
A note about the placement of governance: it’s more than just the policing of rules. Governance is about making sure that the business design delivers on the business intent, and that starts with the design constraints and framework derived from the business intent. So it’s part of the original business design exercise, as well as the ongoing monitoring and development of the design’s execution. That’s why I’ve placed it as a central plank of the model – it’s hard to deliver a business design without the ground rules embodied in a governance framework.
As a reminder: this is “standing on the shoulders of giants” – my earlier posts credit the more theoretically robust models this is derived from – this metamodel is designed to lead conversations with C-suite executives about what enterprise architecture is, and where it fits with their work at a strategic level. When it comes to actually doing this stuff, more detailed tools are more useful.
As always – comments and criticisms welcome (did I really say that?) 🙂