Shared Architecture View
A consistent picture of domains, systems, platforms, flows and dependencies across stakeholder groups.
Enterprise Data Architecture
Current State Data Architecture That Gives Transformation Teams an Evidence-Based Baseline
DataConsultant maps how data actually moves through your organisation today—across business domains, source systems, integration, data platforms, analytics, AI, ownership, controls and operations. The engagement turns fragmented diagrams and undocumented dependencies into a validated baseline that leaders, architects and delivery teams can use for target-state design, rationalisation, governance and investment decisions.
Map systems, platforms, data flows and dependencies
Validate ownership, controls, interfaces and operational realities
Expose fragmentation, technical debt, evidence gaps and risks
Create a decision-ready baseline for future-state architecture
Timeline and commercial terms are confirmed after scoping the architecture boundary, evidence quality, stakeholder access, systems, platforms, interfaces and required level of detail.
Current Architecture Baseline
Evidence-led view
Evidence Traceability
Architecture statements linked to documents, repositories, technical evidence, interviews and known limitations.
Decision-Relevant Gaps
Fragmentation, technical debt, ownership ambiguity, control weaknesses and undocumented dependencies made visible.
Target-State Readiness
A defensible baseline for future architecture, rationalisation, roadmap, governance and investment choices.
1 When the estate is no longer understood consistently
Current-State Uncertainty Creates Rework, Risk and Competing Architecture Narratives
A baseline is most useful when different teams hold different versions of the architecture, major change depends on undocumented interfaces, or leaders need evidence before approving a target state, platform investment or remediation programme.
Common signals that the baseline is missing
The problem is rarely a lack of diagrams alone. It is usually a lack of validated context about how the estate behaves, who owns it and which dependencies matter.
01Architecture diagrams conflict with platform inventories, delivery reality or vendor documentation.
02Data moves through manual files, point-to-point interfaces or hidden transformations that are difficult to trace.
03Teams cannot agree which systems are authoritative, where data is mastered or who owns important datasets.
04Cloud, analytics, AI, ERP or integration change is being planned without a reliable dependency map.
05Security, privacy, quality, retention, lineage or operational controls are documented separately from architecture.
What should be retained?Identify platforms, flows and capabilities that remain fit for purpose and should be protected during change.
What should be rationalised?Expose overlaps, duplicate stores, repeated integrations and redundant platform capabilities for review.
What must be controlled?Connect architecture to ownership, data quality, security, privacy, lineage, resilience and evidence needs.
What constrains the target state?Make legacy dependencies, contracts, skills, operational limits, regulatory context and transition risks visible.
Where is evidence weak?Separate confirmed facts from assumptions, missing documentation and unresolved stakeholder questions.
What decision comes next?Translate findings into clear questions for target-state design, governance, integration or platform planning.
Need one trusted view of a fragmented data estate?
Define the architecture boundary, priority decisions and evidence sources before teams commit to a future-state design or platform programme.
2 Direct service definition
What Current State Data Architecture Means in Practice
The engagement is a structured discovery and architecture-mapping exercise. It establishes a traceable picture of the present estate at the level of detail needed for the decision in front of you.
An architecture baseline, not a prettier redraw
DataConsultant connects business context, data domains, systems, stores, integration, processing, consumption, ownership, controls and operating responsibilities into one coherent current-state view. Existing diagrams are reconciled with evidence and stakeholder knowledge rather than copied without validation.
The objective is not to document every component at equal depth. The objective is to capture enough reliable detail to explain the material architecture, identify important dependencies and gaps, and support the next set of enterprise decisions.
3 Architecture coverage model
Map the Estate Across Six Connected Architecture Lenses
Coverage is adapted to the business question. A current-state baseline can stay at enterprise context level or go deeper into selected domains, platforms, interfaces or control areas.
1. Business & Data Domains
Business capabilities, critical information needs, data domains, authoritative sources, accountable owners and cross-domain dependencies.
Typical evidence: operating models, domain maps, process documentation, stakeholder interviews.2. Sources, Systems & Stores
Operational applications, databases, files, external sources, master systems, warehouses, lakes, lakehouses and specialised stores.
Typical evidence: application inventories, repositories, platform metadata, architecture diagrams.3. Integration & Data Movement
APIs, events, streaming, batch, ETL/ELT, replication, file exchange, orchestration, transformations, reconciliation and hand-offs.
Typical evidence: interface catalogues, job schedules, integration specs, logs and engineering review.4. Consumption & Data Products
Reporting, BI, semantic models, analytical products, operational data use, data science, model inputs, AI-enabled services and external sharing.
Typical evidence: report inventories, semantic models, product catalogues, usage and dependency information.5. Governance, Security & Privacy
Ownership, access, classification, quality, metadata, lineage, retention, residency, privacy, auditability, risk and policy touchpoints.
Typical evidence: policies, control matrices, catalogues, quality reports, lineage tools and risk findings.6. Operations, Change & Cost Context
Environment boundaries, support ownership, monitoring, incidents, change pipelines, capacity, resilience, licensing context and active programmes.
Typical evidence: runbooks, incident/change records, service inventories, cost reports and transformation plans.RepositoriesArchitecture, application and configuration records
Technical evidenceMetadata, interfaces, logs, catalogues and configuration
DocumentsPolicies, standards, diagrams, contracts and operating procedures
StakeholdersBusiness, architecture, engineering, governance and operations
LimitationsMissing, inconsistent or unverified evidence recorded explicitly
Do your diagrams match how data really moves?
Use a structured evidence register and stakeholder validation process to separate confirmed architecture facts from assumptions and outdated documentation.
4 From evidence to validated baseline
How DataConsultant Builds the Current-State Architecture
The sequence is scaled to the scope and evidence available. Each stage produces an explicit output so the baseline remains traceable and reviewable.
01
Frame
Confirm business drivers, decisions, architecture boundary, stakeholders and known constraints.
Output: scope & evidence plan02
Collect
Gather diagrams, inventories, metadata, interface records, controls, policies and operating evidence.
Output: evidence register03
Map
Connect domains, sources, stores, flows, platforms, consumers, ownership and control points.
Output: architecture views04
Validate
Review the architecture with business, technical, governance, security and operations stakeholders.
Output: confirmed facts & gaps05
Analyse
Identify fragmentation, dependencies, debt, control issues, bottlenecks, ambiguity and decision risks.
Output: findings register06
Baseline
Publish the agreed current-state pack, limitations, priorities and questions for the next decision stage.
Output: decision-ready baseline5 Deliverables
Architecture Outputs Built for Executive, Architecture and Delivery Decisions
The exact pack is agreed during discovery. Deliverables are selected according to the architecture boundary, evidence available and the decisions the organisation needs to make next.
| Deliverable | What it contains | Why it matters | Primary users |
|---|---|---|---|
| Current-state architecture landscape | Domains, major systems, platforms, stores, integration, consumption and cross-cutting controls. | Creates a common enterprise view of the material estate. | Executives, architects, transformation leaders |
| System & platform inventory | Role, owner, environment, lifecycle context, main data responsibilities and known dependencies. | Supports rationalisation, accountability and transition planning. | Architecture, platform, procurement, operations |
| Data-flow & integration views | Source-to-consumption paths, interfaces, transformations, movement patterns and key hand-offs. | Makes hidden dependencies and fragile movement visible. | Engineering, integration, security, operations |
| Ownership & control map | Data owners, platform owners, stewardship, access, quality, lineage, security, privacy and operational control points. | Connects architecture to accountability and assurance. | Governance, risk, security, privacy, audit |
| Findings, gaps & technical-debt register | Evidence-backed issues, impact, dependencies, affected areas, owners and unresolved questions. | Separates material problems from diagramming detail. | Sponsors, architecture boards, programme teams |
| Evidence & assumption register | Sources reviewed, confidence, conflicting records, missing evidence, assumptions and validation status. | Preserves traceability and prevents unverified claims becoming architecture fact. | Architecture, assurance, internal audit, programme governance |
| Executive baseline & next-decision pack | Key architecture facts, constraints, risks, decision themes and recommended next questions. | Provides a clear hand-off into target state, roadmap, governance or remediation. | Executive sponsors, CDO/CIO/CTO, transformation leaders |
Need a baseline your architecture board can challenge and approve?
Agree the evidence, architecture viewpoints, findings format and hand-off decisions before the assessment starts.
6 Findings and decision traceability
Turn Architecture Observations Into Prioritised Questions, Not a List of Diagrams
A useful current-state assessment connects each finding to evidence, business or operational impact, ownership and the decision it should influence.
Overlapping stores, tools, interfaces, datasets, transformations or semantic assets that create repeated cost and inconsistent outcomes.
Undocumented hand-offs, manual files, jobs, interfaces or shared services that could affect migration and change sequencing.
Unclear responsibility for authoritative data, platforms, controls, quality, changes, incidents or lifecycle decisions.
Architecture areas where access, classification, quality, lineage, retention, privacy, resilience or audit evidence is incomplete.
Unsupported patterns, brittle integrations, ageing platforms, manual workarounds and constraints that shape future change.
Conflicting repositories, missing documentation, unverified architecture statements and areas requiring deeper technical validation.
7 Client participation
What We Need From Your Teams to Build a Reliable Baseline
The quality of the baseline depends on evidence and access to people who understand how systems and data are actually used. Missing information is treated as a limitation, not filled with unsupported assumptions.
Architecture artefactsExisting diagrams, repositories, standards, principles, system and platform inventories.
Data & integration evidenceInterface lists, lineage, catalogue records, pipeline/job information, data-flow documents and selected technical metadata.
Governance & control evidenceOwnership records, policies, access models, data-quality outputs, risk findings and audit observations where relevant.
Operations evidenceRunbooks, incident patterns, monitoring, change records, resilience information and service ownership.
Transformation contextCloud, ERP, analytics, AI, integration, M&A, regulatory or operating-model initiatives that depend on the architecture.
Stakeholder accessBusiness owners, enterprise/data architects, engineers, governance, security, privacy, operations and vendors as needed.
8 Commercial clarity
Custom Scope & Pricing for Current State Data Architecture
DataConsultant does not publish a fixed fee for this service. A written quote should follow initial discovery because the effort changes materially with estate size, documentation quality, architecture depth and the number of systems, domains, platforms and stakeholders in scope.
Request a scoped proposal
Price the evidence and decision scope—not a generic diagram count
The commercial proposal can define the architecture boundary, deliverables, assumptions, client responsibilities, exclusions, review cycles and the basis for any follow-on target-state or implementation work.
Request a QuoteEstate breadthNumber of domains, business units, systems, data stores, platforms, environments and jurisdictions.
Integration complexityInterfaces, pipelines, events, files, transformations, partners and undocumented dependencies.
Evidence qualityAvailability and reliability of diagrams, inventories, metadata, catalogues, controls and operational records.
Required architecture depthEnterprise context versus detailed domain, platform, flow, logical or control viewpoints.
Stakeholder & validation effortInterviews, workshops, vendor participation, review groups, decision forums and formal approval cycles.
Adjacent scopeWhether target-state design, roadmap, platform rationalisation, governance remediation or implementation assurance is included.
Timeline is also confirmed after scoping. No fixed turnaround, staffing level, day rate or numeric market range is presented here because the page does not have a verified like-for-like DataConsultant price for this exact enterprise service.
Before you design the future state, make the present estate explicit
Use the current-state baseline to expose the constraints, ownership, dependencies and control requirements your target architecture must address.
9 Fit and decision guidance
When This Service Is the Right Starting Point—and When It Is Not
A current-state architecture is valuable when uncertainty about the existing estate is blocking a material decision. A narrower technical review may be better when the issue is already isolated and well understood.
Good fit
- Target-state architecture, cloud modernisation or platform rationalisation needs a defensible baseline.
- Architecture documentation is inconsistent across teams, repositories or vendors.
- Data flows and integration dependencies create uncertainty for major change.
- Governance, security, privacy or quality responsibilities are disconnected from architecture views.
- M&A, ERP, analytics, AI or data-platform programmes need a shared current-state picture.
- Executive or architecture governance needs evidence before approving investment or transition decisions.
May not be the right fit
- A single pipeline, report or configuration issue already has a clear technical owner and solution path.
- The requirement is purely target-state design and a validated baseline already exists.
- The organisation needs a statutory audit, penetration test, legal opinion or certification.
- There is no accountable sponsor, architecture boundary or access to evidence and stakeholders.
- The desired outcome is only a vendor selection without architecture, control or operating context.
- The scope cannot record limitations even when evidence is incomplete or contradictory.
10 Why DataConsultant
Architecture Advice That Connects Evidence, Controls and Delivery Reality
The value of the engagement comes from making architecture facts usable for decisions, not from producing a large volume of diagrams.
Evidence-led
Existing diagrams are validated against repositories, technical information, controls and stakeholder knowledge. Limitations remain visible.
Cross-functional
Architecture is considered alongside data domains, engineering, governance, quality, security, privacy, operations and active change.
Decision-oriented
Findings are connected to the next architecture, rationalisation, roadmap, control or investment decisions the organisation must make.
Built for handover
Architecture views, evidence registers, decisions and working sessions are structured so internal teams can maintain and reuse the baseline.
12 Frequently asked questions
Current State Data Architecture Questions From Enterprise Buyers
Scope, evidence, deliverables, access, controls, timeline, pricing and the relationship with target-state architecture.
What is current state data architecture?
Current state data architecture is an evidence-based representation of how data is created, moved, stored, transformed, governed, secured and consumed across the organisation today. It documents the systems, platforms, data domains, interfaces, ownership, controls, dependencies, pain points and material constraints that shape future architecture decisions.
How is this different from a target state data architecture?
A current-state architecture describes the estate that exists now and the evidence behind it. A target-state architecture defines the future structure, principles, platform roles and transition direction. DataConsultant can use the current-state baseline as an input to a separately scoped target-state design, but the two are not treated as the same deliverable.
What is normally included in a current state data architecture engagement?
Scope can include business and data domains, source systems, databases and data platforms, integration and data flows, analytics and AI consumption, metadata and lineage, data quality, master and reference data, security and privacy controls, operational dependencies, ownership, technical debt, costs where evidence is available, and current change initiatives. Final coverage is agreed during scoping.
What deliverables can we expect?
Typical outputs can include an architecture landscape, system and platform inventory, data-domain map, source-to-consumption flow views, interface and dependency register, ownership and control map, architecture findings and gap register, technical-debt and risk themes, decision log, evidence register, executive baseline report and a prioritised set of questions for target-state or remediation work.
What information do you need from us?
Useful inputs include existing diagrams, application and platform inventories, interface lists, data-flow documentation, policies and standards, data catalogues, lineage or quality reports, incident and change records, cloud or infrastructure information, current transformation plans and access to business, architecture, engineering, governance, security, privacy and operations stakeholders. Missing evidence is recorded rather than silently assumed.
What if our documentation is incomplete or out of date?
That is a common reason to commission the service. Existing documents are treated as evidence to validate, not as unquestioned truth. Workshops, repository exports, configuration evidence, technical interviews and selected system checks can be used to reconcile discrepancies. Unverified areas remain clearly marked as assumptions, open questions or evidence gaps.
Can you assess cloud, on-premises and hybrid environments?
Yes. The current-state baseline can cover cloud, on-premises, hybrid and multi-platform estates where they are in scope. The focus is on actual roles, data flows, dependencies, ownership, controls and operating realities rather than assuming that one deployment model is preferable.
Does the service include data security, privacy and governance?
The architecture can document relevant ownership, access, classification, retention, residency, lineage, quality, security, privacy and auditability requirements where they affect the data estate. It does not by itself constitute legal advice, a statutory audit, formal certification, a privacy impact assessment or penetration testing unless separately commissioned through appropriately qualified parties.
Do you need access to production data?
Not always. Many architecture questions can be answered from diagrams, inventories, metadata, catalogues, configuration information, interface specifications, logs, control evidence and stakeholder interviews. Where deeper technical evidence is needed, access requirements should be minimised and agreed before work begins. Sensitive or regulated data should not be provided unless necessary, authorised and appropriately controlled.
Can DataConsultant work with our internal architects and existing vendors?
Yes. The engagement can be structured to work alongside enterprise architects, data architects, engineers, platform owners, governance teams, security and privacy specialists, business-domain owners, procurement teams, systems integrators and software vendors. Responsibilities, access, evidence ownership and review decisions should be agreed at mobilisation.
How long does a current state data architecture engagement take?
A reliable duration is confirmed after scoping. Timing depends on the number of business domains, systems and platforms, quality of existing documentation, stakeholder availability, evidence access, geographic or regulatory complexity, required architecture depth and the number of validation cycles.
How is pricing determined?
DataConsultant does not publish a fixed fee for this service. Pricing is confirmed after scoping and is influenced by estate size, number of domains and platforms, interface complexity, evidence quality, workshops, required architecture viewpoints, security and privacy review needs, documentation depth, onsite participation and whether target-state design or implementation planning is added.
What happens after the current-state baseline is complete?
The baseline can support target-state architecture, platform rationalisation, integration modernisation, data governance improvement, cloud or analytics transformation, risk remediation, procurement, programme mobilisation and architecture assurance. The next step should be selected from the findings and decisions required rather than assumed in advance.
Current State Architecture Enquiry
Request a Current-State Scope Review
Share your contact details and requirement. DataConsultant can review the likely architecture boundary, evidence needs, stakeholder involvement and an appropriate commercial approach.