/
Enterprise Data Architecture and Platform Governance
Save to my account
Sign up
Enterprise Data Architecture and Platform Governance
Enterprise Data Architecture and Platform Governance
Study
1
Question
What does whole-context architecture require beyond immediate programme needs?
Page 1
Answer
Alignment with enterprise strategy, operating models, existing capabilities, and long-term technology roadmaps.
2
Question
Which organisational risks can a standalone data platform introduce?
Page 1
Answer
Duplication, additional cost, technology-stack complexity, separate support models, security boundaries, data ownership arrangements, and integration points.
3
Question
Why can an additional standalone data platform create future migration costs?
Page 1
Answer
An enterprise roadmap may later provide the same capability, requiring migration and decommissioning.
4
Question
Which stakeholders were consulted when assessing existing data-platform capabilities?
Page 1
Answer
Business sponsors, platform owners, operational teams, security architects, and enterprise architects.
5
Question
Which criteria were used to compare data-platform options?
Page 1
Answer
Cost, delivery speed, supportability, and strategic alignment.
6
Question
Which platform did the programme ultimately select for customs data capabilities?
Page 1
Answer
Existing DWIT Lakehouse capabilities.
7
Question
What were the principal benefits of extending existing Lakehouse capabilities?
Page 1
Answer
Reduced delivery risk, avoided duplication, accelerated implementation, and lowered long-term operational costs.
8
Question
Which version-control initiative affected more than 600 analytical users?
Page 2
Answer
The Git-based version-control rollout across the analytical and data-science community.
9
Question
Which Git platforms were assessed during the tooling decision?
Page 2
Answer
GitHub Enterprise, GitLab, and Bitbucket.
10
Question
Which factors guided the selection of a Git platform?
Page 2
Answer
Usability, cost, DevOps maturity, integration potential with SAS statistical tooling, and internal hosting constraints.
11
Question
What purpose did the CRAID log serve during the Git rollout?
Page 2
Answer
It recorded risks and promoted accountability through regular review with delivery, engineering, and cybersecurity teams.
12
Question
Which concerns required escalation to design authorities?
Page 2
Answer
Repository access controls, code-auditing capabilities, and secure integration with analytical platforms.
13
Question
Which authorities provided guidance for Git decisions exceeding medium risk?
Page 2
Answer
The Technical Design Authority and Security Design Authority.
14
Question
How were disagreements about Git’s architectural role resolved?
Page 2
Answer
Analytical frameworks, stakeholder mapping, and a consensus-building session produced agreement for a phased, secure GitLab rollout.
15
Question
Which governance artefacts were created during the version-control rollout?
Page 2
Answer
Lightweight architectural artefacts documenting design rationale and version-control strategy.
16
Question
Which outcomes resulted from the GitLab rollout?
Page 2
Answer
Improved collaboration, version traceability, and delivery quality within the analytical community.
17
Question
Which ingestion patterns were considered for near-real-time trader data access?
Page 3
Answer
Direct push, change data capture, micro-batching, API polling or webhook-to-Kafka, edge streaming, and Kafka replication via MirrorMaker.
18
Question
Why was Kafka replication via MirrorMaker selected for the use case?
Page 3
Answer
It provided advanced filtering and consumer-offset synchronisation suited to the use cases.
19
Question
Which technical use cases were defined for the data-consuming layer?
Page 3
Answer
Message reordering, schema validation, schema evolution, forward and backward compatibility, and parallel pipeline execution.
20
Question
What was the purpose of prototyping the proposed ingestion approach?
Page 3
Answer
To validate critical technical requirements without compromising near-real-time non-functional targets.
21
Question
Which service procurement supported real-time data synchronisation across consumers?
Page 3
Answer
New Talend ESB services.
22
Question
What architectural lesson emerged from framing the data-sharing challenge early?
Page 3
Answer
Early framing supports sustainable choices for scalability, resilience, and enterprise alignment.
23
Question
Which capability did the Entity Resolution and Matching programme provide?
Page 4
Answer
Identification of complex structures and detection of multi-million-pound VAT and payroll fraud schemes.
24
Question
What architectural risk arose from different programmes interpreting the platform differently?
Page 4
Answer
Inconsistent architectural designs and approaches across programmes.
25
Question
Which architecture communities were engaged to create shared understanding?
Page 4
Answer
Solution, enterprise, security, and data architects, together with delivery leads and product teams.
26
Question
Which architectural states were explained during the engagement sessions?
Page 4
Answer
The current state, transition state, and target state.
27
Question
Which additional subjects were covered alongside architectural states?
Page 4
Answer
Business outcomes, integration patterns, and the future roadmap.
28
Question
Why was challenge encouraged during architecture engagement sessions?
Page 4
Answer
Questioning the design could improve the solution through constructive discussion.
29
Question
Which reusable assets were shared across architecture teams?
Page 4
Answer
Reusable architecture patterns and lessons learned from other programmes.
30
Question
What organisational outcomes followed the Entity Resolution engagement?
Page 4
Answer
Consistent platform understanding, improved collaboration, reduced design divergence, and greater governance-review confidence.