Short answer
#The system
Ledgerline takes orders from about forty wholesale customers and passes them to a warehouse. It was built by an agency ten years ago, extended by three freelancers since, and the last of them stopped answering email in the spring. The company that owns it bought it with a business, and the new owner has a server, a repository and a contract with a hosting company. Nothing else.
#What the first analysis establishes
| Part | What is recorded | How it is known |
|---|---|---|
| Ordering application | Customer login, order entry, invoices as PDF | Observed in the code |
| Database | Orders, customers, price lists, and a set of tables no code in the repository reads | Observed for the tables in use, inferred for the rest |
| Reporting tool | Reads the same database directly, with its own credentials | Inferred from a connection setting and those unread tables |
| Partner import | Fetches a price file from a partner over FTP every night and overwrites the price list | Observed in a scheduled script |
| Warehouse export | Sends confirmed orders to the warehouse by email as an attachment | Observed in the order confirmation code |
Two lines here are worth more than the rest. The reporting tool reads the production database with credentials that live outside the repository, so changing that database can break somebody else without warning. And the price list is overwritten every night from a partner file, so a wrong file would reprice every order the next morning.
#What it says it did not look at
- Examined completely. The ordering application and the scheduled scripts in the repository.
- Examined in part. The database, whose structure is known but whose unread tables are not explained.
- Not examined. Anything on the server that is not in the repository, including the crontab itself and the reporting tool.
This is the part that keeps the picture honest. The analysis read what was in the repository. A job that runs on the server but was never committed is not in the picture, and the picture says so instead of implying that the list of scheduled work is complete.
#The questions, in order
- Who uses the reporting tool, and what breaks for them if the database changes?
- What does the server run on a schedule that the repository does not contain?
- What happens to the price list if the partner file is empty or malformed?
- Does the warehouse still read the emailed orders, or do they arrive somewhere else now?
- What are the unread tables, and can anybody say whether they are still filled?
Questions one and four are for people: the finance team and the warehouse. Two and five can be answered by giving the next analysis access to the server configuration and looking at the tables. Three can be answered by reading one script more carefully, which is what the next analysis is asked to do.
#The next two analyses
The second analysis is pointed at the import script and the server configuration that the owner added to the repository. It establishes that an empty partner file empties the price list, and finds two scheduled jobs that were never committed. The structure of the system did not change at all. Everything in the comparison is newly learned, and the comparison says exactly that, rather than reporting two new jobs as if somebody had just added them. The third analysis, after a fix to the import, shows one change in the system and nothing else.
#What the owner does with it
The owner of an inherited system rarely needs a full description first. They need to know where the system can hurt the business without warning, and who to ask about the parts nobody can explain. The first analysis gives them the shared database, the nightly overwrite and five questions in order. The next two turn the most dangerous of those into facts, and they do it without anybody who built the system being available.