FEDERAL ENTERPRISE OPERATIONS

The enterprise, layer by layer.

Follow work into cloud foundations. Bring results, evidence and cost back to the enterprise.

Reference basis

NIST CSF frames cybersecurity outcomes. RMF frames system risk and authorization. Selected controls and assessment evidence inform the discussion.

Sources & terminology Earlier architecture study

Set the context

Choose a relationship, a reference lens and a path.

Operating relationship

Program or OEM lens

Reveal how a published example relates to this architecture.

Follow a path

Select a flow, then step through its handoffs below.

Tools & executionReference notes

THE ENTERPRISE VIEW

Start at the service front door. Follow governed work down, then observations and evidence back into enterprise operations.

01

Service front door

Request · coordinate

02

Decisions & access

Govern · permit

03

Orchestration & execution

Plan · release · operate

RETAINED SERVICES

Existing operating team

On-premises environmentCompute · storage · network
Existing element management

CLOUD FOUNDATIONS / GSS

Enterprise shared services

Cloud resources & native managementIdentity · network · compute · storage
Provider APIs & resource lifecycle

04

Observe & account

Reconcile · verify

↔

Separate security service

Coordinate · respond

Requested work / actionObservation / record returned

Layers group capabilities, not project stages or authorization boundaries. Illustrative paths are not installed integrations. Each receiving team retains its actual decision rights. Shared visibility does not grant execution authority.

Lights-out is bounded automation.Automate known actions within delegated limits; route exceptions to people. Verify service results and preserve the evidence. More automation does not itself confer authorization.

A TRACEABLE CHANGE

From requested change to observed service.

A fictional platform release illustrates operational handoffs. This is a release workflow, not the seven RMF steps.

Teaching scenarioFictional · no live execution

Record / artifact

Responsible conversation

What the next team needs

What this does not prove

EXCEPTION & DECISION

Monitoring and authorization decisions

Linked, trustworthy change and monitoring evidence can support applicable ongoing authorization or reauthorization processes. The applicable authorization approach, assessment and risk decisions remain with the designated authorities.

A pipeline pass, an attestation or a signed artifact is evidence about a defined check—not an ATO.

DoD-specific cATO example and research limits

This summary relies on indexed official passages describing continuous monitoring, active defense and secure delivery, with assessment of people, process and platform. Direct retrieval of the cited cATO PDFs was blocked; current component requirements and approval route must be confirmed with the issuer. No cATO for a named product or DISA program is established here.

DoD CIO evaluation criteria, May 2024

GitHub: artifact attestations NIST RMF, SP 800-37 Rev. 2

EPHEMERAL DOES NOT MEAN UNTRACEABLE

Can we explain the bill—and the allocation?

Keep observed activity, provider charges and agency allocation distinct. Then reconcile them.

01ObserveResource identity, lifecycle & service context

02ReconcileMetered quantities, prices, invoice & corrections

03AllocateAgreed owners, shared-cost rule & exceptions

Fictional checkpointInvented USD amounts · not a price estimate

FICTIONAL BILLED-COST SNAPSHOT

Allocation of the selected export snapshot
Destination	Direct	Shared	Total

Basis and limits of this illustration

The selected amount is a fictional billed-cost snapshot in USD. It is not independently metered, invoice-verified or posted to agency accounts. Equal shared-cost allocation is an invented agreement for the second and third checkpoints. The example omits tax and commitment amortization to isolate identity, allocation and corrections.

For a real engagement, preserve billed cost and effective cost separately. Effective cost can allocate commitment purchases across consumption and need not equal invoices for the same period. Do not add cumulative export snapshots together.

THE SHORT-LIVED WORKLOAD

Six hours is one observation.

Our fictional job has a recorded six-hour lifecycle. That alone cannot validate a cloud charge.

Which thing ran?: Link resource ID, account, region and time range to a durable service, owner and release reference.
What was metered?: Check the actual service-specific usage unit, quantity and billing period. Storage, requests, transfer and idle capacity may also cost money.
Which cost are we showing?: Name billed or effective cost, currency, credits and commitment treatment. Avoid adding incompatible cost views.
Who should pay?: Apply a versioned allocation rule. Unallocated costs stay visible until an accountable owner resolves them.

Matching a provider export to its invoice establishes consistency, not independent meter accuracy. A CMDB may hold the stable service context. A lifecycle/event store and billing ledger may carry high-volume history. Product configuration and retention determine what is actually available.

FOCUS v1.3: billed-cost semantics AWS: report revisions and timeline FinOps Foundation: shared-cost allocation

Showback explains. Chargeback applies an agreed financial policy.Neither a tag nor a dashboard establishes a financial commitment. Preserve the original export, transformations, allocation version, review and any later correction.

