# Enterprise architecture example overlays

**Use one enterprise hybrid service-management architecture, with North Star programs and OEM practices presented as scoped examples of particular functions and handoffs.** Keep the underlying responsibilities stable: service intent, governance, access, orchestration, delivery, retained operations, inventory, telemetry, assurance and cost accountability. An overlay identifies what a source actually describes; it does not supply a complete client solution or prove that adjacent capabilities integrate. CSSP services require an independently established service relationship. NIST vocabulary provides the cybersecurity frame, while release, service and financial decisions remain distinct. Preserve **30 requests / 51 positions / 10 domains / 53 workstreams**; these conceptual functions do not replace the canonical domains.

## One architecture accommodates examples without merging their authority

The base architecture is **analyst synthesis**: service requests and configuration-change decisions lead to bounded execution, followed by observed results, reconciled records and reviewable evidence. Cloud/GSS, retained enterprise services and third-party overlays contribute through their own responsibilities. Common intake does not imply shared privileged access, centralized execution authority or an enlarged authorization boundary. Retained services can continue effective scheduled procedures without adding automation merely to resemble cloud delivery.

Use CSF 2.0 outcomes and RMF roles to explain cybersecurity responsibility. **Govern, Identify, Protect, Detect, Respond and Recover** are connected outcomes, not product layers. The system owner, common control provider, control assessor and authorizing official remain separately identified; an OEM or program name assigns none of those roles automatically. Evidence supports assessment and authorization decisions without granting them. NIST applicability remains system- and authority-specific, including the national-security-system caveat. ([CSF 2.0](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf); [RMF Rev. 2, Authority and Appendix D](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf))

Each overlay should state its supported functions, direction of handoff, source/date, evidence strength and unresolved connections. Use **documented integration**, **historical tutorial**, **vendor-described capability** and **unverified handoff**. Highlighting two functions does not establish a connection between them; unknown is not failed or absent.

## North Stars demonstrate organizational and operational slices

