Statement of Architecture Work Template

Standard Operating Procedure: Statement of Architecture Work (SAW) Template Creation and Management

1. Document Control Block

• Document ID: TR-SOP-ARC-001
• Effective Date: 2023-10-27
• Version: 1.0
• Review Cadence: Annually

2. Executive Summary & Scope

This Standard Operating Procedure (SOP) outlines the standardized process for the creation, review, approval, and management of a Statement of Architecture Work (SAW) within Template Registry. The SAW serves as a foundational document for all architecture-driven initiatives, ensuring clear communication, explicit scope definition, and consistent stakeholder alignment regarding architectural efforts.

Purpose: To establish a repeatable, high-fidelity process for defining and baselining architectural work packages, thereby reducing ambiguity, managing expectations, and improving project predictability and architectural integrity.

Scope: This SOP applies to all architectural engagements initiated by or impacting Template Registry's enterprise architecture landscape. This includes new system developments, significant system enhancements, technology modernizations, and architectural research initiatives. It covers the lifecycle of the SAW from initial concept to final approval and archival. Excluded are detailed technical design specifications, which are downstream deliverables generated after SAW approval.

3. Prerequisites & Required Tools

3.1. Prerequisites

• Architectural Principles: Adherence to Template Registry's published Enterprise Architecture Principles and Standards.
• Business Case: An approved business case or project initiation document (PID) outlining the strategic justification for the architectural work.
• Initial Requirements: High-level functional and non-functional requirements (NFRs) sufficient to inform architectural scope.
• Stakeholder Identification: Comprehensive identification of relevant business, technical, and operational stakeholders.

3.2. Required Tools

• Collaborative Document Management System (CDMS): Confluence, SharePoint, or equivalent for document drafting, version control, and stakeholder collaboration.
• Enterprise Architecture (EA) Modeling Tool: ArchiMate, Sparx Enterprise Architect, or equivalent, for documenting current and target state architectures and generating relevant diagrams.
• Project Management Information System (PMIS): Jira, Azure DevOps, Asana, or equivalent, for tracking tasks, deadlines, and dependencies related to SAW creation and review.
• Secure Communication Platform: Microsoft Teams, Slack, or equivalent, for real-time discussions and rapid information exchange.
• Version Control System: Git, SVN, or integrated CDMS versioning, for strict control over SAW iterations.

3.3. Compliance & Standards

• Template Registry Architecture Standards: All architectural decisions must align with internal standards.
• ISO 27001: Information security considerations must be embedded.
• Data Privacy Regulations: GDPR, CCPA, or regional equivalents, where applicable.

4. Roles & Responsibilities (RACI Matrix)

• R (Responsible): Performs the task.
• A (Accountable): Ensures the task is completed and approves it. There is only one 'A' per task.
• C (Consulted): Provides input or expertise.
• I (Informed): Kept up-to-date on progress and decisions.

5. Step-by-Step Procedure

Phase 1: Initiation of Architecture Work Request

• 1.1. Project Manager (PM) or Business Sponsor submits a formal Architecture Work Request via the PMIS, linking to an approved business case/PID.
• 1.2. Enterprise Architect (EA) receives and reviews the request for alignment with strategic architectural roadmap and initial feasibility.
• 1.3. EA assigns a Solution Architect (SA) to lead the architectural definition process.
• 1.4. SA schedules an initial kickoff meeting with key stakeholders (PM, TL, BS) to clarify objectives and high-level scope.

Phase 2: Drafting the Statement of Architecture Work (SAW)

• 2.1. SA creates a new SAW document instance using the prescribed Template Registry SAW template within the CDMS.
• 2.2. SA populates the following mandatory sections:
  • 2.2.1. Document Information: Unique ID, Title, Project/Initiative, Author, Version.
  • 2.2.2. Executive Summary: Concise overview of the architectural work.
  • 2.2.3. Background & Context: Strategic drivers, business problem, current state overview.
  • 2.2.4. Architectural Objectives: Measurable outcomes for the architectural effort.
  • 2.2.5. Scope of Architecture Work: Explicitly define what is IN and OUT of scope.
    • In Scope: Systems, domains, capabilities, architectural styles, principles, deliverables.
    • Out of Scope: Specific detailed design elements, specific implementation tasks, operational runbooks.
  • 2.2.6. Key Architectural Principles Applied: List and explain relevant EA principles guiding this work.
  • 2.2.7. Non-Functional Requirements (NFRs): High-level NFRs (e.g., performance, security, scalability, resilience, maintainability, compliance).
  • 2.2.8. Architectural Constraints & Assumptions: Technical, regulatory, financial, timeline, resource constraints; critical assumptions made.
  • 2.2.9. Proposed Architectural Approach (High-Level): Conceptual target state architecture, significant architectural patterns, technology choices (at a high level), and key architectural decisions. Include relevant diagrams generated from the EA modeling tool.
  • 2.2.10. Deliverables: List specific architectural artifacts (e.g., target architecture diagrams, reference models, architectural decision records, technology selection matrix).
  • 2.2.11. Roles & Responsibilities: Identify key architectural roles involved and their scope.
  • 2.2.12. Success Metrics: How the architectural work's success will be measured.
  • 2.2.13. Appendices: Glossary, references, supporting documentation links.
• 2.3. SA ensures all references to existing standards, policies, and frameworks are accurate and hyperlinked.

Phase 3: Review & Iteration

