Greyquill

Modernisation

Mapping an estate before you touch it

An architecture diagram usually shows the system somebody set out to build. Before you change any of it, you need a record of the one that is actually running.

One page, the whole method.

Six columns per system

Six columns will answer the questions you actually end up asking. Maps that try to capture everything tend not to get finished.

The six fields recorded per system A system record card with six fields: what it does in one business sentence, a named business owner and technical owner, every inbound path including manual ones, every outbound path, what it runs on and whether that is supported, and what happens if it stops. One system one row in the map What it does one business sentence Who owns it two named people What goes in including by hand What comes out including by hand What it runs on and is it supported If it stops blast radius, downtime You are finished when you can pick any system and say, without checking, what breaks if it stops. How long One to three weeks for a mid-sized estate. Past a month, the map has become the project. Stop when you can name the first seam and defend it.

Inbound and outbound mean every path, including manual uploads, email attachments, a shared folder, and somebody rekeying from a screen.

What interviews will miss

People will tell you about the systems they work with. The ones that cause trouble later are usually the ones nobody has thought about in years, so you have to go looking.

Firewall, load balancer, DNSShows what is actually talking to what. Chase down anything nobody can account for.
Scheduled jobs and cronBatch work is rarely documented, and it is often where the surprises are.
Database accountsWhich account connects, and from where. One system reading another's tables directly turns up more often than people expect.
Ask operationsAsk what they do by hand every month. Those spreadsheets carry more load than anyone realises.
Certificate and licence renewalsSomebody pays for each one. They can usually tell you what it is for.

Ordering the work

Consequence against fragility A two by two grid. The horizontal axis is fragility, the vertical axis is consequence. Systems high on both are where money is spent eventually but are the wrong first seam. The right first seam sits in high consequence and low fragility, or high fragility and moderate consequence, where there is real pain and a small blast radius. Fragility supported, understood unsupported, nobody left who knows it Consequence regulatory inconvenience Where the money goes eventually, and almost never first most coupled, most political heat Start here real pain, small blast radius prove the method, then go up watch, but not urgent leave it alone

The system's owner can answer both without going away to look anything up. Anything high on both axes will need attention eventually, though starting there is risky. Those systems tend to be the most coupled, and a first attempt that stalls is hard to come back from.

What to resist

Starting with a tooling decision. Mapping often stalls while a discovery platform is evaluated and procured. You learn more from a spreadsheet with the six columns filled in than from a platform nobody has populated yet.

What you use it for afterwards

Choosing the next seamIn most organisations it is the one place blast radius has been written down.
Audit and due diligenceThese requests arrive at short notice, and they tend to ask which systems process a given category of data.
DecommissioningBefore you switch something off, the map tells you what still depends on it.

Keeping it current is a small standing job. Attach it to something that already happens, such as a change approval step, so it does not rely on a review nobody attends.

Greyquill
greyquill.io/dc/services/estate-map.html
Greyquill Software

Estate map, field guide

What to write down before a modernisation starts.

Six columns per system

What it doesOne business sentence. If nobody can write one, record that.
Who owns itA named business owner and a named technical owner. Not a team.
What goes inEvery inbound path, including uploads, email, shared folders, rekeying.
What comes outFiles, APIs, reports, direct database writes, anything copied by hand.
What it runs onLanguage, framework, version, host, and whether any is out of support.
If it stopsBlast radius in plain words, and tolerable downtime.

What interviews will miss

  • Firewall rules, load balancer config, DNS
  • Scheduled jobs and cron tables
  • Database accounts and where they connect from
  • Ask operations what they do by hand each month
  • Certificate and licence renewals

Order on two axes

  • Consequence. Down for a day: inconvenience, revenue, or regulatory?
  • Fragility. Supported? Understood? Last successful change?

Anything high on both will need attention eventually, though it is rarely the right place to start. Begin where there is real pain and a small blast radius.

Finished when

You can pick any system and say, without checking, what breaks if it stops, and you can name the first seam and defend the choice. One to three weeks for a mid-sized estate. Past a month, the map has become the project.

Resist

Evaluating a tool firstA spreadsheet with six columns filled in is worth more than a platform with nothing in it.
Starting at the worst systemProve the approach somewhere smaller, then come back to it.

Greyquill Software modernises systems that cannot be switched off, one seam at a time, with the evidence to show it worked. greyquill.io