Also review the service-map sources and design limits for advisory AIOps and collection alternatives.

RESEARCH & APPLICABILITY

Know what each reference can establish.

NIST supplies the common cybersecurity risk vocabulary. Architecture connections remain our synthesis; product and agency examples retain their own conditions.

COMMON FEDERAL REFERENCE LANGUAGE

Outcomes, risk management and controls serve different purposes.

NIST Cybersecurity Framework

CSF 2.0 organizes cybersecurity outcomes under Govern, Identify, Protect, Detect, Respond and Recover. These Functions work together; they are not a sequence of project gates.

Current and Target Organizational Profiles describe relevant outcomes and help identify priorities. CSF Tiers characterize the rigor of risk governance and management; they do not replace or convert our readiness ratings.

NIST CSF resources

NIST Risk Management Framework

RMF connects organization- and system-level security and privacy risk with Prepare, Categorize, Select, Implement, Assess, Authorize and Monitor activities.

Use it iteratively through the system life cycle. Configuration change approval, control assessment and system authorization remain distinct.

SP 800-37 Rev. 2

Control detail: SP 800-53 supplies the control catalog; SP 800-53B addresses baselines and tailoring; SP 800-53A supplies assessment procedures. Applicable requirements, selection, tailoring and actual implementation determine what must be assessed.

This is a NIST-informed reference, not a NIST-endorsed architecture or a conformance assessment. Agency requirements still govern; applicability to national security systems requires the appropriate policy authority. IT service management and FinOps remain complementary disciplines.

Preferred terms and their limits

Shared services and common controls: Describe the service first. Call controls common or inherited only where their implementation, assessment, authorization, monitoring and applicable inheritance are established. A shared platform is not automatically a common control.
Security-service provider: Use the general operational label across the reference. Keep CSSP when discussing a program that uses that designation; it is not a formal substitute for the assigned RMF common control provider.
System owner and authorizing official: Use NIST role names where the actual responsibility matches. Technical administrators and service-change approvers do not acquire authorization authority through tooling.
Monitoring, assessment and ongoing authorization: Operational monitoring addresses service health. Information security continuous monitoring (ISCM) maintains security-risk awareness at an appropriate frequency. Assessment evaluates controls; authorization is a risk decision. Retain DoD cATO as a qualified program-specific example.
Configuration change control: Use for reviewed changes to system configurations. Workforce adoption and organizational change management remain a separate conversation.
Management and orchestration: Use for our technical integration functions. “Control plane” and “lights-out” remain explanatory descriptions, not names of NIST frameworks or proof of compliance.

Read the NIST research and adoption guide

Four kinds of information

Published program descriptions: Public statements about a named program; not another agency’s service entitlement.
Product documentation: Documented behaviors and interfaces; not verified interoperability or government approval.
Conditionally applicable requirements: Use the actual selected baseline, contract and authorization regime.
Our reference patterns: Conceptual relationships and fictional walkthroughs, not observed client operations.

Scope of this reference

Cloud and shared-service integration receive the detail. Retained systems remain represented through existing owners, procedures, observation and approved interfaces.

These reference functions do not replace the existing 30 requests, 51 positions, 10 service domains or 53 workstreams. No client records, live connectors, automated provisioning, analytics or persistent user notes. External source pages open in a new tab only when you click a link. The local package needs no external runtime.

Explore the earlier four-pattern study (before NIST terminology adoption)
Download the baseline research

PROGRAM EXAMPLES · DISTINCT ROLES

These names occupy different parts of the picture.

Read the program and OEM overlay research · source-specific handoffs, evidence strength and unresolved connections.

DISA Thunderdome

Government descriptions cover user/device/application access and segmentation. This does not establish a general-purpose infrastructure orchestrator.

Government hearing record, QFR pp. 30–32

DISA / HPE hybrid cloud

HPE’s November 2025 announcement describes a production arrangement after a prototype, using Private Cloud Enterprise and GreenLake. It does not verify completed deployment or name Morpheus as DISA’s implemented stack.

HPE supplier announcement

Morpheus & CloudBolt

Alternative examples of orchestration roles—not a recommendation to buy both. HPE documents Morpheus in particular Private Cloud Enterprise configurations; that does not mean every GreenLake service depends on it.

HPE implementation example, August 2025

DISA Olympus

Indexed official material lists integrations, but still carries old beta/launch language. Current availability, fulfillment depth and backend architecture remain unverified.

Official offering page · indexed-only; no readable body retrieved

No DISA-specific topology, bill of materials, tenant agreement or authorization was inspected. These relationships are not an official DISA architecture. Earlier Army ECMA/cARMY, Cloud One, Platform One and federal examples remain in the deeper reference with their access limitations.

Read the expanded research and source qualifications