A higher education institution asked me to undertake an analysis of a very complex account management system. (I was called in after multiple employees and consultants had failed in this task.) The institution wanted the analysis as a precursor to building a new system. One particularly obscure aspect of the system was how and when resources such as email accounts were deprovisioned for a user who was leaving the institution. The institution had many different type of users—and many users had more than one role. The upshot was that the institution could not reliably predict, much less change, the deprovisioning process for any given user.

My analysis showed in gory detail what their current system was doing.

I had a strong sense that a far simpler system could accomplish the same set of functions. I created the "Simple, Accurate Model For The User Termination Process" to show this process in a way that end users, executives, and programmers could understand.

The diagram—a Finite State Machine—also pointed the way to how to code a far simpler, clearer, and more flexible system than what they had.

(Note to Internet Explorer (IE) Users: The diagram may look a bit squashed. Consider viewing this page in Firefox, Chrome or Silk for a more accurate presentation of the diagram.)

An FSM models a process as a set of states, inputs to each state, and transitions between states. It shows a system at a functional level without regard to how a system is actually built. It can be a great tool for understanding what is happening.

I was asked by a project manager to prove to one and all that our "Consent-informed Attribute Release" system CAR could be of great use to OIDC implementers. This sequence diagram shows exactly how CAR could serve as the policy and decision service for an OIDC Authorization Server (show simply as "Authorization Server" in the diagram).

Sequence diagrams show in detail the message flows and operations among a series of interacting systems. They allow engineers to reason about systems that have already been built—or that are being proposed. They are fantastic for helping uncover security holes in a design.

I've found holes in two commercial security systems by creating sequence diagrams. The problems "popped out."

In my experience, sequence diagrams are also a highly underutilized tool. They aren't pretty, but they are hugely useful.

A significant challenge for medical and higher education institutions is assigning identifiers (IDs) to users coming into the institution. It sounds easy but two major problems are:

• assignment of a multiple IDs for the same person
• assignment of an existing ID to someone who should get a new ID.

Sorting out multiple IDs and incorrectly assigned IDs requires significant time—and also causes delays for users in getting crucial services (such as email). This architecture diagram shows my design for an identifier assignment system that provided for vastly improved accuracy and efficiency while still utilizing the institution's legacy databases.

In my architecture diagrams, I show the components of a distributed system and how they interact. Generally, this type of diagram serves both an executive who wants to get a feel for the system's components as well as an engineer who wants to dig in a bit into the component interactions.

At a higher education institution, identity specialists were responsible for "resolving" cases where an incoming user was given a new identifier when the user's demographic information partially matched the information of a person who'd previously been associated with the institution. This situation was called a "force create" of an identifier.

The identity specialists had to use two separate applications and do manual calculations as part of figuring out whether the new identifier was correctly assigned. In the case where it wasn't, the specialists used ad hoc methods for tracking communications with other administrators and the user. It was a time-consuming and error-prone process, particularly when more than one specialist was involved.

I architected a new application (using backend services I'd previously architected) that greatly streamlined the process for the identity specialists. As part of the design, I created "mockups" of each screen of the new application.

The mockup below presents a near final step of a particular de-duplication process: The mockup shows the "Force Create Entry" for a new user named Susan Jones, and the "Possible matches" that were rejected by the person who initially processed Susan Jones's demographic information. The mockup shows the point in time where the specialist has already selected the "Non-duplicate ID" button, and is now being asked to "Confirm" that choice. The mockup also shows that the identity specialist has the ability to add in note about their actions via the "Add Work Note" button near the bottom of the mockup.