Enterprise architecture is a vague term. The lack of a clear and consistent definition leads to [[Enterprise Architecture Misconceptions]]. [[Enterprise Architecture as a Strategy]] defines `enterprise architecture` as: Enterprise architecture is the logic that organizes IT Infrastructure around Business Processes, reflecting the [[Company Operating Model]] (set points for _integration_ and _standardization_). Architecture aligns IT project capability deliveries to long-term company process, systems, and technology needs. It allows a company to [[Build On Yourself]], rather than create ad-hoc solutions, starting from scratch each time. [[The Practice of Enterprise Architecture]] defines `enterprise architecture` as: > [!quote] A collection of special documents (artifacts) describing various aspects of an organization from an integrated business and IT perspective intended to bridge the **communication** gap between business and IT stakeholders, facilitate information systems planning and thereby improve business and IT alignment. This second definition stresses the importance of EA as a mechanism for achieving [[IT-Business Alignment|IT-Business Alignment]]. EA is presented in [[Enterprise Architecture Artifacts]], of which there are numerous types. This definition illustrates the importance of creating _easy to interpret_ artifacts. [[Things Are Only As Important as What You Can Do with Them]]. If [[IT Project Actors]] can't do anything with your EA documentation, then you're not helping anything. Whatever definition you choose to use, EA is what bridges [[What is a Strategy|strategy]], [[Standard Processes]], the [[Defining Project|project]]s that realize them, the IT resources necessary to enable them, and the **communication** of all players involved in making everything happen. # Frameworks Architectural _modeling_ using [[Enterprise Architecture Frameworks]] is the practice of representing these - although it's maybe better to not be overly-reliant on [[Criticism of EA Frameworks|EA Frameworks]]. The book from the source suggests a more humble approach using simple [[Core EA Diagrams]]. The other book source is actively hostile against depending on frameworks. While there is no one “correct” way to present or think about EA, the _[[Enterprise Architectural Layers|layered]]_ approach seems to be common - one common-ish take on the layering is as follows: ![[IMG_1664.png]] The business architecture is the least complex. It’s held up by the business information (or data), which is slightly bigger. That’s held up by applications, which are in turn held up by underlaying technologies. For more, see: [[Enterprise Architectural Layers]]. There’s also the artifact-characterization framework known as the [[CSVLOD]] model: ![[IMG_2014.jpeg]] **** # More ## Source - [[The Practice of Enterprise Architecture]] - [[Enterprise Architecture as a Strategy]] - [Image](https://www.linkedin.com/pulse/enterprise-architecture-domains-pillars-getz-pmp-csm-aws-cmmi) ## Related - [[Company Operating Model]] - [[Archimate]] - [[UAF]]