Other Methods and AM
- Some Assertions are the assessment of a Capability from BIZBOK.
- Assertions map to DDD components such as aggregates and entities.
- Some Assertions express information from a Process from BPMN
- Some Asserions are a Business Requirement for an Implementation
- Most Assertions can be categorized as TOGAF and Archimate elements
- A subset of Assertions to be Implemented defines an Agile Sprint
- When an Assertion is emited to its connectors it is a Business Event
- Assertions align to Use Cases but elaborate the information flows more explicitly.
BIZBOK
BIZBOK addresses a strategic perpective of an organization. It aims to align with other parts of traditional Enterprise Architecture.
BIZBOK’s core elements provide a powerful language for subdividing and expressing value in an organization.
AM aligns with BIZBOK in the sense that Assertions are used to to assess the status of the capability, perhaps in comparison to a target.
Currently Assertionizer supports tagging Assertions as Capability Assessments and can build the Capability Map from these assertions.
DDD
Domain Driven Design focuses on modeling software based on its real-world business domain.
Requirements are discovered through dialogue with domain experts.
Assertion models capture the business domains and their interrelationships. They define the ubiquitous language, and assertions map to DDD components
The Order Entry Assertion Model was built to show how AM supports DDD
BPMN
Process Modeling embraces workflows, completing tasks and moving on to the next. Built on this foundation BPMN has added information flows and decisions, only of the next task to tackle. Anchored in notation diagramming elements have been added to make resolve how individual flows work together and break down into subtasks.
Trials aligning BPMN and AM have imported BPMN elements to prime a more extensive assertion model(a good way to start exploring Assertionizer).
Once built, perspectives can be identified that align with the original process flow. Trials are under way to explore exporting subsets of a larger assertion model into a BPMN structure.
Business Requirements
Typically requirements are delivered as lists, often within a use case perspective. Translated into JIRA tasks, they have difficulty in carrying the depth of business understanding analysts have gained in discussions. This moves communication of the business into agile team discussions, and finally only documented in code.
As assertions are elaborated, more discussions occur to capture a richer description at the source.
(How often is this done? Is it manual or can it be calculated? Does it create personal information? What information is needed? Who usesthe information created and how is it passed?)
The ‘why‘ of the assertion is how its information supports other decisions in the organization. And the other decisions may be operational, managerial or goverance.
See the example of Requirements in the AM Example Model of Recruitment.
AM and AI
AI is exquisitely good at hanging information into the frameworks we already have; implied by how AI sees us using them. Until trained, AI won’t present business descriptions in terms of decisions and how they are communicated.
Assertion Modeling is a simpler language/framework to advance our management of knowledge. AI can be a helper.
Assertion modeling trials with AI have included asking it to populate an assertion model with what it knows about a particular domain. It works surprisingly well, pre-populating a starter assertion model. But immediately gaps are exposed in the business description(because AI stays generalized).
Trials, using AI to help create code, from thje complete specification generated from an assertion model, works very well too. Using this approach the Order Entry Application was built in about a week.
Other Methods