Skip to main content

CompTIA Security+View full course outline

Technical and Business Considerations in Architecture(OBJ.3.1)

By Jonathon Eades — Founder & IT InstructorUpdated

10 min read

A payroll company has 14 months before its servers reach end of support. The CFO wants the cheapest option, the operations manager wants the one that never goes down, and the sales team has just promised European customers that their employees' data will stay in Europe. Each of those wishes is an architecture requirement, and they don't all point the same way.

On the CompTIA Security+ SY0-801 exam this sits under objective 3.1, which expects you to compare the security implications of different architecture models, including the technical and business considerations that drive the choice. This lesson defines each consideration and applies it to that one decision, so you can see how they eliminate and rank options.

Architecture choices trade one strength for another

No architecture is the most secure in every respect. On-premises gives control but makes you responsible for everything; SaaS removes most of the technical work but also most of the control. The security professional's job in an architecture decision is to make those trade-offs visible in terms the business can weigh.

Here is the decision this lesson works through. Larkspur Payroll runs payroll for 1,200 small businesses. Its platform holds about 180,000 employee records in the U.S. and, after a recent acquisition, 30,000 in Germany and the Netherlands. The records include names, tax IDs, bank account numbers and salaries. Everything runs in a server room at the Ohio headquarters on hardware that leaves vendor support in 14 months.

Three options are on the table:

  • Option A: refresh the on-premises servers in the same room.
  • Option B: rebuild on a public cloud using IaaS and managed PaaS services, defined in infrastructure as code, in one U.S. region and one EU region.
  • Option C: move to a SaaS payroll engine whose vendor hosts in U.S. data centers only.

Availability, resilience, and ease of recovery describe how a design survives failure

Availability is the share of time a system is up and usable when people need it, usually stated as a target such as 99.9 percent, which allows about 8.8 hours of downtime a year. Resilience is the design property that produces availability: the ability to absorb a failure through redundancy and failover, or keep working in a degraded state, instead of stopping. Ease of recovery is how quickly and simply the system can be restored after something does stop it, whether that is a failed disk or ransomware. The recovery metrics that put numbers on it are covered in the resilience and recovery section.

For Larkspur, availability matters most twice a month. If the 48-hour pay run fails, 210,000 people aren't paid on time.

Option A has one server room and one building, so a fire or long power cut stops everything. Its last recovery test restored from tape to replacement hardware in three days. Option B can spread the application across several availability zones, which are isolated groups of data centers within one region, and rebuild the environment from code and snapshots in another region within hours. Option C's contract promises a 24-hour recovery time, and Larkspur can't test it independently; it relies on the vendor's audit reports.

This lesson is part of ExamWizardz Pro

Unlock every lesson, unlimited practice tests, and the AI tutor.

See Pro pricing

or start with a free account

Test yourself on this topic: free Architecture Models practice questions — no account needed.