When we describe the data architecture we describe\u00a0four elements<\/a>–data needs<\/a>,\u00a0major sources of data<\/a>,\u00a0major types of data<\/a>, and the required data management resources<\/a>.<\/p>\r\n Navigate<\/a> is model-centric. There are four enterprise architecture models<\/a> that describe your data architecture – the subject model<\/a>, subject area model<\/a>, logical data model<\/a>, and logical document model<\/a>.<\/p>\r\n When the data architecture is combined with application architecture<\/a> focus on the structure and interaction of the applications that … manage the data assets, <\/em>you have an information systems architecture<\/a>.<\/p>\r\n Let’s look closer at what is a data architecture.<\/p>\r\n\t\t\t\r\n\t\t\t\t\t\t\tExplore TOGAF Certification Training\r\n\t\t\t<\/a>\r\n\t What is Data Architecture?<\/a><\/p>\r\n Four Elements of Data Architecture<\/a><\/p>\r\n Data Architecture Model Kinds<\/a><\/p>\r\n Everything Revolves Around Data Needs<\/a><\/p>\r\n Conclusion<\/a><\/p>\r\n\t\t\t\t Data architecture is explains and enables the data needs of the enterprise<\/em>.\u00a0 It is described through four elements<\/a>–data needs<\/a>,\u00a0major sources of data<\/a>,\u00a0major types of data<\/a>, and the required data management resources<\/a>.<\/p>\r\n We use four enterprise architecture models<\/a> to describe your data architecture – the subject model<\/a>, subject area model<\/a>, logical data model<\/a>, and logical document model<\/a>.<\/p>\r\n Data architecture is the leading part of the information systems architecture<\/a>. The Information Systems Architecture is a unique architecture domain<\/a> that aligns\u00a0functionality<\/em>, data<\/em>, and data management<\/em>. In practice, this means ensuring that applications are delivering the required data flow and data management, not just delivering features.<\/p>\r\n Common practice pushes data architecture to the background. We obsess about features and talk about applications – what they do, how they’re built, or how they integrate with other systems.<\/p>\r\n Applications exist to process and manage data. Without a solid understanding and design of Data Architecture, applications become disconnected islands. As they deliver features, they deliver technical debt. They create complexity in data flow and data management. Complex data flow and data management accelerate your technical debt, and add complexity to data governance.<\/p>\r\n When you lead with data , and ensure the application architecture<\/a> is focused on the structure and interaction of the applications that … manage the data assets, <\/em>you have an information systems architecture.<\/p>\r\n No successful digital transformation<\/a> will be built on functionality. They are always built on data.<\/p><\/blockquote>\r\n\t\t\t\r\n\t\t\t\t\t\t\tExplore TOGAF Certification Training\r\n\t\t\t<\/a>\r\n\t Every data architecture will address:<\/p>\r\n By themselves these elements help us understand the structure of the data.<\/p>\r\n We are chasing an understanding of data flow. Data flow is explained by data sources and data needs are the bookends of data flow-where it comes from, and where it is needed.<\/p>\r\n Keep in mind that once data starts moving it can go anywhere. Flow requires controls; it requires data management resources.<\/p>\r\n We know that data architecture steers great enterprise architecture<\/a>. It can only steer if you know the data flow.\u00a0 Required data flow mandates how\u00a0 application architecture and infrastructure architecture<\/a> enable your business architecture<\/a>.<\/p>\r\n\t\t\t\t Everything starts with the data needs<\/em>\u00a0of the enterprise.<\/p>\r\n Data needs fall into three categories:<\/p>\r\n Do not get confused about data needs<\/em> – you must ruthlessly separate what’s nice to have<\/em> from what’s needed<\/em>.<\/p>\r\n Needed<\/em>\u00a0does not require modifiers like absolutely, or important. Needed is simply necessary.<\/p>\r\n\t Where data is created, or collected, and where it is transformed. Data comes from manual processes, applications, devices, and external partners. Understanding the source system is central to data quality, lineage and governance.<\/p>\r\n\t Identifying key data categories relevant to your business-customer, product, financial, operational, and so forth. This classification helps focus architectural efforts and governance.<\/p>\r\n Usually the major types of data are defined in the Subject Model<\/a><\/p>\r\n\t Tools and systems that deliver the needed data where, when, how, with the right quality, confidence and security. In practice these are a broad set of requirements directed at the application and infrastructure architectures.<\/p>\r\n\t\t\t\r\n\t\t\t\t\t\t\tDownload the Practitioner’s Guide to Developing an Enterprise Architecture\r\n\t\t\t<\/a>\r\n\t Navigate<\/a> provides an end-to-end enterprise architecture landscape. This is a specific way of saying we work towards an end-to-end model architecture model.<\/p>\r\n We develop the EA Landscape following the best practice of incrementally extending it one architecture project at at time.<\/p>\r\n We manage the enterprise model through discrete model kinds<\/em>. A model kind can support specific analysis, or focus on a separate aspect of the end-to-end model. In simple terms, a model kind refers to the conventions for a specific type of modelling.<\/p>\r\n Each model kind is optimized to tell us something about the architecture.<\/p>\r\n Different model kinds will explore:<\/p>\r\n Using model kinds drive consistency and re-usability driving productivity and consistency across an EA Team.<\/p>\r\n Each model kind is defined by:<\/p>\r\n We draw Navigate’s data model kinds from DAMA’s The Enterprise Data Model. The Enterprise Data Model is comprised of the Subject Model<\/a>, Subject Area Model (SAM)<\/a>, and Logical Data Model (LDM)<\/a>. Both the SAM and LDM are built from the Subjects. They serve distinct, but interconnected, purposes.<\/p>\r\n The Subject Model <\/strong>describes the organization’s data landscape. Every Subject is meaningful to the data landscape.<\/p>\r\n The Subject Area Model <\/strong>is business-centric<\/em> view. It’s about understanding a specific business domain – a “Subject” – in detail. The SAM defines Subject in a way that’s readily understandable by business stakeholders. It’s a narrative of the data, focusing on what it means.<\/em><\/p>\r\n The Logical Data Model<\/strong>, is a technically-oriented<\/em>. It builds upon the SAM, transitioning from the SAM’s business concepts into sufficient detail to guide implementation.<\/p>\r\n Together the SAM and the LDM speak to two distinct audiences. The SAM reflects the business understanding of the data’s meaning. The LDM is guidance and constraint for the implementation. This frame is often documented in a Master Data Blueprint.<\/p>\r\n The SAM and LDM reflect the same Subject, speaking to different audiences.<\/p>\r\n\t Subject Model Scope<\/strong><\/p>\r\n Subject model identifies business relevant<\/i> information areas<\/p>\r\n Each Subject identifies the information needed in an area of activity or a distinct aspect of operations<\/p>\r\n Provide a shared understanding<\/i> of the data landscape<\/p>\r\n Used to<\/p>\r\n Subject Model Guidance<\/strong><\/p>\r\n Enterprise-wide<\/p>\r\n Department-wide Architecture project<\/p>\r\n Transformation Initiative<\/p>\r\n The Subject Area Model Kind (SAM) represents the information within a single Subject. The SAM is used to ensure a common understanding of the understanding of the data landscape.<\/p>\r\n The purpose is clear – develop an understanding of the data landscape.<\/p>\r\n DAMA tells us to think about the entities that define the information in a Subject. Entities have relationships with other entities. Relationships within the Subject, and with entities in other Subjects.<\/p>\r\n Entity is just a data-way of saying a topic of information, a noun. We use the component Business Term.<\/p>\r\n Subject Area Model Guidance<\/strong><\/p>\r\n The Subject Area Model uses 8-15 Business Terms (Entities) to define the Subject. Expect 1-2 Business Terms from from another subject, to complete the understanding of the Subject.<\/p>\r\n Aim for a sweet spot of ~13 Business Terms. You must keep the model manageable.<\/p>\r\n As you approach 12 Business Terms consider whether you have more than one subject<\/p>\r\n Less than 8 Business Terms suggest this might not be a deep, or important Subject.<\/p><\/blockquote>\r\n\t The Logical Data Model Kind Kind (LDM) represents the information within a single Subject with the intention of guiding and constraining implementation. The LDM is used to ensure a consistent technical handling of the data landscape.<\/p>\r\n The purpose is clear – guiding implementation to ensure the data landscape\u00a0 enables the business’ data needs<\/em>.<\/p>\r\n Logical Data Model Guidance<\/strong><\/p>\r\n The Logical Data Model uses 12-20 Logical Data Components (Entities). Expect 3-5 Logical Data Components from from another subject.<\/p>\r\n The LDM\u00a0must<\/em> include cardinal relationships, properties, and data access and data management architecture specifications<\/p><\/blockquote>\r\n Logical Data Properties<\/strong><\/p>\r\n Data Access<\/strong><\/p>\r\n Data Classification<\/strong><\/p>\r\n Data Retention<\/strong><\/p>\r\n Data Type<\/strong><\/p>\r\n Data Protection Property (Optional)<\/strong><\/p>\r\n The Logical Document Model Kind exists to represent artifacts-such as forms, letters, or reports-relevant to a specific business activity (e.g., Quotation, Sales Order, Invoice, Bill of Lading, Job Application).<\/p>\r\n It provides context for data, facilitating understanding of data security, retention, flow, and governance. For example, data entities such as price<\/em> do not convey retention or security requirements, whereas documents like the Quotation<\/em>, Sales Order<\/em>, and Invoice<\/em> provide that context.<\/p>\r\n Logical documents cover three document types:<\/p>\r\n Logical Document Model Guidance<\/strong><\/p>\r\n The Logical Document Model is easiest when an end-to-end business process is considered. End-to-end processes will use 3-10 Logical Documents.<\/p>\r\n Aim for a sweet spot of ~6 Logical Documents. You are looking for a complete list of Records<\/strong>, and a useful list of Business Documents<\/strong> and Transitory Documents<\/strong> to capture retention, security and quality.<\/p>\r\n Each Logical Document will contain 5-10 Business Terms or Logical Data Components.<\/p><\/blockquote>\r\n Logical Document Properties<\/strong><\/p>\r\n Document Type<\/strong><\/p>\r\n Data Access Property<\/strong><\/p>\r\n Data Retention Property (Optional)<\/strong><\/p>\r\n Data Protection Property (Optional)<\/strong><\/p>\r\n Best practice enterprise architecture<\/a> from Conexiam Navigate<\/a><\/p>\r\n\t\t\t\r\n\t\t\t\t\t\t\tSchedule Custom Enterprise Architecture Training to Boost Your Team\r\n\t\t\t<\/a>\r\n\t Let’s clarify about data needs<\/em><\/strong>– you must ruthlessly separate what’s nice to have<\/em> from what’s needed<\/em>.<\/p>\r\n Needed data<\/em> does not require modifiers like absolutely needed, or important data. Needed is simply necessary.<\/p>\r\n The clear distinction between needed<\/em> and everything else<\/em> is the foundation for effective application requirements.<\/p>\r\n Once you know that a business activity needs some data everything else emerges:<\/p>\r\n Source is a challenge- especially when the provider and consumer are in different organizations or authority, or governance domains<\/a>. We often imagine that data consumers define quality. They don’t. Data producers define quality.<\/p>\r\n Consumers can request higher quality, but they may be faced with three choices:<\/p>\r\n This is no different than any other producer\/consumer relationship.<\/p>\r\n Remember:<\/p>\r\n Data needs drive a path through fractured data landscapes.<\/p>\r\n Data needs break silos.<\/p>\r\n Data needs drive real data definitions<\/p>\r\n Data needs deliver data governance.<\/p><\/blockquote>\r\n\t\t\t\r\n\t\t\t\t\t\tBe a Better Enterprise Architect – Free 12-week Kickstart Program\r\n\t\t\t\t\t<\/a>\r\n\t Data architecture leads information systems architecture<\/a>. Information Systems Architecture is the architecture domain<\/a>\u00a0that aligns\u00a0\r\n
\r\n
![\"Data](\"https:\/\/conexiam.com\/wp-content\/uploads\/2025\/09\/AdobeStock_1491080524-1200x675.jpeg\" "\\"Data")
\r\n\tWhat is Data Architecture?<\/h2>\r\n
Enterprise Architecture Downloads and Enterprise Architecture Examples<\/a><\/h2>\r\n\t
Four Elements of Data Architecture<\/h2>\r\n
\r\n
![\"Data](\"https:\/\/conexiam.com\/wp-content\/uploads\/2025\/09\/Data-Architecture-scaled.png\" "\\"Data")
\r\n\tData Needs<\/h3>\r\n
\r\n
Major Sources of Data<\/h3>\r\n
Major Types of Data<\/h3>\r\n
Data Management Resources<\/h3>\r\n
Enterprise Architecture Training and TOGAF Training<\/h2>\r\n\t\t\t\r\n\t\t\t\t\t\t\tCustom Enterprise Architecture Training to Boost Your Team\r\n\t\t\t<\/a>\r\n\t
Navigate Data Architecture Model Kinds<\/h2>\r\n
\r\n
Navigate Model Kind Description<\/h3>\r\n
\r\n
Enterprise Data Model Notes<\/h3>\r\n
Subject Model<\/h3>\r\n
\r\n
\r\n
\r\n
\r\n
![\"Data](\"https:\/\/conexiam.com\/wp-content\/uploads\/2025\/09\/Data-Structure.png\" "\\"Data")
\r\n\tSubject Area Model<\/h3>\r\n
Logical Data Model<\/h3>\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
Logical Document Model<\/h3>\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
\r\n
Go Further with Best Practice Enterprise Architecture Process and Method<\/h2>\r\n
Everything Revolves Around Data Needs<\/h2>\r\n
\r\n
\r\nNeeded data defines where the flow must get to.<\/li>\r\n
\r\nNeeded data defines quality.<\/li>\r\n
\r\nSecurity doesn’t define where data can go. Needed data goes where it is needed. Needed data defines where the data\u00a0must<\/em> be securely delivered, and where it must be secured.<\/li>\r\n
\r\nNeed + quality + flow + security define the data management resources required<\/li>\r\n<\/ul>\r\n\r\n
Enterprise Architecture Consulting Workshops<\/a><\/h2>\r\n\t\t\t\r\n\t\t\t\t\t\t\tContact us to get enterprise architecture consulting helping you\r\n\t\t\t<\/a>\r\n\t
Conclusion of\u00a0What is Data Architecture?<\/h2>\r\n