Before building anything, we must collaborate on modeling your organization’s activities. In doing so we develop a vocabulary for your system (one of the two hard things in computer science, as the saying goes, is naming things), aiming for it to be maximally thorough and unambiguous. As Eric Evans explains in his 2003 book Domain-Driven Design:

It is vital that we play around with words and phrases, harnessing our linguistic abilities to the modeling effort, just as it is vital to engage our visual/spatial reasoning by sketching diagrams.

Our method is what we call BOND (Business Operations Notation & Development). Within BOND we practice what we call Role & Port Modeling, as roles and ports represent the twin aspects of a system: Roles for who can do what, and Ports for where they do it.

We capture ideas for the blueprints by entering them into the Engaging OS platform itself, fulfilling one of the holy grails of software: being an executable model.

Our basic unit is the business operation. In Role & Port Modeling, as we think through your organization’s work, we jump around the constituent aspects of business operations, namely:

• Positions capture everybody’s various job titles within the organization or part thereof that the system is intended to handle (ie, the subjects).
• Entity Attributes outline the characteristics of the widgets that the organization handles, mainly its products and services (ie, the objects).
• Actions & Statuses list the various verbs that people holding positions do to entities as part of their work, and what are the possible states of these entities 
• Conditions are the situations that determine whether the operation can actually take place. This is one of the places where functional complexity can grow 

As operations develop, we start seeing the necessary contours of the canvases where they are to be performed:   

• Screen Attributes & Wireframes sketch out the canvases where each user will perform these steps, and the ways to navigate to them.

Collections of business operations are gathered into processes, which are how the organization produces its work. Once Engaging OS has a collection of business operations defined as a process, it can generate on-the-fly process maps using the industry-standard BPMN notation, which serve as graphic documentation available to all stakeholders, ensure that the system is focused on delivering the required functionality.

Note that the entity attributes and actions and statuses, in demanding that every facet of the system be labeled, help us communicate about the system.

In addition:

• A maquette provides guidance for the intended look and feel of the interface.
• A binding narrative tells the story of the project utilizing all the terms generated in the other aspects of the model.

Any and all issues uncovered later during implementation are treated as continuations of the discussion of the model and may modify it and the resulting system. As Evans writes:

These models are never perfect; they evolve. They must be practical and useful in making sense of the domain. They must be rigorous enough to make the application simple to implement and understand.