Setting Realistic Expectations for Software Availability

Software availability should be discussed in terms of the work the business needs to complete. A demand that the product “never goes down” does not create a practical operating plan. A realistic expectation identifies important tasks, acceptable interruption, response arrangements, and the costs of supporting those commitments.

Define availability from the user's perspective

A service can be reachable while a critical task fails. Customers may sign in but be unable to submit an order. Staff may view records while changes cannot be saved. Decide which completed activities represent availability for your business rather than relying entirely on a general website check.

Consider a hypothetical ticketing company. Its principal commitment is that customers can purchase a valid ticket during a sales window. An internal monthly report has a different urgency. Treating these functions identically may direct expenditure away from the point where interruption has the greatest consequence.

Google's guidance on service-level objectives discusses targets for service behavior and their measurement. For a business owner, a service-level objective means a defined operating target. It should describe a useful result and a way to measure it, not merely an impressive percentage.

Identify the periods that matter

A short interruption during peak demand may have different consequences from the same interruption during quiet hours. Explain sales windows, daily deadlines, and time-sensitive commitments to the provider. A monthly average may conceal an event that caused substantial operational disruption.

For the ticketing company, the opening of a popular event's sales could deserve special preparation. The owner needs to describe expected demand and the consequences of a failed purchase. The developer then assesses the options and uncertainties rather than extrapolating from ordinary usage alone.

Discuss planned maintenance separately from unexpected failures. Decide how advance notice will work and when planned changes can occur. Do not assume that a product must be modified without any interruption under every circumstance. The appropriate arrangement depends on the work, technical options, and resources available.

Understand the cost of stronger expectations

Higher availability can require additional engineering, operating services, monitoring, and support. Ask what changes would be needed to meet your desired target and what continuing costs follow. Compare those costs with the business consequences rather than choosing the highest possible target automatically.

The UK Government's availability guidance addresses keeping services available and preparing for failures. Its relevance is the need for a deliberate operating approach. It does not establish that a particular architecture or spending level suits every business.

Ask about external dependencies. A payment service, email supplier, or network connection may affect the customer journey even if the custom product itself is functioning. The provider should explain those boundaries and possible alternatives. A claim about one part of the system should not be interpreted as a guarantee of the whole process.

Agree measurement and response together

Define how availability will be measured and how partial failures are treated. Clarify the period covered, the affected functions, and any exclusions. If a percentage is used, ask for its practical meaning in the company's operating context before accepting it as sufficient.

Also agree who notices a problem, who investigates, and how the owner receives updates. A measured target does not itself establish a response commitment. Confirm the actual support scope and the business actions available if a critical task is unavailable.

Review operating evidence after launch. If interruptions cluster around one task, investigate that task rather than relying on an overall average. If the business changes its commitments or grows into new markets, revisit the target. Availability expectations should evolve with the company instead of remaining attached to launch assumptions indefinitely.

Apply Holism's approach to proportionate reliability

Holism combines AI-assisted development with a human developer and a Software Product Line of reusable capabilities and consistent rules. The developer can assess reliability choices in the context of the business's critical workflows. AI supports implementation and iteration; professional judgment weighs consequences and operating tradeoffs.

The owner supplies customer commitments, peak periods, and acceptable alternatives. The developer explains what meeting those expectations would require and where uncertainty remains. Specific availability or response commitments need agreement; Holism's delivery model alone does not provide a guaranteed percentage or universal support arrangement.

A realistic availability expectation is measurable, commercially justified, and supported by a workable response process. It gives the business a basis for deciding reliability expenditure without confusing an absolute aspiration with an achievable operating commitment.