Try to look at the organizational values or the architecture principles in general, and work outward from there.
Considering that data and the structural quality thereof as a major corporate asset, the importance of data architecture is often
overlooked, despite in many organizations data being the true business jewels.
Applications come and applications go, ‘Big Data’ is hot, ‘small data’ is
helpful, but do you have solid data architecture as a foundation, is there
proper data management strategy, how should you measure Key Performance Indicators (KPI) or Critical Success Factor (CSF) of DA effectively?
Data Reference
Architecture: The chief data architect is the steward of an organization's
information base and data flows. This requires a foundation for allowing others
to classify the nature of the data in question and understand how to apply that
sources of data to the overall data management strategy and reference
architecture.
3. KPIs for Data
Architecture
Generally speaking, there are two or more groups to work on the data: 1). One group is responsible to define the enterprise data entities 2). And another group is responsible to use the entities to develop the Logical & Physical Data model. How could you measure the performance of these two groups together?
3) Could the items mentioned below be critical success factors
for both the groups combined?
- Percentage of Enterprise Data Entities being identified & used to design Data Model
- Percentage of Data Entities that are assured to be identified for a project by the Service while delivering the Logical Data Model.
- Anything around the scalability of the data model by the architects?
- Anything around design for performance by the architects?
-Are the models for the Data Architecture current with the business data model?
-Is the Data Architecture documentation up to date?
Is data redundancy minimized to n %?
-Are the DBAs skills current with the current IT Operating Model
Considering that data and the structural quality thereof as a major corporate asset, the importance of data architecture is often
overlooked, despite in many organizations data being the true business jewels.
Applications come and applications go, ‘Big Data’ is hot, ‘small data’ is
helpful, but do you have solid data architecture as a foundation, is there
proper data management strategy, how should you measure Key Performance Indicators (KPI) or Critical Success Factor (CSF) of DA effectively?1. Data Management Strategy & Data Architecture
Data Management Strategy is an integral element of overall IT strategy which is also critical
ingredient of business strategy, A solid data strategy must be both practical
and extensible. This has to include data flows in & out of the organization and
under what circumstances use of standard file systems is considered
permissible. And how well does this strategy allow for changes to the business
or new technologies.
Four Perspective of
Data Architecture: For data-architecture, the non-functional (qualitative)
requirements are usually more important than the functional ones. Obvious
examples include security, privacy, and data quality management, and all the usual compliance checks.
Any applicable law or industry-standard implies a performance-indicator of some
kind. There are four perspectives that any architecture must keep in mind and
those are
-Performance
-scalability
-risk/governance
-availability/fault tolerance
-scalability
-risk/governance
-availability/fault tolerance
2. Data Reference Architecture, Framework & Standards
Data Reference
Architecture: The chief data architect is the steward of an organization's
information base and data flows. This requires a foundation for allowing others
to classify the nature of the data in question and understand how to apply that
sources of data to the overall data management strategy and reference
architecture.
Framework: The
rules and procedures for implementation/integration/etc of data resources must
have clear and extensible rules for maintaining the strategy and reference
architecture. The framework must include procedures for altering the above, or
otherwise submitting proposals for doing so based on local requirements.
Standards: The data architecture should have clearly defined sets of tools, rules (best practices) & requirements for usage, and standards for implementation at a detailed level to ensure consistency across the organization. This helps reduce costs in so many ways, especially with training new hires, or transferring resources from one department/project to another.
Standards: The data architecture should have clearly defined sets of tools, rules (best practices) & requirements for usage, and standards for implementation at a detailed level to ensure consistency across the organization. This helps reduce costs in so many ways, especially with training new hires, or transferring resources from one department/project to another.
Flexibility: to
be added as necessary. In general, consistency is a virtue in data
management, but there has to be enough flexibility to allow new technologies and
deliverables for analysis, design, construction, and administration of data that should be clear and evident.
3. KPIs for Data
Architecture
Try to look at the
organizational values or the architecture principles in general, and work
outward from there. Every principle (such as transparency) implies an architecture-principle
(design for transparency) that implies a KPI (or perhaps non-key performance-indicator)
of some kind. You could derive a suitable unit of work/output for the
enterprise group. And there are two levels of delivery.
1) the entities and relationships
2) the attributes and metadata/descriptions.
1) the entities and relationships
2) the attributes and metadata/descriptions.
Generally speaking, there are two or more groups to work on the data: 1). One group is responsible to define the enterprise data entities 2). And another group is responsible to use the entities to develop the Logical & Physical Data model. How could you measure the performance of these two groups together?
1) 1st group: as some things will be more complex
than others, so you need to factor in all three elements
-the number of entities as a measure of business complexity
-the number of relationships as a measure of the architecture complexity
-a number of attributes as a measure of granularity.
2) Theoretically, the second group outputs are reuse,
-number of models as a measure of reuse
-number of entities as a measure of business complexity
-number of relationships as a measure of the architecture complexity
-number of attributes as a measure of granularity.
-the number of entities as a measure of business complexity
-the number of relationships as a measure of the architecture complexity
-a number of attributes as a measure of granularity.
2) Theoretically, the second group outputs are reuse,
-number of models as a measure of reuse
-number of entities as a measure of business complexity
-number of relationships as a measure of the architecture complexity
-number of attributes as a measure of granularity.
3) Could the items mentioned below be critical success factors
for both the groups combined?- Percentage of Enterprise Data Entities being identified & used to design Data Model
- Percentage of Data Entities that are assured to be identified for a project by the Service while delivering the Logical Data Model.
- Anything around the scalability of the data model by the architects?
- Anything around design for performance by the architects?
-Are the models for the Data Architecture current with the business data model?
-Is the Data Architecture documentation up to date?
Is data redundancy minimized to n %?
-Are the DBAs skills current with the current IT Operating Model
4) KPIs at
transaction Level (DBA):
a) transactions/sec (performance, scalability)
b) mean-time of a transaction (performance, scalability)
c) mean-latency time for a transaction (performance, scalability)
d) daily mean-latency time for a transaction (daily average, scalability)
e) transactions-per-day (scalability)
f) daily mean-latency time for a transaction per transaction ( d / e, scalability)
g) total failed logins per day (security)
h) total failovers per day (availability)
i) daily mean-time for failover to secondary service (availability
b) mean-time of a transaction (performance, scalability)
c) mean-latency time for a transaction (performance, scalability)
d) daily mean-latency time for a transaction (daily average, scalability)
e) transactions-per-day (scalability)
f) daily mean-latency time for a transaction per transaction ( d / e, scalability)
g) total failed logins per day (security)
h) total failovers per day (availability)
i) daily mean-time for failover to secondary service (availability
