The main value of an [[Enterprise Architecture]] practice is the enhanced **communication** it brings, assisting in [[IT-Business Alignment]]. The product of the practice are of EA Artifacts - concrete (or digital) descriptions of _facts_ and/or _decisions_. The process of EA is the creation and use of these artifacts, perhaps along with some supplementary/supporting activities. EA artifacts and their creation are the topic of [[The Practice of Enterprise Architecture]] by [[Svyatoslav Kotusev]]. This note contains my own thoughts as well as those pulled from this book. EA artifacts are of varying format, domain, scope, level of detail, volume, temporal states, and storage approaches. They have a **duality** - they are meant for business and IT audiences. They may be temporary in nature or designed to be permanently maintained. Some are simple textual documents, others are simple graphics made in things like [[Excalidraw]], and others are derived from complex models housed in for-purpose tools like [[Archi]]. > [!tip] EA Artifacts are either **decision** or **fact** artifacts **Decision** Artifacts are develop collaboratively, built to aid in a specific situation, facilitate shared [[Mental Models]] for the decision-makers, and should be mutually approved at the end. They are _process over product_. They are valuable as they are being developed. **Fact** Artifacts are developed more on one’s own, perhaps after interviewing SMEs. They are _product over process_. They are valuable only _after_ they have been developed. # Duality Many (though not all) EA Artifacts should feel [[Idiomatic]] (or at least _approachable_) to **both business and IT stakeholders**. This duality makes them more effective at building shared [[Mental Models]] and enabling effective communication/collaboration. # Tooling & Hosting EA artifacts are [[Distillation]]s of various aspects of a business, at various levels of detail, with various focuses, and various purposes - thus they are _highly variable_. They should, however, represent **the same underlying truth**. They represent reality (or in some cases proposed realities). This perspective on EA Artifacts would seem to suggest a **model-based approach**, where the same reality with massive complexity can be rendered into distinct-but-connected _views_ that support [[Decomposition Understanding]]. As I cover in my [[Modeling Purposes]] note, the purpose of these models is _not_ meant to be simulation, but communication. Thus the modeling tools that are armed with simulation capabilities are bloated with unnecessary features right out the gate. This makes [[SysML]] tools less ideal, where necessary hooks and UI elements are in place to enable fancy simulation engines that do you no good for this type of work. This concern is alleviated by using purpose-built [[Enterprise Architecture]] tools like those built for [[Archimate]]. Even still, though, those tools require mass installation & file sharing, or robust publishing capabilities that can be hosted elsewhere. Also Archimate still has some surprising limitations in its metamodel (such as [[Cardinality]]). An ideal world would have a tool that supports [[Referential Integrity]] through linking to discrete elements, but also the ability to use them to create _whatever_ necessary visualization, report, or distillation necessary, in order to meet the _audience_ where they are at with a message they don’t need training to comprehend. An alternative approach would be to eschew the concept of the underlying data model altogether, and instead go for a something more akin to [[Wikipedia]], or even [[Semantic Wikis]]. This is the fundamental approach behind the [[CSVLOD]] categorization approach. It’s not yet clear to me to what extent [[Ontology]] research, [[PKM|Personal Knowledge Management]], and [[Enterprise Architecture]] can overlap. Something as simple as [[Obsidian]] could easily be used to make a fairly robust basis for your EA. A [[Graph Database]] could be a very fruitful approach to flexibility modeling reality. Perhaps once AI can help construct them. **** ## Source - [[The Practice of Enterprise Architecture]] ## Related