• 3.1. SA circulates the draft SAW to the PM, TL, and relevant BS for initial technical and business review.
• 3.2. Reviewers provide feedback and comments within the CDMS or designated feedback channels.
• 3.3. SA consolidates feedback, clarifies ambiguities, and iterates on the SAW document, updating the version control.
• 3.4. SA conducts follow-up meetings as necessary to resolve conflicting feedback or complex architectural concerns.
• 3.5. Once initial feedback is addressed, SA presents the refined SAW to the Enterprise Architect (EA) for endorsement.
• 3.6. EA reviews the SAW for strategic alignment, architectural integrity, and adherence to Template Registry standards. EA provides endorsement or requests further revisions.

Phase 4: Formal Approval

• 4.1. SA submits the EA-endorsed SAW to the Architecture Review Board (ARB) for formal approval.
• 4.2. ARB reviews the SAW against defined criteria (e.g., strategic alignment, architectural soundness, risk assessment, compliance).
• 4.3. ARB conducts a formal review meeting, inviting the SA, EA, PM, and key BS to present and defend the SAW.
• 4.4. ARB either approves the SAW, approves with conditions, or rejects it with specific required actions.
• 4.5. The decision is formally recorded, with signatories from the ARB and key stakeholders (SA, PM, lead BS).

Phase 5: Distribution & Baseline

• 5.1. Upon ARB approval, SA publishes the final version of the SAW in the designated official repository within the CDMS.
• 5.2. SA communicates the approved SAW to all relevant project teams, stakeholders, and departments.
• 5.3. The approved SAW is baselined and serves as the definitive reference for all subsequent design and implementation activities for the initiative.
• 5.4. A link to the baselined SAW is added to the relevant project entry in the PMIS.

Phase 6: Maintenance & Updates

• 6.1. Any proposed changes to the baselined SAW require a formal change request process, initiated by the SA or PM.
• 6.2. Significant changes necessitate re-submission through Phase 3 (Review & Iteration) and Phase 4 (Formal Approval) with relevant version updates.
• 6.3. Minor clarifications or updates can be approved by the EA and SA, with notification to the ARB.
• 6.4. The SA ensures the SAW remains current throughout the lifecycle of the architectural initiative.

6. Quality Assurance & Verification

6.1. Key Metric Thresholds

• SAW Completeness Score: >95% of mandatory sections completed and formally addressed.
• Stakeholder Sign-off Rate: 100% of identified accountable stakeholders have formally approved the SAW.
• Architecture Principle Adherence Score: >90% of applicable Template Registry architectural principles demonstrably addressed within the SAW.
• Review Cycle Time: Average time from draft submission to ARB approval < 15 business days.

6.2. Common Pitfalls & Mitigation

• Pitfall: Scope Creep (post-SAW approval).
  • Mitigation: Enforce strict change control process (Phase 6), requiring re-approval for any scope deviation. Regularly communicate SAW scope to project teams.
• Pitfall: Lack of clear Non-Functional Requirements (NFRs).
  • Mitigation: SA must proactively engage with business and technical stakeholders to explicitly define and quantify NFRs. Leverage NFR templates and checklists.
• Pitfall: Insufficient Stakeholder Engagement during drafting/review.
  • Mitigation: Establish mandatory review gates and sign-offs. PM to track stakeholder involvement. Utilize dedicated workshops for complex sections.
• Pitfall: SAW is too technical/dense for business stakeholders.
  • Mitigation: Emphasize the "Executive Summary" and "Background & Context" sections. Utilize clear, concise language and appropriate visuals (diagrams). Provide a business-friendly overview during presentations.

6.3. Audit Checklist

• 6.3.1. Is a unique SAW Document ID present and correctly formatted?
• 6.3.2. Are all mandatory sections (as per 2.2) complete and populated with relevant content?
• 6.3.3. Is there clear evidence of stakeholder sign-offs (BS, PM, TL, ARB) as per the RACI matrix?
• 6.3.4. Does the SAW demonstrably align with Template Registry's Enterprise Architecture Principles?
• 6.3.5. Is the SAW under strict version control within the CDMS?
• 6.3.6. Are Architectural Objectives measurable and traceable to the business case?
• 6.3.7. Are NFRs clearly stated and, where possible, quantifiable?
• 6.3.8. Does the "Scope of Architecture Work" explicitly define both "In Scope" and "Out of Scope" items?
• 6.3.9. Are high-level architectural diagrams included and consistent with the narrative?

7. Troubleshooting FAQ

• Q1: Stakeholders disagree significantly on architectural scope after the initial draft is circulated.

  • A1: The SA, in conjunction with the PM, must immediately schedule a dedicated scope clarification workshop. The objective is to facilitate consensus or, failing that, escalate to the EA and relevant business sponsors for a definitive decision on scope boundaries, potentially leading to a revised business case or project scope. Document all decisions and outstanding disagreements explicitly in the SAW's "Constraints & Assumptions" section.

• Q2: The Architecture Review Board (ARB) rejects the SAW due to identified risks or misalignment with strategic direction.

  • A2: The ARB will provide explicit reasons for rejection and required actions. The SA must revise the SAW addressing these specific points, potentially involving re-engagement with technical leads or business stakeholders for re-scoping or re-architecting elements. The revised SAW must then be resubmitted through the formal review and approval process (Phase 3 & 4), highlighting the changes made in response to the ARB's feedback.

• Q3: Significant new requirements or changes emerge after the SAW has been formally approved and baselined.

  • A3: Initiate a formal change request (Phase 6). The SA, in collaboration with the PM and affected stakeholders, must assess the impact of the new requirements on the baselined SAW (scope, NFRs, approach, deliverables). If the impact is substantial, the SAW must be updated and submitted for re-approval through the ARB. For minor changes, the EA and SA can approve, but all stakeholders must be informed, and the SAW version must be updated. Avoid unapproved deviations from the baselined SAW.