Center for Government Interoperability

Opportunities checklist for new software projects

A simple shortcut to ensure that interoperability checks become a permanent part of everyone's organizational structure

One of the easiest implementation methods for enterprise data integration is the distribution of a checklist to anyone that designs a business application or data table.

Potentially free from bureaucratic policy implementation slowdowns, the checklist can just be emailed to stakeholders of any business software project and looked over for data interoperability and other opportunities.

The basic idea of this checklist is to ask a simple question whenever a new business system or data table is created:

If this is new data or software: Can it be shared elsewhere?

Examples of implementation methods include:

  1. Project Management Office making the verification of checklist use a standard deliverable for all IT projects, and
  2. programmers adding the checklist to their System Development Life Cycle.

The goal is for this checklist to be applied by the broadest possible group of government and private industry organizations for all business programs or data tables that are being newly designed or about to be changed so that interoperability checks become a permanent part of everyone's organizational structure.

If every private and government organization adopted this simple checklist, it would result in a significant and permanent shift towards improved business processes.

The mere distribution of the checklist is the simplest way to get enterprise data integration going.

To obtain notification of updates of this list, email a request to me. Your information is not shared with anyone.

Here is the checklist.

 

Checklist for every new business
application, table or field

  • Changing a legacy system. Legacy systems should never exist. Those systems should instead be continually refactored. Then the main focus of the IT shop is to continually keep the data model in 3rd Normal Form in a way that meets new requirements. Data is a virtual format that never wears out like a physical machine. The thinking that when software gets old, it requires replacement like a car is misguided. The correct way to manage change is to continually update the application with rigorous attention to modeling changes in the database. [Documentation and comments]

  • Correct data modeling (3rd normal form), correct keys. (Data Architect, IT) [Documentation and comments]

  • Interoperability: Cross agency data and process sharing opportunities, including, API, SOA, NIEM, and Web Services (Data Architect, IT and business side) [Documentation and comments]

  • Can an additional "organization_ID" field be added so that multiple agencies can concurrently use tables or programs as a centralized "cloud" application? (Executive office, CIO, Data Architect, IT and business side) [Documentation and comments]

  • New software system. Can this software system be obtained from (a) open source (b) GOTS or (c) shareware sites. Or, can this software become (a) open source (b) GOTS or (c) shareware? Consider making all apps open source that have potential to be used by others. Can an old system simply have its data model refactored to obtain same functionality as new a new system? (Data architect, IT). [Documentation and comments]

  • Can any new programming effort be backed out of in case new code does not work? Is there a backup plan?

  • Can any business processes be improved with existing data or be improved by changing the data model? Are there opportunities to re-engineer small, medium, or large, core, foundation business processes with new data models? (Data Architect, IT and business side) [Documentation and comments]

  • Can this data be replaced by a better source of data elsewhere or replace other data? Can whole tables be eliminated by consolidation and sharing? (Data Architect, IT, business side and federal or state CIO) [Documentation and comments]

  • Prioritize super connector fields and super connector tables. [Documentation and comments] (Data Architect, IT and business side)
  • Can this data be used to validate other data or does it need validation performed on it? (Data Architect, IT and business side)

  • Business Intelligence - data mart/data warehouse opportunities. (Business side) [Documentation and comments]

  • Data harmonization problems or opportunities. (Data Architect, IT and business side) [Documentation and comments]

  • Standards evaluation - Are there standards to be adhered to or created? (Data Architect, IT and business side) [Documentation and comments]

  • Alignment to organizational mission. Strategic planning problems or opportunities. (Data Architect, IT and business side)

  • Enterprise Architecture planning. How does it align with to the "To Be" architecture? (Enterprise Architect, Data Architect, IT and business side)

  • Impact on other systems. (Change Management Board, Data Architect, IT and business side) [Documentation and comments]

  • Metrics generation opportunities - Can this field or table create useful metrics or appear on a dashboard? Customers could include boards, licensees, the public, finance, governor's office and the legislature (business side)

  • Metadata opportunities (business side)

  • KPI - Key performance indicators opportunities. Are there opportunities to use the field/table to measure performance? (Data Architect, IT and business side)

  • Risk (Data Architect, IT and business side) [Documentation and comments]

  • Security. Should it be encrypted? Should backups be encrypted? What controls should be applied? (Data Architect, IT, business side and ISO) [Documentation and comments]

  • Is data subject to legislative oversight or mandates? (Data Architect, business side) [Documentation and comments]

  • Should clients be given control of the data? (Business side, IT) [Documentation and comments]

  • Would a data steward be useful for this data? (Data Architect, IT and business side)

  • Backup considerations - how often should it be backed up? How does it get refreshed when there is a crash? When should it be purged? (IT and business side)

  • Can data quality be improved? Is data cleansing applicable? (IT and business side) [Documentation and comments]

  • Quality management - are clients satisfied? Is quality management and continual process improvement built into this system? (Data Architect, IT and business side) [Documentation and comments]

  • Automated duplicate detection (IT)

  • Timeliness. Is there value to the organization if the data is refreshed sooner or by other ways? (IT and business side) [Documentation and comments]

  • Review for entry into a table of future opportunities and linked to a calendar of related opportunities or future change events. (Data Architect) [Documentation and comments]

  • Optimization by combining multiple projects (past, future or ongoing projects). (Data Architect, business side, IT) [Documentation and comments]

  • Are there opportunities from making this available to a broader audience? Customers that are not immediately evident could include government boards, licensees, NIEM, the public, police and investigative organizations, finance, governor's office, and the legislature. See Open Data and Open Government. (Data Architect, IT and business side)

  • Audit policy - should the field or table be have its edit or use history recorded (IT and business side)

  • Error management. How should the system respond to the errors? E.g., should stakeholders be notified if there are errors in the data? (IT and business side)

  • Are the business rules table-driven and controllable-by-clients where feasible? (Business rules should not be in programming code.) (IT, Data Architect)

  • Data tuning - is it fast enough? Is denormalization required? (IT) [Documentation and comments]

  • Field size and type - will the field be able to contain larger amounts of data 10 years from now? Is it the right type of field (alphanumeric, numeric, etc.) [Documentation and comments]

  • Field and table added to data dictionary

  • Restartability - have data and system been designed so that crashed programs restart without concern for partially filled data or partially completed processes? Has documentation been clearly communicated to clients and IT staff that there a no problems with process restarts?

  • Energy savings - has the system designed to make default reports online instead of paper? Has server virtualization been considered?

  • Unstructured data links - Can HTML links be made to useful web sites at strategic places on the application? (Business side) [Documentation and comments]

  • Does a new business process need to be created to improve or add new data? Does a committee of business and IT members need to be created to analyze and implement the new business process to improve or create additional data? (Data Architect, IT and business side) [Documentation and comments]

  • Transparency - Can the system bring more transparency to the organization? How can more transparency be built into the system and the organization regarding any related business processes? http://sunlightfoundation.com , http://www.transparency.org, http://www.data.gov/about

  • Mobile Apps - Are there new opportunities to use mobile apps with this data or program? [Documentation and comments]

  • ADA - Americans with Disabilities Act (ADA) [Documentation and comments]

  • If your organization has an enterprise architecture program, does the new business process, IT system, or data need to be incorporated into the EA process? (Data Architect) [Documentation and comments]

  • New Software Systems – does government retain control of the core mission data model and application? (CIO, Contracts Division, Legal, Data Architect) [Documentation and comments]


The above checklist ensures that a whole series of government improvement opportunities are checked for at the precise movement when it’s most important.

Clients don’t have to wait until they request data sharing. Comprehensive data sharing and all other opportunities checks are made at the outset.