KPIs or CSFs for Data Architecture

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?

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  

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.

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. 

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) 1^st 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. 

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

Posted in: Big Data,EA,Information/Data Management,IT Performance Management,KPIs