Requirement Analysts
Is a business process a requirement? Can you deliver the use-cases as the requirements? Are the data requirements separate? Could the user stories could be the requirements? Did you have time for interface requirements? Will the implementer use the requirements document to start implementation or just to estimate? When they start will they begn their own custom methodology tied to the modules they provide?
Or perhaps they have an Assertion Model ( which they might not show you). They have it implemented. It started as an industry reference model (currently being converted to an AM format).
If you delivered a set of loosely connected requirement statements, they will map them to their Assertions.
AM supports numerous perspectives. But who would get the most immediate value from adopting the new paradigm?
Information Flows Are Requirements Too!
Because AM includes an authority, information structure, and information flows it is explicit of the functionality necessary to perform the business. If a required system can move the information accurately and quickly to and from the assertions to be implemented then it will meet requirements. And The test cases are the assertions. Most issues with new systems arise from a disconnect between the meaning of the information supplied and where it comes from. Assertions document these needs and meanings. If an authority signs off on a design assertion then they are saying that the information inputs are understood and sufficient for the determination.
Business People
Ultimately those who do business have the most to gain from being able to clearly articulate what they do, not just from an individual task basis, but from a broader perspective. If they can describe what they do, then they can ask for software to help them do it. Or they can see ways to make it better.
Up to now the disconnect between the builder has been fraught with assumptions. Users assume developers understand what they do. Developers assume they understand what the user does. So write it down. In your Assertion Model.
Participants in the process of building software products may realize the value of AM and encourage and facilitate their ‘users’. But ultimately, until business people can articulate accurately and explicitly, trial and error development will continue. AM brings a key capability to automate quickly. A prototype can be swiftly built, observed and refined.
Business Architects
Up to now Business Architects have an arsenal of methodologies to draw upon. And a new one is just around the corner.
They gird up their use cases and process flows, work with the data architects, define the capabilities, sketch in some swim lanes, then build the CRUD (don’t forget the Assertion defines its information as part of the specification!). Create the stakeholder diagram (maybe with an interaction or service)
Getting clarity from the business has always been a challenge. operational staff are concerned with their immediate remit. Supervisors have a slightly higher perspective but have to configure how they deliver by managing up and down. And sideways, if they can.
Process Improvement Analysts
Often an initiative is undertaken in an organization to improve its processes. (Some call this paving the cow-paths; some call it RPA). This starts with capturing the process flows. Process analysts act as secretaries writing down what the user does step by step in the process model. Maybe there is time for a few token information flows but it is entirely sequential( with the occasional unhappy-path).
The intent is not to process an application, the intent is to capture a set of information necessary to build a subsequent relationship with the ‘applicant’ until a statement like ‘here is your grant cheque’ and ‘we have helped another student’ is made.
Start your business improvement initiative with the Assertions that frame the overall objective.
Agile Teams
In Agile ‘a feature is a service that fulfills a stakeholder need‘. In AM an implemented assertion fulfills an Authorities ability to make a determination. By describing a sprint goal as the implementation of an Assertion the goal becomes articulated by the specification of the Assertion and the information flows that accompany the Assertion are front and center in the sprint plan too.
Can you estimate story points from the Assertion (and its Connections) ? You bet!
Design Thinkers
What language do you currently use to define a users needs? Does it make it easy to challenge why they need certain information, or why they don’t? How do you capture your own insight to bring to the table? How easy is it to translate your description to a prototype?
An Assertion Model brings all these capabilities together.
Organizational Designers
What informs organizational design? Well, culture for one thing. AM does not solve culture issues. And it might not thrive in some organizational cultures. But sooner or later organizational design has to address job duties and then AM begins to shine. And the explicit responsibilities of a section or department, described in AM helps frame the design. And shouldn’t organizational design address optimizing information flows?
Performance Planners
What information do you use to inform performance measures? Use your AM to identify where to add performance related Assertions so the reporting becomes integral, not an add-on.
Auditors
If you are a auditor you probably have a checklist. And you probably get the information you need to perform a non-financial audit in a myriad of formats. But you can build an AM of the business of your audit. The exhibits provided by the client are information flows that support a number of auditing Assertions (assessments or findings). They ultimately compile to the audit as a whole. If the audit is done regularly then there is a pattern of good practice (describable in AM) that the the client could adopt, and implement, that would shorten audits significantly.
And this gives your client a big chance to adjust their AM to reflect the audit needs, cutting audit costs.
Interface Builders
As a large implementation initiative draws to a close, all that is left is to do is the interfaces between systems. Call in the programmers now, we have to roll out next month.
Or perhaps there was an Assertion Model that showed the information flows outside the organization, between departments, or between Assertions currently implemented in different systems. What if it actually stated the information structure needed for its business determinations?
Management Consultants
You deliver a range of services. Updated with the latest terms every year. And you have gurus who are masters of the various perspectives. Organizational Development, Governance, Information Management, Transformations, various Financial Services, Content Management, Records, Information and Privacy, Security. And you have some overarching frameworks that cobble these together. But the products delivered to the client are disparate. PowerPoint decks, spreadsheets with colors, Word documents, PDFs.
What if the AM you delivered for one engagement could be picked up for the next proposal for this client in a different discipline and provide a 20% head-start on the competition. What if the AM reference model you use for the discipline was already partly merged from the previous engagement? What if you already had information populated in your prototype ready for refinement?