Similarities
- AM produces Perspectives that align with BIZBOK
- Both promote an approach for describing business to support decisions for change.
- Both are underpinned with a core set of elements.
- Both promote activities of business practitioners (and their surrogates) to describe the business.
- Both recognize the importance for information in understanding business.
Differences
| Assertion Modeling | BIZBOK |
| AM aligns Concepts, Methods and Software tightly | BIZBOK focuses more strongly on strategic planning primarily at the Concepts level. Methods focus on identifying elements and mapping between them. Tool developers are consulted and informed |
| AM practitioners come from a broader organizational levels. | BIZBOK practitioners largely address management perspectives |
| AM addresses Responsibility for the business statement (Assertion) | BIZBOK addresses responsibility with cross-maps from Business Units to other elements such as Policy, Initiatives, Capabilities, Product, Stakeholders, and Organizations |
| AM has stronger emphasis on business decisions(Assertions) | BIZBOK business decisions are implied in its elements. |
| AM stresses the evaluation of the current, and future, state of Capabilites and Value Propositions | BIZBOK recognizes that Capabilities, Value Propositions are significant in understanding an organization. |
| AM requires conceptual understanding of less than 10 Elements and Connectors | BIZBOK requires conceptual understanding of 30 or more Elements and 40 or more Cross Mappings |
Is Assertionizer a BIZBOK Tool?
A BIZBOK tool should at the minimum support the capture of information about Capabilites, Information Concepts, Value Streams, Organization. This support should support mapping (in BIZBOK capturing lists and hierarchy) and cross-mapping to represent relationships.
In Assertionizer, Information is currently identified at the decision level(Assertion).
In Assertionizer, Authorities encompass any decision maker involved and therefor all Stakeholders. A Business Unit or Organization would be captured as an Authority and the decisions (and information needed) would be captured as Assertions.
To initiate a Capability Map in Assertionizer would require identifying Authorities who assessed the named Capabilities. And where supporting Capabilites make up a Capability it would require information from the assessment of the supporting Capability that carried its assessment to provide the upper Authority with information to support their overall assessment. If it was necessary to eschew responsibilites for the Capability Map a general Authority responsible for evaluating Capabilites at all levels would be used. Currently Assertionizer supports the generation of the Capability Map if this approach is taken.
For an isolated Capability Mapping Project, with no anticipation of further cross mapping, standard office tools make more sense. For a longer term investment it makes sense to use Assertion Modeling. Particularly if it is part of an Enterprise Architecture initiative or if more complex, and costly, tools are out of reach.
The adjustment in using Assertionizer is to fully embrace Assertion Modeling concepts. A deeper understanding of business decisions, veracity, meaning, and communicating decisions, comes in time, with use of the Assertion Method. Thinking of Capabilites as statements of ability to perform, now and in the future, helps for a more explicit understanding of organizational responsibility. It leads naturally to KPIs.
And the opportunity to operate a single knowledgebase and deliver Perspectives as artifacts and deliverables to inform decisions from a single source of truth is appealing.