Intended workflows

This reference architecture was designed based on a specific set of intended workflows that users of such a system would be completing on a regular basis. A workflow in this case refers to the series of tasks that are performed by a user (or users) of the system to achieve a specific business process or objective.

For example, a workflow performed on a parcel fabric to create a feature would include tasks such as:

  • Search for the parent parcel
  • Zoom to the location of interest (LOI)
  • Create a parcel fabric record
  • Create the feature via COGO (Coordinate Geography)
  • Build the parcel
  • Align the parcel to surrounding features
  • Validate the topology
  • Reconcile and post data to a feature service

Workflows can vary significantly from deployment to deployment and the workflows used in this reference architecture are intended to represent common versions that are straightforward and general enough to represent many different potential deployments.

Workflows are an integral part of the reference architecture definition as they help define the requirements that the architecture needs to meet. Additionally, clear, and specific workflow definition helps to:

  • Define the necessary system functionality and the appropriate applications that end-users will interact with.
  • Inform system requirements around architecture pillars like performance, reliability, and security.
  • Inform physical system requirements such as CPU, memory, storage, and networking, which directly impact machine types, sizes, and hardware configurations.

To ensure that workflows are useful for system design purposes, they need to represent real user experiences. This reference architecture was designed with a focus on the editor persona along with use cases for a general user persona. With these audiences identified, the following workflows were selected and developed:

Editor persona

Record-driven workflows

  1. Create a feature by entering in new survey points or lines.
  2. Conduct a boundary adjustment with the Align, Split, or Merge tools. Take existing feature(s) and change their legal boundaries, retiring the underlying parcel(s).
  3. Attribute adjustment – Modify non-spatial attributes, like a transfer of title.
  4. Re-plat – Manage changes to the property or properties where a new survey was created.

Quality-driven workflows

  1. Conduct spatial quality analysis, such as running a least squares analysis.

General user

  1. Query features - such as searching for parcels and displaying historic chain of title.
  2. View and interact with the parcel fabric - as an appraiser would when performing a value analysis within a neighborhood.

An implementation of this Parcel Management System reference architecture may include other types of workflows not listed here, such as mobile data collection, which would introduce additional architectural considerations. See related system patterns, such as the data editing and management system pattern, for more information.

In this topic