LastDevOps

Fractional CTO for healthcare and hospitality SMEs.

View the Project on GitHub snegas/lastdevops.com

Home · Method · Healthcare · Hospitality · Engagement · About · Book a discovery call

Assess: technology gap and risk review

Two weeks. At most three workloads. A board paper that says what is true, what that does to a patient, a guest, or cash, and which decisions are already on the table.

This is a set of conversations against evidence. It is the zoomed-out view of the technology landscape and the specific view of how that landscape lines up with business outcomes. Both altitudes are required. A tool list is neither.

Learn hands over the stream, the baseline, and three constraints. Assess uses that charter. It does not redraw the company.

The pattern for the workload sessions is the AWS Well-Architected review: a lightweight process, hours rather than days, a conversation rather than an audit, aimed at the issues that change the customer’s experience of the workload. The framework’s review process says so directly.

What two weeks can settle

AWS’s unit is the workload: the components that together deliver business value, which is usually the level of detail leaders already talk about. Cap the engagement at three workloads that carry the outcomes the owner named on day 1. Everything else is listed as not reviewed.

Use the standard Well-Architected question set. Building a custom lens is a separate project. For a DevOps-shaped SME, spend the question time on Operational Excellence and Reliability. The six pillars are operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. In ten days the security work is a narrow slice: where PHI or card data sits, who can see it, whether you would know, and whether you can restore. The rest of security is named as not assessed.

Operational excellence questions worth asking in the room:

Reliability questions:

When the EHR or the PMS is vendor-hosted and you cannot see the account, write “vendor-operated, not inspected.” A high-risk issue, in AWS’s terms, is a foundational practice whose failure can seriously hurt the business. A medium-risk issue is an enabling practice. Use those labels only after you have walked the question. The board page leads with the harm and the owner, not with a heat map.

Ten-day schedule

One person writes the notes the same day. Each day ends with a short evidence list: claim, artifact, or “still verbal.”

Day 1. Outcomes and the cut line. Room: owner, the operator (practice administrator or general manager), and whoever watches cash. Write three to five outcomes in their words. Visits completed when the EHR is down. Charges that become paid claims. Rooms sold once. A guest message answered from the system the front desk actually uses. Choose up to three workloads. Write the not-reviewed list in the room and leave it in the report.

Day 2. Both altitudes. Morning: the operator plus one frontline person. Walk one real case from the previous day and name every system touched. Afternoon: the person who administers those systems draws components, the owner of each, what talks to what, and where the record or the card number lives. Mark every “we think it is backed up” as a claim until someone shows it. The Well-Architected facilitation kit is a whiteboard and an action list of facts to check outside the meeting.

Day 3. Delivery, against artifacts. Room: the person who changes production. If that is an MSP or a vendor, they are in the room or on the call. Score the MinimumCD activities and the short DORA set below from the repo, the pipeline, and the last ten production changes. If there is no software team and the product is vendor SaaS, score the same ideas against configuration and vendor releases: one path to change production, a place to try the change first, a way to undo it, and a rule that a broken change stops the next one. Do not invent a CI score for a company with no build.

Day 4. Two workload conversations. Hours, not a day, per workload. The people who operate it that day. Ask the OPS and REL questions above. A third workload only if day 2 showed it carries an outcome and the action list is still short.

Day 5. Harm. Room: owner, clinical lead or guest-operations lead, finance, and the technical person. For each candidate issue, write one harm class before any number: patient or guest harm, revenue leakage, compliance exposure, single-person bus factor, vendor lock-in, or PHI or payment data. Then answer: customer impact, business impact, whether the risk can be removed or only mitigated, who owns the risk, who owns the fix.

Healthcare, in-scope systems only. HHS says a risk analysis is the first step of the HIPAA Security Rule safeguards, that it must cover all ePHI, and that it records where ePHI is, threats, vulnerabilities, safeguards, likelihood, impact, and corrective actions. Check whether that document exists and whether these systems appear in it. Say in the report that a sample of three systems is not the practice’s risk analysis.

Hospitality. Draw the cardholder data environment and compare it to the last SAQ. Details are on the hospitality page. NIST CSF 2.0 is a coverage check, not a work program. For each of the six Functions — Govern, Identify, Protect, Detect, Respond, Recover — write a named owner and one recent example, or “no example.” Do not assign a CSF Tier.

