My approach is straightforward:

I architect and build technology and security around the services your organization has to reliably deliver. Your service catalog is the starting point; then come the infrastructure and tools it takes to support it. Nothing more, nothing less. Most engagements begin with a renewal, a product, or a vendor; this one begins by establishing what you actually deliver and what it depends on. It may sound simple, and frankly what I offer is simple: IT systems that support and build your business. Not my billable hours.

The Core Question: What Services Must Your Business Reliably Deliver?

Before discussing systems, platforms, or vendors, together we define:

• What services must operate without failure?

• What outcomes are contractually or legally required?

• What would materially disrupt operations if unavailable?

• What regulatory or compliance frameworks apply?

I will then produce a set of IT Policies and Procedures as well as a Service Catalog. This set of documents will account for your business’s legal, regulatory, and contractual responsibilities, as well as provide a structured inventory of the business-critical services your organization depends on.

Examples might include:

• Secure clinical documentation

• Protected communications (email, messaging, telehealth)

• Identity and access control

• Secure data retention and retrieval

• Vendor-integrated workflows

• Infrastructure availability and network connectivity

Every technology decision maps back to one or more of these services.

How the work runs

Four phases. Each produces the artifacts the next one depends on. Every environment I've walked into has needed the first one, including the ones that looked fine from the outside.

One: Stabilize
Identify the handful of systems causing most of the unplanned work and give each a named owner. Eliminate standing admin access and shared credentials. Enable Phishing Resistant MFA everywhere, and SSO all the things. Write a one-page change policy and classify every change as standard, normal, or emergency. When it’s longer than a page, it gets circumvented. Make "what changed in the last 72 hours" the first troubleshooting question, every time. This phase costs almost nothing and returns the most.

Two: Inventory
The service catalog gets written: what you deliver, who consumes it, and what each service depends on. Identities, applications, endpoints, data locations, and vendors are documented and categorized against it. Applications are discovered from expense records and sign-in logs, not from a survey. Surveys are incomplete every time. Policy location is not actual location. This phase establishes what is actually true.

Three: Build Library
Written, tested procedures for the things that have to work: provisioning, deprovisioning inside 24 hours, credential reset, backup with a verified restore, endpoint baseline, patch response. The test is whether a critical asset can be rebuilt from documentation, on a known clock, without the person who built it. An untested backup is an assumption, not a control.

Four: Continual Improvement
A living control tracker that everything else is a view of. A mid-month exception report that includes unauthorized changes, new applications in use, security events, new customer or regulatory requirements. A month-end status against the metrics from every prior phase. Risk register reviewed every 30 days, open exceptions aged, access rights confirmed quarterly.

Where these four phases come from

The sequence is not mine. It comes from The Visible Ops Handbook (2004), which was the first serious attempt to describe what separates IT organizations that firefight from ones that don't. I have successfully applied this process for years.

Its diagnosis has aged well. Most unplanned work is self-inflicted, and change is the dominant cause. The controls that produce reliable service are the same controls auditors ask for, which makes compliance a byproduct of operational discipline and system design rather than a parallel project. And the order is not optional: you cannot inventory what keeps changing, standardize what you have not inventoried, or improve what you cannot measure.

Its instrumentation has not aged well. The book assumes an estate of servers in a room you own. Yours is SaaS tenants, identities, and endpoints.

So I rebuilt it. Same sequence, same tests, current tooling. This is mapped to ITIL practices and NIST CSF 2.0 so the work stands up to an audit, a vendor questionnaire, or an insurer. That mapping is available on request.

Utility and Warranty

Within ITIL, value has a precise meaning. A technology asset delivers value only when it provides both:

1. Utility “Fit for Purpose”

The solution:

• Enables business performance

• Supports contractual and regulatory obligations

• Removes operational constraints

• Improves efficiency or quality

If it does not materially improve a service outcome, it does not have utility.

2. Warranty “Fit for Use”

The solution must also reliably perform with sufficient:

• Availability

• Capacity

• Throughput/Performance

• Security/Continuity

If it fails under load, creates security exposure, or cannot meet uptime requirements, it lacks warranty, even if it is functionally impressive.