Government App Sharing
|
|
||||||||||||||
| Home | Free Meeting Place for Government App Sharing |
|||||||||||||
| Data Architect Job Description This article offers a description of the duties of a data architect or someone filling the role of enterprise data integration manager. This article's goal is to prioritize data modeling in the data architect job description over secondary responsibilities such as data recovery planning and other responsibilities that are appearing in data architect job descriptions. By using data modeling methodologies, the data architect will provide energy at the points where energy is weakest in government: continuity in finding and managing collaborative opportunities, and integration between integratable but stovepiped systems so that data is re-tuned to the organization's mission on a daily basis. The data architect absolutely must be highly skilled in modeling data. However it should not be mandatory that they be familiar with hardware or any specific company's software. The modeling duties should be paramount and non-integration specific jobs could be assigned to others. For large organizations, it is important to not dilute the data architect role beyond data modeling simply because keeping a whole organization's data model up to date is a full time job and the data modeling role is more important than anything else. Data modeling duties cleanly separate from other duties. For example, technically setting up an XML data exchange with another agency can be assigned to a programmer. But there must be a data architect there to identify the opportunity and recommend the exchange in the first place. Likewise, a DBA can replicate data or set up secure FTP processes to logically integrate data, but the responsibility for an enterprise-wide integration plan should remain within the data architect's duties. Core function of the data architect 1. Model the data of the whole organization so that it's in 3rd normal form. Independent of where the data is stored or the processes that use it, this new view of the data reveals: (a) redundancy in the organization (b) where incompatibilities should be remedied (c) opportunities for sharing databases and services internally and externally (d) unanticipated capabilities. 2. Change the organization's
data systems to mirror the model. This aligns the organization's resources
to the organization's mission more efficiently than any other method. Detailed data architect duties To get started, data architects should implement a single source of contact for integration issues for each government organization by using a standardized naming convention for an email account that goes to the data architect's office. E.g., enterprise_integration@whitehouse.gov, enterprise_integration@omb.gov, enterprise_integration@ dmv.ca.gov, etc. Everyone in the data architect's team would receive a copy of the email so that backups respond to emails during individuals' vacations. The address is just a standard contact name for each organization. Then any data architect or anyone requiring integration information can contact data architects from any other organization, federal or state, without needing to find a mailing list. The mailing list wouldn't need to be updated because the address would be permanent. Everything, including email address names should be designed to encourage collaboration by default. The data architect should create or be part of a data governance process. The data architect's checklist, summarizes many of the duties below. The data architect must get into the conception and planning loop in all organization venues early and analyze planned computer systems and data flows for all departments to make sure that there is no redundancy, poor design, and field misnaming. Ensure that all tables are in 3rd normal form. Analyze each new IT project with an eye towards maximum potential for enterprise-wide and government-wide integration. Experience has shown me that the data architect should not make the project design wait until they have approved it. That will turn the data architect into a bottleneck. The data architect should leave the designers free to do what they want, but insist that they notify him immediately even when only a new table is designed; so the data architect can study it the same day that it was planned. A worst-case scenario would only require the designer to backtrack a few days work if the data architect found problems. This table analysis role would save the government the most money because it would prevent expensive problems from being permanently locked into systems until they were replaced, perhaps 10 or even 30 years later. Data harmonization and project management - review data fields so that the same field does not have different names for the same record throughout the enterprise. Promote standard vocabulary enterprise wide, for example, "Distributed Cost" is called "Cost Allocation" elsewhere. Promote project management discipline where possible using project management terms to help spread the project management discipline throughout the enterprise. Train and collaborate with project managers so that project management methods include enterprise architecture. The data architect should promote regular business intelligence meetings with agency representatives, attend executive business goals and strategy meetings, and be an energizing force to align IT with the organization's mission. Create a long-term, enterprise-wide plan to integrate all business systems and workflows for the whole organization, including the prioritized detailed steps and budget for the plan. Publish a yearly report of the plan's status. Publish high-level data relationship charts. Maintain centralized documentation of the integration process so that there is integration continuity. Build a database of the organization's databases and document fields that could potentially be shared enterprise wide, and also shared with other government entities, preferably added to a Data Reference Model system. The data architect should learn what all of the organization's systems do and start to model the whole organization. The big picture begins to form as opportunities are mapped out. There should be a comment area for each field where fixes or other issues can be documented. Actively look for collaborative enterprise-wide and government-wide opportunities and watch for potential conflicts with other such systems. NIEM, the National Information Exchange Model, should be explored as the schema sharing tool for state and federal government. They have training classes, a help desk and analysts to check that submitted schemas for sharable data meet standards. Identify SOA opportunities, internally and externally. Suggest new SOA opportunities that don't exit. Co-produce an expanded library of best practices of integration management with the data architect community. Coordinate with the top government CIO. Centralize documentation on what design changes need to be made to convert poorly functioning existing systems. The reality is that there often isn't enough money to replace a poorly functioning system. But the data architect should have the specs ready so that the replacement system is already fully planned out. Clients should send ideas for the new system to the data architect on an ongoing basis instead of at the last minute when the new system is about to replace the old one. Create a database of each business unit's capabilities wish list, updated yearly and whenever there are changes, so that there is the most complete picture of the agency's goals and needs. Make sure big integration projects obtain financial oversight agency approval. Keep a record of every client request to IT, indicating whether it was turned down or not, to understand the agency better and further document any possible need for integration. Metrics: keep track of maintenance that would have been unnecessary if integration had been implemented. Implement quality assurance to ensure that clients of shared applications receive good service. The purpose is to discourage client desertion where they create their own duplicate system because the shared one is not responsive to them. Educate all employees to think from an enterprise-wide viewpoint. Create an environment where enterprise wide integration is promoted throughout all facets of government. Change control - a data architect can minimize risk during change by virtue of their deep understanding of organizational data. For example, if a legacy system is going to be consolidated, the data architect could recommend a stepwise approach where first, the data is harmonized, then tables consolidated and finally only programming code would need to be changed so that the change to the new system no longer becomes an "all or nothing" panic-filled project. Build trust. The data architect should listen to clients, understand their needs, be transparent so that clients understand the reasons for everything they do, and fulfill promises quickly to establish a good track record. Once trust is established, the data architect can get the cooperation needed to reshape the organization's information systems. Participate in a worldwide forum of integration issues. Collectively, data
architects should research opportunities and advise the top federal or
state CIO regarding change or design policies and legislation that promote
integration, such as policy and budget structures that encourage system
sharing between different organizations. They should defend enterprise
integration against policies that cause fragmentation because some governmental
policies may actually promote enterprise disintegration. An example is
the way that financial oversight agencies exercise fiscal control over
IT projects. An oversight agency may author statewide policy that tends
to cancel expensive IT integration projects and instead approve smaller-budgeted
add-ons to obsolete systems that were to be replaced. When this pattern
is repeated over and over again, the net result is institutionalization
of statewide fragmentation because only stovetop applications are approved.
The short-term benefit of these types of oversight agency clampdowns is
that they reduce sensationalized failures of large IT projects. However
if this shortsighted policy is left to continue, the long-term waste of
money and loss of functionality will vastly outweigh any short-term gains.
Bigger is not always better, but data architects need to advise oversight
agencies when smaller add-ons to a broken system are worse than system
rewrites. The data architect should teach a course in data modeling to all newly hired IT and business managers, systems analysts, project managers including the whole PMO department, developers and programmers so that they can learn how to fit in with the agency's overall enterprise architecture plan and learn how to work with the data architect. This will prevent problems such as when middle managers buy what seems to be a cheap COTS solution, but is in reality a stovepiped data silo that creates decades of interoperability problems. Instead of COTS, using an in-house built solution, if appropriate, would last forever because it would bring the whole enterprise one step closer to full integration. Finally, a data architect should encourage all employees to take an interest in integration matters and send suggestions that will improve integration. An intranet website should educate employees about enterprise-wide integration. The data architect should create a culture of collaboration, and an environment where planning for information sharing is an integral part of the organization's personality. The data architect position would in effect, guarantee that government is perpetually guided towards integration through standardized policies and procedures that prioritize data modeling. The data architect would consistently align information systems to government's mission. ->> The next
article discusses a new software development methodology that should be
used to implement the data architect's integration projects and all business
IT projects: Enterprise Focused
Development
|
