Evaluate investment and architecture choices

Compare outcomes and total cost

A business case should identify the problem, the affected business outcome, feasible alternatives, expected benefit, cost, assumptions, and the decision required. Include an option to continue with current arrangements so the consequences of inaction are visible. If a requirement is mandatory, evaluate how to meet it rather than treating noncompliance as an ordinary cost-saving choice.

Total cost extends beyond the purchase price. Include integration, migration, training, staffing, support, recurring fees, and eventual retirement. Separate estimates from observed data. Where loss estimates are uncertain, show a reasonable range and explain which assumptions most affect the decision. A precise-looking return figure is not reliable merely because a spreadsheet calculated it.

Understand the architecture relationship

Enterprise architecture connects business capabilities, information, applications, and technology so that change can be planned coherently. Security architecture describes how security requirements and design decisions fit those relationships. This lesson introduces the distinction; it does not claim a complete mapping to the revised CISM architecture objectives.

Consider a customer portal that depends on a shared identity service, payment provider, and order database. A local improvement to the portal may leave a shared dependency as the main failure point. Map trust boundaries, data flows, administrative access, and recovery dependencies before deciding where a control belongs. Engage the relevant architects and service owners early enough to influence design.

Plan how the investment will work

For each option, ask who will operate it, which existing services it depends on, how failure will be detected, and how the business will know it helped. An identity service may simplify access management while also concentrating availability risk. A design decision should make that tradeoff explicit and include proportionate resilience arrangements.

Present leadership with a recommendation, meaningful alternatives, residual exposure, an accountable sponsor, milestones, and a plan to assess benefit. Review after implementation. If expected benefits did not appear, investigate whether the original assumptions, implementation, or adoption were wrong and adjust the plan.

Use an architecture decision record

For a proposed shared identity service, write down the affected business capabilities, the data and trust boundaries, the decision owner, and the options considered. Compare availability, administrative access, integration effort, recovery dependencies, and operating capacity. Record why an option was chosen and which conditions would require reconsideration.

For example, central sign-in can improve consistency while creating a shared availability dependency. A documented decision might require independently tested recovery access, monitoring for privileged changes, and a planned review after adding another critical application. These are illustrative design choices, not universal controls for every service. An architecture diagram is evidence of the design; testing and operational records are needed to evaluate implementation.

Review enterprise and security architecture together

Enterprise architecture helps explain how business capabilities depend on information, applications, and technology across the organization. Security architecture adds the protection requirements and design choices needed across those relationships. Reviewing only a server diagram can miss a critical business dependency or a supplier-held information copy.

For a new customer portal, trace customer information across the portal, identity service, support tools, and suppliers. Specify trust boundaries, permitted administrative actions, required recovery capability, and the evidence needed to accept the design. Consider least privilege, separation of duties, protection across multiple layers, and failure behavior where they address the stated exposure. These are design considerations to assess, not a mandatory product list.

Record alternatives and tradeoffs, then verify the implemented design through appropriate testing and operational evidence. A shared identity service can simplify control operation while concentrating availability risk. Review the architecture again when a major dependency, information flow, or business objective changes.