Center for Government Interoperability

Blueprint For Better Government

http://gov-ideas.com/

Center for Government Interoperability

Government Ideas

Recommendations for Implementing Enterprise Data Architecture

We have got to define table modeling as the main tool for bringing IT into alignment with government's mission. It must remain government's focus in perpetuity.

The definition of table modeling here is broad in that it involves harmonizing data with outside governmental organizations, sharing data and systems with those organizations, and bringing continuity to table analysis and table updates driven by business intelligence.

Here is an overview of how to start implementing enterprise data architecture so that table design is the primary focus.

1. Appoint someone to be a data architect for each organization. They must be highly skilled in data modeling and understand how to transform business requirements into data tables.
2. Whenever a table is planned, created or changes, the data architect will review it for enterprise integration opportunities. This includes potential future projects, checking external organizations for integration potential and building in business intelligence during the design phase.
3. Each time there is change, there is an opportunity to bring government's entire data one step closer to third normal form. Redundant table removal, SOA opportunities coming into focus, data harmonization and removing business rules from programming code and placing them into tables are some of the opportunities that change brings. Once business rules are out of programming code and in tables, they are de-siloed and available to be shared enterprise-wide. Legacy systems should be included because even when they are replaced, conversion will be far easier when their files are normalized. Also, maintenance headaches from these systems will be greatly reduced.
4. Following this process, IT will move towards what I call super-alignment to the organization's mission where IT can nimbly deliver new features and solve problems in the most efficient way.

Super-alignment to the organization's mission is clearly possible because E.F. Codd's invention, the relational model for database management, which is based on relational algebra, brings data to efficiency perfection using easy-to-follow rules. Simply bringing organizational data into third normal form resolves business problems throughout the organization and improves IT alignment to the organization's mission in the most powerful and cost effective way.

It is amazing that such a simple, mathematically based solution is available to solve so many problems.

Third normal form is smarter than programmers, analysts, managers and government. Implementing third normal form unthinkingly, blindly, yields more intelligent results than process oriented humans. Many times when making the slightest variance from strict normalization, I have been surprised to find that there was hidden value in the strict form and needed to go back and correct the table design.

Incrementally re-engineer systems during change opportunities

Each time there is a single integration improvement, IT removes subtle roadblocks to supporting the organization's mission. Then data silos inexorably become accessible, clients' problems disappear, maintenance problems are reduced and connectivity opportunities open up across government. This stepwise approach is a little like government being a boa constrictor when battling an enemy. Whenever its enemy breathes out, the boa's coils tighten a little more. In our case, the enemy is disintegrated data, so whenever there is change, our version of tightening our coils is to integrate the data a little more until data silos are gone and strong alignment to the organization's mission is accomplished. This incremental method is also the least expensive approach.

Each time there is change, the data architect should update an integration map of how the table needs integration, or is available for integration.

Normalization principles are immune to subjective bias so they should be easy to implement. But why then is IT in its current state? Don't IT managers have degrees in computer science and know this already? Shouldn't they have already fixed most IT business problems? Several factors impede integration.

Programmers are rewarded for quickly finishing a project, not for looking for integration opportunities outside of their project. Programmer skill is improving regarding normalizing data within their control, but not beyond their unit or department. They are not trained to ask, "Does the next unit use the same table as I do?" These lost integration opportunities result in redundant data and processes. Managers like to show "project completed" to their supervisors. They do not encourage programmer cross-departmental cooperation because of the added complexity, lack of education or simply are not collaboratively inclined. This is the main problem and can be summarized as a lack of will power on the part of data managers to tackle data integration.
Contractors and vendors, because they are temporary, create runaway code without enough supervision in table design, and create new databases without understanding how they could be integrated with the rest of the organization in the future. (This problem is solved here.) There is a lack of integration continuity when data systems are deployed at different times by different vendors. The lack of integration continuity causes problems such as those in the Maricopa County, AZ justice system where different agencies assigned multiple numbers to the same criminal cases causing confusion on the part of judges and attorneys.
COTS - commercial off the shelf software is not integratable with the rest of the organization's systems because each government's core business systems are, by definition, unique.
Budget structures do not encourage co-sponsorship of systems sharable by different government entities.
Project managers from most schools of project management are not trained in enterprise architecture principles.
Security concerns discourage sharing between organizations.
Absence of Enterprise Focused Development methodologies is responsible for the lack of table improvements during system design and implementation.

One of the key things that even experienced data managers underestimate is the high degree of normalization strictness needed to keep IT in alignment with the organizational mission. Even systems that have recently been rewritten from scratch begin to disintegrate if small changes are not evaluated for integration opportunities. This leads us to a very unusual conclusion not heard often in the IT world. If enterprise data were always kept fully normalized and updated for business rule changes, no rewrites of computer systems would be necessary. Even legacy systems would eventually offer as much value as new systems using the stepwise process above, and the only reason for migrating away from them would be to save money on cheaper platforms, but their data functionality would be perfect. This underscores the enormous value of focusing government on table modeling. Add up the cost of small, medium and largest system rewrites, unnecessary maintenance, unnecessary labor and lost functionality to see the true value of keeping data models fine-tuned. It is stupendous. Government IT must remain focused on table modeling.

Integration Help Desk

A centralized help desk should be created in each state to assist all of the state's agencies in connecting data between internal and external departments.

A component of the help desk should include experts who offer SOA, security, web services and other technical help in establishing data exchanges. This would speed up connectivity implementation first identified by the data architect in each organization, and free the data architect from work that is not part of their core function, modeling data.

The following article recommends a description of the duties of a data architect, who should be the chief person focusing on modeling their organization and the whole government.

Next->> Recommendations for data architect duties