Day 6. Debt register. Room: the people who pay the interest. The biller, the front desk, the developer or the MSP. Ward Cunningham’s line from 1992 still holds: shipping first-time code is like going into debt, and every minute spent on not-quite-right code counts as interest. Eric Allman’s useful extension for a board is that interest is the delay paid by the next person who touches the system, that a system one person understands is debt, and that a debt backlog is communicated in dollars. Columns: the item (how the system works versus how the work now works), interest per month in hours, incidents, or dollars from a named window, the outcome it blocks, and who feels it. If the interest was not counted, write “not counted.” No story points.

Day 7. Decision records for choices already live. Cap at three. Replace or keep the EHR or PMS. Portal inside the record or beside it. Billing in-house or a revenue-cycle vendor. Channel manager. Guest messaging. An AI feature. Michael Nygard’s record is one or two pages: title, context as forces, the decision in the form “We will …”, status, and consequences including the bad ones. Add four fields this engagement needs: the options, including do nothing and turn the vendor’s feature on; reversibility, using AWS’s one-way door and two-way door; total cost, meaning licenses, implementation, the interest you keep paying, and the people required after go-live; data ownership and exit, meaning the export you can actually produce and what breaks on the way out.

For an AI feature the options are: call a model API, fine-tune, or enable the vendor’s feature. Write down where the note or the guest message goes, whether you can leave with the prompts and the test set, and who owns a wrong clinical or guest-facing answer. A vendor feature you can switch off, with a human still authoring the note, is a two-way door. A fine-tune you cannot export is a one-way door.

Day 8. Close the action list. No new workshop. Read the last incident, the last backup restore, the last deploy or vendor release note, the export terms, the admin account list, and one week of charges or one day of rooms and rates. A fact that is still only spoken stays “reported, not evidenced.”

Day 9. Write. Every finding line has observation, evidence, harm class, outcome blocked, owner, and what would change the conclusion.

Day 10. Readout. The same people as day 1, plus anyone you are asking to accept a risk. Leave with accepted risks, funded items, and the unknowns the board is choosing to leave unknown. The roadmap is not in this paper. That is Translate, and it waits on Strategy.

Scoring that stays inside the evidence

Score each item met, not met, or not observed. “Not observed” is a result. It is not a pass.

The DORA capabilities a ten-day visit can score from evidence are trunk-based development, continuous integration, deployment automation, and whether the team can change and deploy this system without another team’s release. DORA’s bar for trunk-based development is three or fewer active branches, merges to trunk at least daily, and no code freeze. “If you have to create a ticket and wait for someone to prepare an environment, you don’t have a fully automated deployment process” is their deployment-automation test. A two-week visit can report a sample. It cannot claim the multi-year research result that these capabilities predict organizational performance.

MinimumCD’s floor, from minimumcd.org, is the delivery checklist: continuous integration, the pipeline as the only way to deploy, a pipeline verdict that a person does not overrule, an immutable artifact, stop-the-line when the main pipeline is red, a production-like test environment, and rollback on demand.

Where a change would move an outcome

Three items maximum, at the end of the report. Each one names an outcome from day 1, a change the company already knows it needs and cannot make, the evidence of the block, and the decision record that would remove the block. AWS’s operational-excellence material makes the cut: managed services exist so a small team can spend its time on the work that differentiates the business. A missing feature the whole industry lacks is a wish. It does not go in this section.

How an assessment fails

A tool inventory. A table of logos and renewal dates with no outcome, no owner, and no checked fact. Those rows can sit in an appendix labeled “systems named.” They are not findings.

A maturity model with no business link. A 1-to-5 DevOps level, a CSF Tier, or a DORA performance cluster produced from interviews. A level number that does not change a denied claim, a downtime, or a double-sold room is not an input to strategy.

Boiling the ocean on security. Every CSF subcategory, every HIPAA specification, or a penetration test inside the ten days. The corrective action, when the risk analysis is missing, is to go and do the analysis. It is not to finish it on day 5. The same cut applies to reliability: two workloads deeply, the rest named as not reviewed.

What Strategy receives

Strategy receives the outcomes, the workload diagram, the delivery gaps, the risk and debt registers, the proposed decision records, and the explicit list of what this assessment does not say. It does not receive a roadmap or a pillar scorecard.

Sources

Book a discovery call

The call is to decide whether this engagement fits. The answer can be no.