Step through all the parts of a mature AM for Recruitment. The full model is located here. Keep it open to browse, and follow the links below to find out about each section.
If the this model is good, you will become involved with being a real business analyst; thinking about how the business works, and could work better. AM is a means to an end.
Tour Sections
- Understanding the Report – What is the HTML Report, and how it is structured
- Understanding an Assertion – All the parts of specifying an Assertion
- Understanding a Connection – What the Connections show
- Understanding The Frame – How is the data detailed
- Understanding Authorities – Specifying the Authorities
- Understanding Modeling – How a modeler thinks AM
- Understanding Perspectives – How to focus on the parts that matter for a problem
Understanding the Report
The HTML Report:
- Is generated by the software
- Is in HTML format and includes many links.
- Is available in full here. Other links in this tour take you to sections to explain them in more detail.
- Includes many sections to give a full picture of the model and its perspectives
- Is focused on the business of Recruitment. A section of the report describes the domain
- Starts with a hyperlinked Table of Contents.
- Contains a list of the Assertions in the Detailed Assertions section. Search by SpecID, Alphabetically or Model Order
- Shows everything. You will produce other artifacts of the model that address specific model deliverables.
- Shows the current model explicitly. It can be used to grasp how the business is performed and support ideas for different and improved business.
Most of the sections are explained in the tour.
As you slowly build and enhance your model you will regenerate this HTML report to check consistency and browse the model overall.
Understanding The Assertion
Arranged Phone or In Person Interview is a good example Assertion to start with.
A fully elaborated Assertion has many parts; each enhances the core perspectives. As you start modeling you will incrementally populate each Assertion. This diagram gives the placement of the Assertion;
The first section, a profile, shows an identifier, name, and title of the Assertion. It shows that the Recruitment Administrator is accountable, This Assertion is not Governance, or External. It is Operational.
The Activity Type gives a categorization of the determination. The chosen type is Arrangement. This has complex inputs ( such as availabilities) and requires the Recruitment Administrator to ensure those constraints are met.
This Assertion cannot be automatically determined from the inputs. It is determined Manually . If this could be calculated automatically then Automatic would be shown and there would be a script or business rule to calculate it.
The Specification section provides guidance to the Authority on how the determination is to be made. This may be a few, helpful sentences. Or the text of a formal Standard Operating Procedure. If procedures change regularly and are issued by another Authority then the SOP would be included as an incoming Connection by the modeler.
The Modeling section shows information to assist in the building of the Assertion Model. The Status is modeler defined and is usually used to tag the Assertion as having been assessed to a certain level of detail. The QA Frame is calculated and from how much of the Assertion has been elaborated. It helps measure the overall quality of the model.
The Model Note can be used by the modeler to elaborate on some of the rationale used for how it is specified, or for indicating concerns for more detailed business investigation.
These values that describe the Assertion are incrementally refined as modeling progresses. Completing them helps ensure the Assertion is clearly understood.
Understanding the Connection
The next two sections are Inputs and Outputs.
Connections move information into and out of an Assertion.
Different Input Connections will carry different information. When new information arrives, such as an updated short list, or a changed schedule, the Authority may re-determine the Assertion; they may reissue interview details. The Assertion is determined based on the input information provided. Often there may be informal information sources (they may consume effort in accessing). These will not be included as Connections but may be mentioned in Input Notes.
All the Output Connections carry the same information defined by the Frame(see below) of the Assertion. Determining the Assertion populates the Frame, and the Connector delivers that information. The Frame sets the structure (and meaning) of the information. The Assertion does not deliver different information and structures to different downstream Authorities. Consuming Assertions may only use some of the information provided.
Information Management and the Connection
For explicit information management in the organization, the Assertion defines the meaning of the information and the Authority is considered the ‘owner’. Connections are agreements between Authorities. It is the discretion of the source Authority to provide access (authorize the Connection).Connections often carry Personal, Financial, or Organizational Records. When these Connections are between disparate environments the protection of the connection becomes paramount. The Assertion design specifies these information types and allows these to be seen as individual perspectives.
For the Arranged Phone or In Person Interview there are 2 formal inputs shown. The Recruitment Administrator uses corporate calendaring (including meeting rooms) to assist in scheduling. The information from RC7 Job Opening Shortlist is shown to contain availability of the interviewers. The Assertion will have to be determined once for each of the candidates tagged for an interview.
Output Connections
There is a single Frame shown for output. When a determination is made it is populated and sent to consumers. There are 4 consuming Assertions that require this information in order to make determinations themselves. The Recruitment Officer appears to receive the same information twice. In fact this is due to the fact that they must take two separate decisions based on the information. The implemented Assertion RC05 Applicant Interview Notes must be refreshed to show that the Applicant has been scheduled for an Interview. And the second Assertion RC36 Opening Status ( which is the responsibility of the Recruitment Officer) receives information that allows it to update the status of the Opening Status automatically (Use the link in the report to inspect RC36. And to discover how this business event is captured automatically)
Understanding The Frame
The Frame specifies the structure of the information that the Assertion delivers. It can be specified at a detailed, field-definition level, or more generally as for example ‘Assessment Report’ .
The ability to vary the definition of the information means that Assertion Modeling can be applied to Governance Modeling as well as Operational Modeling. When operational Assertions are being modeled it is common to be specific with the fields and their definitions. When a Connection delivers information to an external organization the Frame must be fully specified. As it must when it describes information into or out of Automatic Assertions (implemented by scripts or business rules). How the frame is specified is detailed enough to support the creation of XML or JSON schemas.
The Frame is defined by the originator of the information. They know its structure and meaning. Downstream Assertions change the meaning at their peril. For Arranged Phone or In Person Interview the Interview details are used by more than one downstream Assertion.
For Arranged Phone or In Person Interview there may be some boilerplate details for expenses and even for appearance(physical or online) at the interview. This Assertion is a prime candidate to be an ‘augmented’ Assertion ( not purely manual, and not purely automatic). A good implementation would provide functionality to orchestrate the interviews.
All the Frames in the HTML Report have the opportunity to provide sample information for each of the fields. This can make it much more concrete. In fact it makes it easy to mock up a prototype implementation of the Assertion.
The Recruitment modeler has decided that ‘how to appear at the interview’ and ‘how to submit expenses’ are determined together in a single Assertion. This is very much a business design decision. If as a modeler of a business person, you were exploring this, you might make two fragment assertion models to see how both might affect the participants.
Also note that the two Assertions determined by the Selected Applicant are External Assertions. They are determined by an Authority outside the organization. As you do your business design you may feel it valuable to implement them with in an organizational environment. The applicant would be using an implemented functionality online. Currently though this is implemented within an email environment.
Understanding The Authorities
Authorities are managed separately from the Assertions in AM. They are identified and defined ;and then specified when an Assertion is specified. Authorities are perhaps the most important ingredient of AM: they stress the importance of Accountability. And a good AM would be incomplete without a set of Governance Assertions with their own Authorities, that provide the rationale for the Operating Assertions.
They are managed within the Assertion Modelling process, but they can reported on separately. So there is a section in the HTML Report that specifically addresses this(the Responsibility Perspective).
This is the first of an indication of how valuable AM is at providing views or perspectives into the model itself. By identifying an Authority for each Assertion the ability to produce the Responsibilities Section of the HTML Report.
In this perspective you will see that for each Authority, the Assertions that they are responsible for are shown. Indeed, their job duties are listed here. If you wish to run your organization with a magnifying glass and an iron fist, write detailed specifications in the Assertions and show them here.
The Responsibilities for the Recruitment Administrator provide a good example. They have two duties(responsibilities, Assertions to perform). REC6 that we have seen and RC18 Approved Applicant Expense. When you completed these Assertions there was a place to specify sizing(if it applied) . Now this information can be added to the Perspective to show the amount of effort needed to perform these duties. Making these sizing estimates can be contentious but extremely rewarding. In a large organization the sum total of effort for scheduling may exceed a single FTE. So the model begins to identify at this point the need for a number of employees to be assigned to this Authority to complete the workload. Because each Assertion is a coherent unit your implementation may route different short lists to different employees with this Authority. This is an indication that AM supports workflow planning. You may want an Assertion (manual or automated) that routes the information to available Authorities. In an Implementation an Authority is called a Cubicle and is expected to provide messaging and buffering. (Concepts for AM Implementation are in the ideation phase)
Understanding Modeling
The HTML Report plays an important part of the art of AM. The software ( Firmstate, and Assertionizer) support the editing of the model, and they allow browsing and diagramming capabilities. But the HTML report allows a complete and easy to navigate total overview. The software supports quick generation of the Report so modelers can view the coherence of their additions quickly.
The very essence of AM is that it is constantly being enhanced and improved. So typical modeling efforts revolve around expanding a fragment of the model to address a better elaboration of the business or to fix inadequacies. The software supports fragments as views(subset collections of Assertions) and they are used for expressing the many perspectives. Usually a view includes a diagram (an emerging capability in the software) . In this HTML Report you see diagrams that have been created for important perspectives. From the software a view is created, then its diagram and then its inclusion in the HTML Report.
Who is the Modeler?
A design goal for AM was that it could be used by a business person to elaborate their own business. Hopefully it will mature in this direction. But now Business Analysts will facilitate the creation of the model using questioning techniques, experience in implementation, and experience in the business domain to produce project artifacts and deliverables.
AM supports Governance Modeling using the same approach and method. A model that addresses, for example Requirements, will have operational and governance Assertions. An initial governance model capturing the important statements of performance for a business endeavor should proceed the operational modeling. Then, as Assertions are identified that provide rationale for the governance, it may be necessary to revise both parts.
This waltz between responsibilities will play itself out somewhere in implementations and becomes much cheaper (but still painful) early on.
The Arranged Phone or In Person Interview Assertion may look a little incomplete. Filling in the information about the Assertion is an ongoing activity.
Understanding Perspectives
Standard Perspectives
The strength of the Assertion Model is in its ability to support views that focus the business analyst on parts of the business to be analyzed and designed. There are two standard perspectives that view the model from the perspective of an Responsibilities, and for Capabilities.
The Responsibility Perspective shows, for each Authority, the Assertions that they are expected to determine. By focusing on a single Authority, all the tasks (or job duties) can be seen. Changing the Authority for an Assertion in the software, and regenerating will show the changed responsibilities. The Specification of the Assertion is included to show the guidance (or standard operating procedure) for the determination.
The Capability Perspective shows the Assertions that have been identified as capability.
Custom Perspectives
The Recruitment Contribution Perspective shows the determinations that feed an overall assessment of the Capability of Recruitment. For the Recruitment Administrator to make the assessment they need assessments of some of the contributing determinations of the parts of Recruitment. The Diagram shows how information flows from these to support the overall assessment.
In Assertion Modeling a Contribution Diagram will show (usually in a tree structure) all the factors that may affect a desired state. As each of the upstream assertions are evaluated the information flows to the next assertion, triggering its re-evaluation(manually or automatically). Finally the target state is determined and the defined value realized. The Contribution Diagram recognizes that business events ripple to other events, changing state (as defined by the Authority) , and enhancing the value proposition.
This diagram also shows feedback. Information from RC29 – Recruitment Practice Alignment may result in a decision in RC34 – Business Improvement Initiative to make changes that eventually result in an improved RC29.
Also in this model is a Financial Perspective. There are some Assertions that create Frames that deliver currency values ( or other organizational assets that relate to monetary value). They are likely to flow to and from the Financial system. This information may be tracked in subledgers and contribute to financial reporting. The AM identifies financial information and shows who makes decisions that change financial position. It may be that an Authority steps into the financial system to issue a Financial Assertion. Or, the implementation of this Assertion may have a connection ( implemented by an integration) into the financial system. This Recruitment Model does not include decisions that are made as part of the budgeting process. it is one of the gaps that would be expanded on in a real modeling context.
For now RC20 Interview Expenses Claim carries this information that originates from the Applicant. It is modeled as having the Recruitment Administrator review and approve the claim. And forward it into Finance where it is tracked for financial reporting. The specification for RC18 is probably information that is created by the Financial function of the organization as formal policy(perhaps with input from Recruitment). If the question arises as to the impediment to Recruitment from a meagre expenses policy then governance decision are n order to change this and perhaps put in place assertions that track the impact. All with a Governance Assertion Model.