Standard are part of the [[CSVLOD]] model, representing **IT-focused rules**. They're a result of Technology Optimization. They help achieve consistency of IT infrastructure, helping reuse, lowering risk, increasing interoperability, and easing maintenance and compliance tasks. They are only meant for IT users (and architects). > [!question] Questions > - What technologies and products should be used in IT Solutions? > - How should those things be used? > - What are the main data entities? Standards _may_ be textual, but are often visual [[Diagram Types (index)|diagrams]] and may involve specialized tools like [[Archi]] or a [[UML]] tool. Standards are more generic and broadly-scoped than are [[EA Landscapes]]. # Concerns Finding the right level of specificity can be difficult - you want to _have_ standards, but also not constrain local solutions into approaches/technologies that don't make sense. Overly constraining standards will result in either ineffective solutions or, more likely, unwillingness of the developers to abide by them - making them useless. There should be a process for breaking with standards, and those exceptions should be documented as "_architectural debt_". It makes sense to build out standards with respect to the [[Hierarchy]] of the business - enterprise level standards being most general & least restrictive and individual team standards being the most specific and restrictive. As with all things, [[Balance]] is key. # Types ## Technology Reference Models Commonality: **Essential** Tech reference models graphically depict the chosen technologies used across the business. They are also often color-coded to represent some lifecycle information for said technology - e.g. a particular database technology current, prospective, or sunsetting. > [!note] Example > ![[screenshot 4.png]] ## Guidelines Commonality: **Essential** Guidelines are a written list of technical rules for how things must be done when implementing IT solutions. Guidelines are specific to IT, and don’t concern business stakeholders. They do however codify best practices and help with security/compliance. They may cover things like protocols, database access [[Pattern]]s, UI/UX rules, et al. Large or disparate organizations may have multiple sets of hierarchical guidelines to IT teams/solution architects in different areas to write their own guidelines. > [!note] Example > ![[Pasted image 20240530231608.png]] ## Patterns Commonality: Common Patterns are essentially descriptions of archetypal solutions to common types of specific problems, or high-level [[Checklists]] for how to carry out some repeated tasks. Patterns often come with a _description_, _applicability_, and _rationale_. You'd have a pattern for how to deploy a new server, or test a new API. > [!note] Example > ![[Pasted image 20240531095125.png]] ## IT Principles Commonality: Common IT Principles are essentially the same thing as [[EA Considerations#Principles]], but more specific to IT concerns. These would be textual, captured wherever. They'd be used by governance bodies, IT Project Leads, & architects. > [!note] Example > - Prefer open-sourced solutions > - Back up all permanent data offsite > - Utilize zero-trust methods where possible ## Logical Data Models Commonality: Uncommon(?) These are essentially just [[Entity-Relationship Diagrams]]. The fact they're labeled as "uncommon" must mean that they are uncommon _for Enterprise Architecture_, because there's no way these are actually uncommon in industry. These are typically [[UML]]. > [!note] Example > ![[Pasted image 20240531104350.png]] ## Others Mentioned, but not given full sections in the book are: - **Technology inventories** - comprehensive catalogs of all technologies used - **Interface definitions** - essentially API documentation, again this feels like it should be _very_ common **** ## Source - [[The Practice of Enterprise Architecture]] - https://eaonapage.com/ ## Related - [[CSVLOD]] - [[Enterprise Architecture of the PDW]] - [[Diagram Types (index)]]