| Program example | Supported slice | Boundary that must accompany it |
| --- | --- | --- |
| **ECMA/cARMY** | Catalog/onboarding entry points; shared-service operation, access responsibilities, compliance reporting and financial/acquisition functions | Undated overview; detailed catalog CAC-gated. Financial ownership does not prove a FinOps allocation system or automated fulfillment. [Army overview](https://www.army.mil/ecma) |
| **Cloud One** | Platform operations, sustainment, monitoring and migration assistance | September 2024 account; inherited cybersecurity packages remain conditional on AO signoff. “Hybrid” migration does not establish complete retained-system operations. [AFLCMC article](https://www.aflcmc.af.mil/NEWS/Article-Display/Article/3903974/cloud-one-expands-in-midst-of-great-power-competition/) |
| **Cloud One/P1 CNAP** | A specific support split: authentication remains with P1; access-authorization support routes toward Cloud One | June 2025 notice/workflow: P1 Jira versus Cloud One ServiceNow routing, not record synchronization, infrastructure provisioning or ATO authority. [Transition notice, pp.1–2](https://repo1.dso.mil/platform-one/bullhorn-delivery-static-assets/-/raw/master/p1/Cloud%20Native%20Access%20Point%20%28CNAP%29%20Transition%20to%20Cloud%20One%20-%2006_03_2025.pdf) |
| **Thunderdome** | SASE, SD-WAN/customer-edge security and application access; automated security-policy application | DISA’s March 2023 prototype release supports policy/access automation, not general workload orchestration or October 2026 coverage. [DISA-issued release](https://www.prnewswire.com/news-releases/disa-announces-successful-completion-of-thunderdome-prototype-301759988.html) |

The CNAP notice provides the clearest cross-service handoff in this program set. Preserve its direction and meaning. Do not turn it into a universal ServiceNow catalog, common backend or automated Jira–ServiceNow bridge. Likewise, Thunderdome should not illustrate an infrastructure-provisioning function merely because both involve automation.

## OEM overlays explain different execution and return paths

ServiceNow/Morpheus and Jira/Jenkins demonstrate **different initiating directions**. A March 2022 HPE tutorial exposes private-cloud catalog items through a Morpheus ServiceNow plugin and shows order/deployment status; optional CMDB mapping is outside that tutorial. Separately, Morpheus **v7.0.10, released January 2025**, documents ServiceNow-owned approval before provisioning, configured CI creation and local execution history. Combining those passages gives a reference pattern, not a tested current transaction or proof that Morpheus underpins every GreenLake service. ([HPE tutorial](https://developer.hpe.com/blog/how-to-provision-hpe-greenlake-private-cloud-resources-from-servicenow-service-catalog/); [versioned manual](https://support.hpe.com/docs/display/public/mp00710en_us/index.html))

Atlassian instead documents Jenkins raising a pending deployment, checking a Jira Service Management Cloud change gate and returning success status. Its sample deployment is an echo; failure/rollback evidence is incomplete, and configured integration plus applicable Premium/Enterprise access is required. CloudBolt’s 2019 explanation describes ServiceNow back-end orchestration and CMDB updates; its rolling self-service page positions ServiceNow/Jira approvals and Terraform/Ansible extensibility. Neither establishes a complete current connector contract. These are alternatives, not a verified ServiceNow → Jira → Morpheus → CloudBolt chain. ([Jira/Jenkins gating](https://support.atlassian.com/jira-service-management-cloud/docs/use-deployment-gating-with-jenkins/); [CloudBolt historical integration](https://www.cloudbolt.io/blog/servicenow-and-cloudbolt-innovation-want-to-dance/); [CloudBolt capabilities](https://www.cloudbolt.io/cmp/self-service/))

AWS LZA and Azure landing zones illustrate governed platform deployment, access foundations and centralized telemetry. AWS documents configuration-driven pipelines and optional manual review; Azure documents platform/workload responsibility separation, IaC and subscription vending. Provider configuration records are **partial inventory inputs**, not a reconciled enterprise CMDB. GovCloud installation/service differences and Azure sovereign-cloud adaptations prevent commercial-to-government deployment-parity claims. ([AWS LZA](https://docs.aws.amazon.com/solutions/landing-zone-accelerator-on-aws/); [AWS implementation guide](https://docs.aws.amazon.com/pdfs/solutions/latest/landing-zone-accelerator-on-aws/landing-zone-accelerator-on-aws.pdf); [Azure architecture](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/); [Azure deployment](https://learn.microsoft.com/en-us/azure/architecture/landing-zones/landing-zone-deploy))

Financial overlays need separate evidence: AWS CUR revisions and Azure usage/charge records support investigation, not invoice verification from runtime. Retain export scope/revision, ownership intervals, invoice adjustments and financial review. Landing-zone automation does not establish shared allocation or chargeback authority. ([AWS CUR](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html); [Azure usage/charges](https://learn.microsoft.com/en-us/azure/cost-management-billing/understand/understand-usage))

## CSSP coverage and traceable handoffs require explicit agreements

DISA’s **Winter 2023 Lookbook** describes CSSP customer intake, service packages, quotes, implementation, monitoring and response separately. That supports treating CSSP as a service relationship; it does not establish coverage for any ECMA, Cloud One, Thunderdome or OEM tenant. A log archive, Sentinel instance or pipeline security check cannot substitute for that agreement. ([DISA Lookbook, pp.20–21](https://www.disa.mil/-/media/Files/DISA/Fact-Sheets/2023_lookbook_winter_508-compliant_20230310.ashx))

The following is a **proposed handoff discipline**, not a verified end-to-end integration or mandatory evidence schema.

| Handoff | Trace and responsibility to establish |
| --- | --- |
| Request/change → execution | Decision object, approved scope/window, workflow version, bounded executor identity and target IDs |
| Execution → inventory | Attempt/result/error, actual resources, observation time and reconciliation; CI creation alone is insufficient |
| Telemetry → security operations/CSSP | Named recipient, admitted data, coverage, acknowledgement, triage and separately delegated response authority |
| Response → service recovery/evidence | Incident correlation, authorized action, verified effect, residual uncertainty, custody and closure responsibility |
| Provider records → financial review | Export revision, invoice scope, adjustments, allocation policy and unresolved differences |

Customer SLAs and interteam OLAs should distinguish delivery commitments from supporting handoffs. Missing identity propagation, duplicate handling, expiry, cancellation, partial execution, recovery or retention must remain visible. No reviewed source establishes safe Solaris/SPARC orchestration, a complete assurance return, or automatic containment authority.

All overlay notes were retrieved **3 October 2026**, without a later verification round. Cloud One’s article and the CSSP Lookbook were read through official indexed text after direct retrieval failed; Army restricted content remained inaccessible. CloudBolt connector documentation returned shells, and newer Morpheus pages failed retrieval; a staging release-candidate page was not used as production evidence. AWS’s opened overview showed **1.16.2**, while search rendering showed **1.16.3**; neither is labeled verified latest. Its rolling PDF revision date differs from software releases. Microsoft article text was readable despite authorization notices. These limitations qualify the examples, not prove missing capabilities.

## Conclusion

A useful overlay makes one handoff more understandable while preserving what remains unknown. Keep program descriptions, OEM mechanisms and analyst connections visibly distinct. Their value is sharper questions about ownership, evidence and operating agreements—not a composite client solution, compliance score or implied service entitlement.