Alpine Technica Ltd

The findings note, and what is measured from it

A surveyor fixes a datum before any height on the sheet means anything, and the equivalent here is the findings note, a written description of the client’s own system produced before a single line of integration or automation work is specified. Every figure that appears later — a run window, an alerting threshold, a retention tier — is quoted against that note rather than against a recollection of a meeting.

Line-of-business system, in the sense used across this sheet, means the application the working day actually passes through: the order book, the stock ledger, the dispatch board. It is not the office suite around it, and the distinction matters because the two are maintained by different people and fail in entirely different ways.

The examination reads the surface a system presents to everything else: the hosts it runs on and the versions they are still supported at, the accounts holding access, every point at which data enters or leaves, the tasks already running to a schedule, and the dependencies that would break if any one of those pieces moved. A component past its supported life is recorded on sight, because a weakness whose consequences are already written down is easier to plan around than one that surfaces in the middle of an outage.

The order in which those surfaces are read, and the shape the written output takes when it is handed over, are set out on the technical assessments sheet.

assessmentfindings noteinventorydependenciescredentialsdocumentation

Joining two applications that were never introduced

Integration work here means carrying records between two applications bought years apart from different suppliers, with no expectation on either side that the other would ever exist, which is why the join has to be invented rather than configured. The available joins are ordinary enough: a file dropped over SFTP, a delimited or fixed-width export, a REST or SOAP endpoint, a read-only database view, or a queue that one side writes and the other drains.

The interesting part is never the happy path, which usually works on the first afternoon and then behaves for a fortnight; it is the set of conditions that arrive weeks later, once real volume and real people are attached to the join. Those conditions are handled by name in the specification, so that each of them can be tested deliberately before the join carries anything that matters.

The conditions named in an integration specification, and the countermeasure written against each.

Condition	What is written against it
A file lands half written	A size-and-marker check runs before the file is opened, so a truncated delivery waits rather than being read as a short one.
A delivery repeats	An idempotency key carried on every record means the second arrival updates the first in place instead of creating a twin.
Records arrive out of order	A sequence or timestamp on the record decides which version wins, so a late arrival cannot overwrite a newer state.
A column appears upstream	The reader is written to tolerate an unknown column and to record its appearance, since a widened schema is a change of fact rather than a fault.
A credential rotates	The failure is raised against the named owner of the join rather than retried, because no number of attempts will guess the new secret.
A batch commits in part	Anything unparseable is held in a quarantine folder with the reason it failed, and a replay path returns it once the cause has been dealt with.

Naming a condition is what turns it into something testable, and a condition that has been tested before go-live is one nobody has to diagnose at seven in the morning with a warehouse waiting.

integrationsftpschema driftduplicatequarantinereplay

Counting interfaces before counting hours

The unit of work in an integration is the interface rather than the system, because a single application joined at four points is four builds, four sets of named conditions and four things that can drift apart afterwards. Counting interfaces first is what stops a conversation that began with two systems from quietly becoming a conversation about eleven joins.

The figures below multiply out whatever is typed into them and nothing else. They stand for one build each, at whatever hourly figure the client has in mind for comparable work, and they become a plan only once the interfaces have been listed by name in a findings note.

Guide only — arithmetic, not a quotation

Systems, interfaces and hours

Systems to be joined

Interfaces on each system

Hours against one interface

Why the count of interfaces moves more than the hourly figure

An hourly figure is argued over once and then settles, whereas the interface count moves every time somebody remembers a report that is e-mailed out on a Friday or a spreadsheet that a supervisor maintains by hand. Both of those are interfaces in every sense that matters to the build, and both are routinely absent from the first description of a system, which is precisely what the findings note exists to catch.

interfacesefforthoursscopeplanning

Work that runs without anyone starting it

Automation here covers the tasks that used to occupy somebody’s Monday morning: an export assembled and sent, a reconciliation run across two ledgers, an overnight import, a report cut and filed where the auditors expect to find it. Whichever scheduler the site already runs is the one that keeps the new work as well, since a second scheduler is simply a second place for the answer to hide when a job has not appeared.

