Considerations are part of the [[CSVLOD]] model, representing **business-focused rules**. A result of [[A Plan is Not a Strategy|strategic planning]]. They help achieve overall agreement on [[Guiding Principles]], values, and overall direction. They are dual-focused, for IT and business users both. > [!question] Questions > - How should the entire organization work? > - What [[Company Operating Model]] is desired? > - What [[Core Business Processes]] & what data should be standardized? Considerations are usually textual, rather than graphical. They have broad scope, but are not highly detailed. They are **permanent** and change very slowly. # Concerns They can be prone to being truisms, but are best when they actually describe a position your business has made in the [[Tradespace]] of possible directions. See: what makes good [[Mission Statement]]s. They should [[Make the Decision that Informs all Subsequent Decisions]]. # Types ## Principles Commonality: **Essential** Principles are high-level guidelines that should influence all planning & decision-making in an org. They are broad and general. Principles may come with _rationales_ and subsequent _implications_. > [!note] Example > **Business Continuity** > Services should not go down in the case of emergencies. > - **Rationale**: Customers need to be able to depend on the service to be there when they need it. > - **Implications**: All servers & data should have failsafes & redundancies, even if additional expenses are incurred ## Policies Commonality: **Common** Policies are basically like more descriptive and a little more _restrictive_ than principles. They're less subject to interpretation. Policies may relate to security, risk, and compliance. They may be derived from external laws (e.g. HIPAA). > [!note] Example > **Data Security Policies** > 1. No sensitive data on mobile devices > 2. Store credit card information in encrypted formats ## Conceptual Data Models Commonality: Uncommon Conceptual data models provide abstract definitions for the main data entities about which a business cares, tailored for non-technical audiences. These provide common vocabulary for use across the business and in documentation, like other [[Enterprise Architecture Artifacts]]. Would look like [[Block Definition Diagram]]s or very basic [[Entity-Relationship Diagrams]]. I'm surprised these are uncommon. > [!note] Example > ![[Pasted image 20240528172323.png]] ## Analytical Reports Commonality: Uncommon Analytical reports are executive-level analyses of industry-wide trends and their potential impact on the business. These are things like a [[SWOT Analysis]], [[2x2 Growth-Share Matrix|BCG Matrix]], etc. They depict technological innovations/trends for decision-makers. ## Direction Statements Commonality: Uncommon Direction statements describe organization-wide decisions with far-reaching implications. These would show high-level strategies for handling the result of an analytical report. This would be like something saying "_We're going to the cloud!_" with some identified gaps and expected outcomes. These may be represented in any sort of manner. The book suggests one, but it feels arbitrary. **** ## Source - [[The Practice of Enterprise Architecture]] ## Related - [[CSVLOD]] - [[Enterprise Architecture of the PDW]] - [[Diagram Types (index)]]