Find out who would use it, what does it do, and why you would use it.
Who would use it?
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 colours, 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?
What does it do?
A strong assertion model provides the analytical foundation for many recognized management practices such as audits(financial and non-financial), organizational design, and performance reporting. Some of practices are included here and they include references to the example model of Recruitment.
Business Strategy
The strategic statements of the organization are Assertions. These statements support each other logically and require tactical, planned and implemented assertions to be realized. These Strategic Assertion Models provide the framework for aligning other business design and implementation.
EXAMPLE: See the Recruitment –Strategic Perspective to see how Strategic and Tactical Assertions inform (and are informed by) operational Assertions.
Organizational Design
Organizational design addresses the application of human resources and accountability to meet organizational goals. Business Assertions are explicit in representing, with Authorities, how resources are applied in the organization. For a functional area under review they also show the size of the effort and where some tasks may be automated.
EXAMPLE: See Recruitment — Responsibilities Perspective for the summary of duties for a given Authority. These can be analyzed with respect to necessary skills and effort.
Performance Measures
Because the Assertion Model shows information flows within the organization they can also show where information can be extracted (through counts and summaries) to provide measures to compare to targets. Extracting measures becomes an exercise in studying existing Assertion models and implementing a connection to support the Performance Assertion.
EXAMPLE: See Recruitment – Timely Recruitment Performance for an example of an Assertion that automatically creates performance information.
Security, Privacy and Freedom of Information
The Assertion Model shows the Authority in the organization responsible for creating the information. Some of this information, identified in the Assertion Model, is personal or financial and when the implemented information flows cross security domains it is is explicit in the model.
EXAMPLE: See the Recruitment – Personal Information to see how a summary of the information flows of personal information can be created from the AM.
Audits
Audits typically assess a set of business processes, standard operating procedures, reports. Often this against a standardized auditing framework. The Assertion Model shows in one place and one format how the business is performed. Aligning the organization’s model with auditing frameworks simplifies the auditing process. In some cases audits cover how well certain factors have been implemented. To support his in the short run mappings of the Assertion Model to implemented components in applications. In the long run, as implementations are driven from the Assertion Models auditing becomes a simpler exercise.
Position and Skills
The organizational job positions can be mapped to the Authorities in the Assertion Model.
The specification of actions, documented in each Assertion, form part of the job description. Implications of changes or become more obvious. The example in the appendix shows how these specification can be extracted from the model to show a set of duties for a given Authority.
Business Architecture and Transformations
The Assertion Model embraces both Business Rules and Requirements. In fact business rules are elaborated in each Assertion (or in a set of Assertions). The Assertion Models set of Assertions is the set of Requirements. The solution must implement each of the Assertions including passing information into and out of the organization (which is shown explicitly). The Frames specified for all the Assertions provides a set of Data Requirements. These can be mapped into the physical database design particularly where the database acts as a store between Assertions. Process flows are extracted form the Assertion Model by sub-setting the Assertions and arranging in swim-lanes for the Authorities. Classic Process Flow Diagrams often miss information needed in other domains by a singular focus on sequence.
Analytics and Simulation
Because a well-formed Business Assertion Model is formally specified, numeric values can be assigned to these Assertions. These can be statistical methods that forecast how often they will be asserted; and subsequently lead to attained goals. Or they can have numerical values assigned that represent the costs of delivering the information within the organization. There is opportunity to extend the methodology to support these more analytical endeavours.
Why you should use it
- Stop the multi-methodology wheel-spin
- Merge your organizational viewpoints/silos
- See the business from a whole new light
- Narrow the Business/IT gap
- Be explict and clear
- Connect strategy tactics and operations
- Align information management and content management
- Identify reliable information
- Implement in chunks, knowing what is affected
- Establish accountabilities
- Do real business analysis
- Implementation and design co-exist
The Vision
Up to now there has not been a approach that is so atomic, that ties closely to business information, that incorporates information meaning, structure. authorities, and flows, all in the atomic business element.
Up to now there has not been an approach that is so basic that implementation is not dependent on business meaning.
Up to now there has not been an approach that has a simple enough mechanics that effort is left available for understanding the business, not the methodology.
Up to now there has not been an approach that emphasizes the veracity and source of the information.
Up to now there has not been an approach that can be nimble enough to design and implement in a day.
Up to now there has not been an approach that can keep up with the direction the information industry is headed and has the same concepts and culture of constant change.
Up to now there has not been a way for design and implementation to co-exist.