Down to the sheet

Sheet 02 of 03Origin BournemouthDatum the findings note

Technical assessments

What is examined when a line-of-business system is read before anything is altered, the order the reading runs in, and the shape the written output takes by the time it is handed across.

Why this sheet exists separately

An assessment is the only piece of work here that produces no change to a running system, which is exactly why it is described on its own sheet rather than folded into the integration and automation work that follows from it.

Registered office 55 Muscliffe Lane, Bournemouth, BH9 3NF, United Kingdom

Service desk servicedesk@alpinetechnica.website

01

What the word system is doing in these pages

The word is doing narrow work here, and the narrowness is deliberate. A line-of-business system means the application the working day passes through: the order book that the counter staff key into, the stock ledger the buyers argue with, the dispatch board that decides which van leaves first. It is the piece of software whose unavailability stops the trade rather than inconveniences it.

The office suite sits outside that definition even though it is often the loudest thing in the room, because mail, spreadsheets and documents are maintained under an entirely different arrangement and fail in an entirely different way. Where a spreadsheet has quietly become part of a working process, however, it is inside the frame, and it is recorded as the interface it has turned into.

Drawing the boundary in writing at the start is what keeps an assessment finishable, since a description that widens to include every machine on the premises stops being a description and becomes an inventory nobody reads twice. The systems inside the boundary are named in the first paragraph of the note, and anything that turned out to sit on the line is named there as well, together with the reason it was placed on the side it was placed on.

02

The order the reading runs in

The reading happens in four passes, and the order of them carries most of the value, because the interesting material is almost never a single fact but the distance between two accounts of the same fact. A pass that begins with the machines would learn everything except what anybody believes to be true, and a pass that begins with the people would learn everything except what is actually running.

The four passes, what each one reads, and what it leaves behind in the note.
PassWhat is readWhat is written down
The declared picture The account given by the people who use the system daily and by whoever is understood to look after it. A statement of what the system is held to do, in the words of the people who depend on it.
The running picture The hosts, their versions and support status, the scheduler, the job list, the log locations and the account list. An inventory of what is present and running, dated at the point it was read.
The edges Every point at which a record enters or leaves: files, endpoints, views, queues, and anything a person carries across by hand. A register of interfaces, each with its direction, its format and its frequency.
The differences The places where the first pass and the second disagree, together with anything found at an edge that nobody described. A list of the discrepancies, each one attached to the person who is able to settle it.

The fourth pass is the one that pays for the other three. An export that a supervisor has been e-mailing on a Friday for years, a report nobody recognised, a scheduled task running under a leaver’s account — these surface at the join between what was described and what was found, and they are the items that go on to move an integration estimate more than any hourly figure does.

03

The surfaces that get read

Six surfaces are read on every assessment, and each of them is written into the note whether or not anything notable was found there, because an entry recording that a surface was examined and looked ordinary is worth having when the same question is asked again a year later.

  • Hosts and versionsThe machines or instances the application runs on, the operating system and database versions underneath it, and whether each of those is still inside its supported life. A component past that point is recorded on sight rather than argued about, since the consequence of it is a matter of fact rather than of opinion.
  • Accounts and accessWhich accounts can reach the system, what each of them is for, and which of them belong to a person rather than to a service. Shared logins and accounts belonging to people who have left are noted as findings in their own right.
  • Integration pointsEach place a record crosses the boundary, with its direction, its format, its frequency and the thing on the other end. A point that only moves twice a year is still a point, and it is the one most likely to be forgotten when a version changes.
  • Scheduled tasksWhat already runs to a clock, under which account, inside what window, and where it writes its output. Two schedulers doing overlapping work is a common finding, and it is recorded as one entry rather than two.
  • DependenciesThe pieces that would break if something else moved: a fixed address written into a configuration file, a mapped drive, a certificate, a licence tied to a hostname, a font or a report template held somewhere unexpected.
  • Observed failuresAnything that went wrong while the examination was running, described as it happened rather than as it was later explained. A failure witnessed directly is the most useful paragraph in the document.
04

What a finding looks like once it is written down

A finding is a small structure rather than a sentence, and it carries four things in a fixed order so that it can be read by somebody who was not standing in the room when it was made. The fixed order is what lets a reader skim a note of sixty entries and stop only at the ones that concern them.

The four parts of a finding, and the question each part answers.
PartThe question it answers
The observationWhat was seen, stated plainly and without an adjective attached to it.
The locationWhich host, account, interface or job it was seen on, named exactly as that thing is named on the system itself.
The dependencyWhat else relies on it, so that the size of the finding can be judged rather than asserted.
The consequenceWhat would be true if it moved, failed or expired, written as a description of a state rather than as a warning.

A finding carries no severity rating. A rating compresses the three parts above into a single coloured word, and the compression is precisely what a reader needs to see undone when they are deciding what to do about it.

05

What the note contains when it is handed across

The document that leaves at the end of an assessment is a description rather than a proposal, and its contents are settled in advance so that its usefulness does not depend on how interesting the week turned out to be. It opens with the statement of what the system is held to do, followed by the boundary and the reason each borderline item was placed where it was placed.

After that come the registers: the host inventory with versions and support status, the account list with the purpose of each entry, the interface register with direction and frequency, and the scheduled task register with windows and log locations. Each register is a table rather than prose, because a register is consulted rather than read, and a reader consulting one under pressure should not have to parse a paragraph to find a hostname.

The findings themselves follow, in the four-part form above, grouped by the surface they were found on rather than by how serious anybody thought they were. The note closes with the open questions, each attached to the person able to settle it, so that the document states plainly what it does not yet know and who holds the answer.

The client keeps the note, and a copy is retained by Alpine Technica Ltd under the terms set out on the field reference sheet, which lists the fields that copy carries and what ends its retention.

06

Where an assessment stops, and what follows it

An assessment stops at description. Nothing is reconfigured, no credential is changed and no job is added while it is running, because the value of the note rests entirely on it being an account of the system as it stood rather than as it was left. Where something is found to be actively failing, it is reported at the time rather than held back for the document.

What follows is planned against the note rather than against a conversation. The interface register becomes the count of joins behind the effort arithmetic on the front sheet; the scheduled task register becomes the starting list for automation work; the host inventory and the observed failures decide which thresholds are worth writing; and the dataset figures feed the retention schedule. Each of those is described, with its own arithmetic shown, on the front sheet.

An enquiry about an assessment becomes answerable once it names the application, says what the work is eventually meant to change about the way that application is used, and identifies the person inside the organisation who keeps it running from day to day. The service desk address below reaches the people who carry out the work described here.