Run window is the span of clock time inside which a job is expected to have started and finished. It is written down because “overnight” means something different to the person who set the job and the person who finds the output missing.

Every job built carries four attributes in the runbook: a name stating plainly what it does, a role that owns it, the run window it belongs in, and the location of its log. A job that fails once is retried after a fixed interval, an isolated failure usually being a lock, a timeout or a network fault that has already cleared by the time anyone would have looked.

A job that fails a second time stops there, its input left untouched and the failure raised to the contact named against it. No third attempt follows inside the same window, because two failures in succession point at a changed condition — a rotated credential, a full disk, a moved schema — and further attempts only bury the evidence under identical log lines.

automationschedulingretriesrun windowlogs

What is worth waking someone for

An alert that fires often enough to be ignored has stopped being an alert and become weather, so the list is kept short and every condition on it carries its threshold in writing next to the job or host it belongs to. A threshold written down is a threshold that can be argued with afterwards, which is the whole difference between monitoring and noise.

The conditions that carry a threshold, and the form that threshold takes when it is written into a runbook.

Condition	The form the threshold takes
A job that has stopped	Two consecutive failures inside one run window, counted against the named job rather than against the host.
A queue that is filling	A depth agreed for that queue, set above its ordinary working peak so that a busy hour is not mistaken for a fault.
Free space on a host that matters	A floor in gigabytes rather than a percentage, because a percentage on a large volume can hide a very short remaining life.
A backup that reported nothing	Silence at the point the job was due, which is treated as a failure rather than as an absence of news.
A certificate approaching expiry	A fixed number of days before the expiry date, chosen so the renewal falls inside ordinary working time.

The contact reached, and the hours inside which the call happens, are written into the engagement rather than assumed; outside those hours an alert queues until the next working period and is found waiting rather than missed. The boundary of the list matters as much as the list itself, so the findings note records which side of it each piece of equipment falls on — end-user desktops, network hardware outside the agreed scope, hosted services run by a third party and anything without an agreed threshold all sit outside, and saying so in writing is what prevents an argument during an incident.

alertingthresholdson-callmonitoringscope

Custody of the written material

Everything described on this sheet produces text: the findings note, the integration specification with its named conditions, the job entries with their thresholds and owners, the retention schedule and the record of the handover session itself. That text is kept as one document per engagement, in a plain portable format, held somewhere the client controls and can still open when nothing belonging to this consultancy is installed anywhere near it.

The system belongs to the client’s staff before the work starts and still belongs to them afterwards, so each automated job in the runbook names the role that owns it — the finance supervisor, the warehouse lead, whoever it genuinely is — rather than naming a department. A job owned by nobody in particular is the one nobody looks at on the morning it stops.

A handover session walks that document page by page with the people whose roles sit against the entries, and any question raised is folded into the text while the session is still running, because a correction made a week later rarely finds its way back to the copy in circulation. Any elevated account created for the work is withdrawn once the last item is signed off, and the withdrawal is recorded beside the creation so the account list stays true after the consultancy has left.

A copy is retained by Alpine Technica Ltd for the period set out in the engagement, kept current whenever a threshold or an owner changes, and superseded whole rather than amended in the margin, so the version in circulation is always the version in force. What that copy contains, field by field, and what ends its retention, is set out on the field reference sheet.

handoverrunbookcustodyaccessownership

Reaching the service desk

Enquiries reach the company at servicedesk@alpinetechnica.website, and post at the registered office in Bournemouth printed at the foot of this sheet. An enquiry becomes answerable once it names the application involved, says what the work is meant to change about the way that application is used, and identifies the person inside the organisation who keeps it running day to day.

A first reply sets out what an assessment of that system would cover and what the resulting note would contain, since the note is the document every later piece of work is planned against. Work is carried out for organisations in Bournemouth, across Dorset, and remotely wherever the access allows the system to be read properly rather than described second hand.

contactenquiriesbournemouthdorsetengagement

Key to the bands on this sheet

Narrow the sheet by keyword

Eight blocks shown.

A / pressed anywhere moves the caret into this box; Esc empties it and restores every block. A block that is hidden takes its contour band with it, so the key above stays the only complete list of what the sheet carries.