Government Integration System

Align Information and business architectures so that business people have the information they need to run the business. This means accurate, on time information, with the right level of detail.

Vision

Bring self-awareness to government. Self-awareness means having government data and business processes integrated so that government components understand what other components of government are doing in order to act as one.

Strategy

Create the unifying application for all government business processes so that sector-wide integration of new applications is built into government from the beginning and sector-wide business stakeholders are brought into strategy planning from the beginning. The unifying application will be managed by a new agency, the Center for Government Interoperability.

Why Use The Government Integration System Solution

The Government Integration System tool creates enterprise architecture that is business driven.

Business perspective: A government-wide, standardized menu for the application acts as an non-IT person's map of business and IT systems so that business government executives can visualize government as a whole clearly enough to be full strategic planning partners with IT executives.

Technical perspective: All business processes are related. Examples are procurement, personnel administration, ITIL, inventory management, portfolio management, change management, in short, everything. They should be integrated throughout the enterprise (statewide, or federal-wide) but different government departments use different vendor products that don't interoperate. Locking all government organizations into one private vendor's system to obtain interoperability is not an option. Government is best suited to integrate itself by building interoperability or telling vendors how to build components through enterprise design. This integration concept is similar to how Microsoft mandates outside vendors to integrate into Microsoft's systems which allows applications to share functions and to make sure that that each new application doesn't interfere with existing ones. Integration for Microsoft means interoperability so as not to have to reinvent screen drawing or disk access functions. Microsoft doesn't leave interoperability up to the outside vendors; it closely manages all integration issues using its operating system as the unifying focus. Government must do the same and view its business processes as an integrated, citizen oriented operating system.

Executive Summary

The Government Integration System is proposed to be the starting and ending menu for all government organizations. It acts as a perceptible unifying point that centralizes collective awareness of the inter-operational vision. It is the focal point for tying everything together. It works in the same way that Microsoft's desktop brings outside vendor products together into inter-operational compliance through a single unifying application.
It acts as a universal government menu, a digital, central meeting place that brings business people out of local, isolated business meetings and into statewide or nationwide collective process improvement meetings. It works in the following manner: (1) provides a uniform menu system that standardizes common government functions and terminology (2) visually conceptualizes enterprise architecture so business people become strategic planners in partnership with IT by giving business people a common experience, language and forum to connect with IT and each other statewide or federal wide.
It is intended that many applications be added to it by government and private industry developers. Different views of the data will appropriately appear for different sectors of government, e.g., military, police, education, etc., while beneath the surface, the data is configured to interoperate government wide. Private industry vendors can build components but government will retain control of designing interoperability.
A simplified example would be a project portfolio management application that would appear as a menu item on the Government Integration System. It would cost government less to build a single project portfolio management system that all state, city and county departments use, than to have all of the state's departments, cities and counties individually pay $200,000 for the system. A centralized system could "roll up" subtotals for all cities, counties and state departments into summary statewide totals that individual, silo project portfolio systems could not if each entity bought their own version. These summaries would be instantly available to the legislature, governor and state budget officials. Instead of having hundreds of enterprise architects individually configuring project portfolio software into local organizations, there would need to be far fewer configuring the single, centralized one. The local enterprise architects could concentrate on issues unique to their departments, counties or cities. City planners from all of the state's cities would use the same menu, business terms, and application functionality thereby allowing smarter design recommendations and mutual assistance through collective, statewide discussions in the Government Integration System forums. One centralized help desk could serve all city, county and state users.

Benefits Overview

Benefits of the Government Integration System are extensive in scope:

Comprehensive reduction of duplication, statewide or nationally. Why should each city in the country have a duplicate billing process? An application should be built once and shared government wide. Otherwise, government entities will redundantly end up purchasing copies of inventory, ITIL, portfolio management, UML, etc. applications.
Brings the business side into the IT improvement process. The menu acts as a communication bridge between IT and government business users. It gives the business side the ability to conceptualize its IT environment so that business can become a fully participating application development partner with IT. Without this, the only people that can see potential and operating SOA for example, are a few IT people. With the Government Integration System, not just a few IT people, but the whole government becomes involved in process improvement and IT strategic goal planning.
Brings IT enterprise integration efforts into focus for the IT side. It centralizes the process of bringing complete integration of all business applications within each government entity so that business and IT are aligned to government's mission. Government applications should not be allowed to run as independent silos that do not communicate with each other. Now for example, an attorney general's civil case database will talk to its criminal database. A state's licensing department's data becomes easily accessible to other outside state departments.
Economies of scale arise from centralization so that there is only one unit doing each the following for the whole state (or federal government): 24/7 help desk, hardware operations, security, billing, oversight, software support for legislative mandates, etc.

Government Integration Laboratory

A single testing area for the Government Integration System, a government integration laboratory, should be built to allow government and private industry developers to set up trial versions of their software to see how it inter-operates with all currently existing systems. The laboratory will be a mirror of the production version and allow clients to collectively test, compare and comment upon software from many vendors. Example: a city environmental sustainability component can be simultaneously tested by city planners in every city in the state. The city planners test the software in conjunction with all of their already-existing systems in the test area so that bugs and improvements are quickly identified. They can comment on how it inter-operates with the rest of their city business applications and send feedback to each other and the vendor within a secure online forum to guarantee that requirements are met. For vendors, this means a level playing field where their products can be evaluated by all clients in a particular government sector. A government integration laboratory means that all products can be thoroughly tested for seamless enterprise integration before merging with the production environment, thereby strengthening enterprise architecture with each purchase and build of a government application. Otherwise without a Government Integration Laboratory, each new software build or purchase risks incomplete enterprise integration.

Example: Let's assume that all city police departments have a single, shared, vendor-neutral application for all business processes. A new, private company brings a product to the market that can improve management of worker sick leave and vacation times so that human resources are automatically configured to handle police functions around the city during personnel absences. The vendor introduces the product to the Government Integration Laboratory by integrating it into the rest of the police management applications, where police managers from around the state test, comment and compare it with similar applications. Because of the large number of reviewers, the depth of the review is improved and the ability to collectively discuss it on a secure government forum makes application testing much more productive and generates many more suggestions than if a single city was reviewing the software. If the new application improves government's mission, then it can be added to the production version of the Government Integration System, which is composed of other modules that may have been written by different private or public developers. All cities' police departments benefit from the new software but only pay a fraction of the cost that they would have, had they bought it individually.

Project Origins

When private industry creates a business tool such as ITIL, all of the organization's components are identified and placed in a database. Once the data is there, it is easy to create additional applications such as portfolio management. Because all of the government components are already in the application database, all they have to do is connect them together to make other applications available. The natural result is that the application has done government's interoperability work for it and is integrated deeper and deeper into business areas where the whole government organization can be serviced by one vendor. Many vendors compete to be The One Big Integrator of government. The sticking points with this are (1) the different vendor products are not cross-departmentally inter-operational (2) there is no continuity if a vendor goes out of business (3) government cannot allow itself to become locked into a single vendor product (4) government is redundantly paying for the same product. The Government Integration System was designed to resolve these conflicts by transferring private industry vendors out of areas that are duplicative or discourage government interoperability, and into areas that are not duplicative and that more efficiently boost government savings and productivity. This is a subtle but important distinction that has not been fully understood yet.

Private Industry role

Private industry can play a role in the Government Integration System because it adds an important, extra set of eyes on improving government, but under this model, the integration aspect of the solution is emphasized and mandatory. The Government Integration System has vendors stop competing to sell redundant tools to government, but to instead compete with each other and government analysts to add something new to enterprise architecture and to align it more closely with government's mission. Government will own all of the system and not pay for licensing of components. Vendors can add components to the system but cannot own them. This allows vendors with good ideas to improve an already existing component that they didn't create. The Government Integration System shifts the focus to competition for interoperability and innovation, instead of silo creation. Instead of a race to lock government into a proprietary system, private industry will race to find new ways for government to improve and integrate its components. The Government Integration System removes previous inefficiencies arising from government and private industry relationships and puts them both to work in the same productive direction. It solves the old paradigm problem of vendors using the same model to sell to government, that they use to sell to private companies that do not have concerns about being locked into proprietary systems.

Enterprise Architects' role

The Government Integration System is implemented by Enterprise Architects to build better Enterprise Architecture faster. It assists them by compelling stakeholders to look at actual integration ramifications of every new business project and every business system change. The Government Integration System is the mechanism that compels developers to create interoperability, and compels stakeholders to verify interoperability.

Enabling Concept

The concept that makes it easy to create sharable software is that only one extra field per database record is needed to make it sharable. For example, if an inventory system has these fields: item description, location and serial number, then all that's needed to make the table sharable for every government organization in the whole state is to add an organization_ID field to it. This is a simplification, but it gives the general idea. It keeps all of the data logically separate so that each governmental entity only sees data that pertains to it, but since all of the data is physically in one table, legislators, analysts and budget officials can obtain unfettered business intelligence from the database.

Relationship to Enterprise Architecture

Why not just implement Enterprise Architecture (EA) without the Government Integration System, since EA will reduce redundancy and provide interoperability anyway?

The Government Integration System acts as a common interface that brings all stakeholders together into the same room. It is important for government business people, not just architects, to see, to visualize, the commonalities and integrated management tools through the shared menu to really become involved development partners. In this case the development “project” is to create integrated government. Once stakeholders are involved in collectively improving government applications using the shared menu as a communication platform, depth and scope of analysis is greatly improved and enterprise architecture is implemented easier, faster and better.

The Government Integration System menu gives stakeholders the vocabulary they need to discuss government improvement. The Government Integration System forum gives them a centralized venue to discuss it. County planners from around the state can discuss new features, help each other with current features and make recommendations based on a menu that they all are familiar with.

The centralized software and infrastructure (servers, operations personnel, etc.) makes it easier for stakeholders to have a standard budget mechanism to share costs. They don’t need redundant preliminary discussions on where to house the system and who will maintain it. Centralized infrastructure simplifies cost sharing so that it becomes more of a standard billing transaction instead of a case-by-case special budget structure authorized by the legislature each time two or more entities collaborate. Costs become easier to predict.

With the Government Integration Laboratory, full integration testing can be done with a realistic sense of how new applications will impact existing architecture.

Scope

The Government Integration System does not apply to applications like networking software or hardware that must be purchased because it's not efficient for government to build them. It is not intended that government write its own server operating systems. It applies to business applications because they all share data that can be easily connected but has not been because previously, there was no centralizing process. Business applications that are unique to a government entity should be added onto the Government Integration System if they have any table sharing potential at all. It could be added to the system even if it has no sharing potential at all in order to consolidate servers and hardware, so that economies of scale can be gained for security processes, hardware licensing and server updating.

Benefits

All clients receive solutions at lower cost due to economies of scale. For example, the smallest and poorest cities and counties receive the same top-class integrated management tools as the largest and richest ones. All they need is an Internet connection.
More minds, that is vendor and government analysts, are put to work on improving a specific government component. More solutions are offered per problem from more sources.
More stakeholders are involved in testing, that is the whole state or federal government sector is testing the same new system, thereby providing much greater requirements-fulfillment reliability and generating higher quality feedback.
New capability for vendors and government analysts to actually see how their proposed systems interoperate with current systems. This is automatic enterprise integration assurance.
Citizens receive better service from integrated government business processes. For example, when a citizen who is an insurance agent, changes their address, they can update their information in one place and have drivers license, voting, and insurance agent license address updated automatically.
Problems are centralized and not duplicated. Instead of isolated companies working on redundant isolated government entity problems, all companies work on a single version of the problem. For example, a court document management system problem being worked on in San Francisco, should not be redundantly worked on in Los Angeles by a separate company on a separate system. The problem only should be addressed once, in the Government Integration System that has the only centralized version.
The Government Integration System avoids an inherent problem that is the result of COTS (commercial off the shelf software), in that COTS prevents government from integrating itself. COTS are silo oriented and do not have enterprise integration. In the past, COTS were cheaper than build-your-own projects, but if the beneficiaries are multiplied statewide, then paying the vendor to integrate their solution with existing systems, or building your own, is cheaper. The Government Integration System makes private industry work towards integration because it redirects private industry from selling silo systems, to integration compliance when selling their solutions. The focus shifts from redundant solutions, to innovative solutions that haven't been conceived of before. Continual improvement in enterprise integration is automatically built into the application acquisition process. This strengthens the natural innovative forces of private industry, and channels private industry into a more productive model.
Small vendors have a level playing field within which to compete with large vendors because they can identify improvements relating to their specialty in a nonproprietary environment.
Weaknesses in one vendor's product that is installed in the Government Integration System can be resolved by a different entity than the vendor. The result is that the Government Integration System consists of the strongest features from all developers.
Because of the larger number of shared enterprise architects involved in each implementation, and the reality that the implementation must truly work with everything before it’s loaded into production, the Government Integration System constitutes a checkpoint to verify that a new system integrates into the current architecture. The Government Integration System acts as a barrier to silo projects.
Faster dissemination of solutions. For example, if a government developer created a better international currency conversion tool, how would it normally get noticed? Optimally, it would be become a discoverable SOA module and discovered by business analysts. With the Government Integration System, this would also happen, but it could also be available as a human readable menu item that individual government financial analysts would see on the Government Integration System business menu and interface with directly. This greatly speeds up discovery and expands the number of people finding this new functionality. It gives business people an understandable map of enterprise architecture.
Faster compliance with legislative mandates and other government-wide policy. For example, if the legislature mandated school districts to produce a new annual report, every school district would have the reporting software available to it from the centralized system, which would only have to be designed one time in one place. The school data would already be centralized in the Government Integration System and poised to create the reports with a minimal amount of effort.
Harmonization of data, business processes and, business terms used in human business processes. For example, if different units of the same department, or different departments use different phrases to describe the same business concept, this could cause confusion. The centralized menu could standardize the term. If identical meaning terms were "cost allocation" and "distributed cost", stakeholders could agree to standardize on one of the terms and remove the other from business documents such as contracts and agreements processed in the Government Integration System and all other areas.
Simplified billing for shared applications. Billing methodologies for shared expenses would only have to be worked out once and would be more easily standardized.
Business Intelligence. Data warehouse creation would be greatly simplified through centralization of business data that the Government Integration System provides.
Better oversight over data, expenses, privacy and project development. All of these areas benefit from centralizing business applications within the Government Integration System because data is in one place, connects to everything, and is efficiently configured for easy retrieval.
Consolidated help desk, data governance, security, operational recovery, SOA technical implementation assistance, all become available through centralization. For example, due to economies of scale, a single help desk could be available 24 hours a day to assist cities with Government Integration System budget tools.

Roadmap Overview and Financial Model

Stepwise implementation method would be used. Build a single, first function in the Government Integration System to inventory all government applications and desired applications. That will let government know what it has and wants. Architects from each organization would enter this data.
Candidate software applications would be identified in several different ways:
1. Find redundant: (a) planned or (b) desired applications and add up their cost to see if sharing a single, centralized version of them is justified. Prioritize projects according to highest ROI. If they are already planned, then budget planning is more reliable and it will be easier to channel the individualized planned funds to the centralized system.
2. Find all redundant existing applications and add up their cost to see if sharing a single sharable version of them will be justified. Prioritize projects according to highest ROI.
3. Whenever change is contemplated, analyze it to see if there is justification for building a centralized version that can be shared by the whole government.
4. Vendors demo their software applications in the Lab for clients.
Clients discuss the all of the applications above and if they can get enough purchasing partners (or if an individual entity can afford it) they purchase the new application. In this way, software applications compete with each other for implementation based upon many client votes.
Move the selected applications to the Government Integration System one at a time, working towards eventual complete enterprise integration.
The initial system would be small and could be housed anywhere and be distributed. Eventually, a centralized data center should house everything to gain efficiencies of scale and budget sharing standardization. The center name would be the Center for Government Interoperability.

Technical Summary of Starter System Initial Functions

A free "starter" system is being developed to act as the main menu of the Government Integration System. This "starter" system is not necessary to implement the Government Integration System. A private industry created module could just as well serve as the initial system, as long as it was built to be owned by the government without licensing requirements and any limits on add-ons.
Technically, the current starter system works like this: Everything is a component and can be cross-linked to anything else. This provides the ability to express complex dependencies between individual business tasks, people and data. Main Concept items (tables, business processes, projects, strategic goals, hardware systems, states, counties etc.) are designed as components (but can be validated through dedicated county tables, city tables, etc.).
Anything can become a component. Clients have the power to create components and to create hierarchies of components within components. This allows enough flexibility to handle cross-entity projects because clients create the collaborative project as a component. Each client can create infinite custom views of component groupings.

Overview (click image to see enlarged version)

Government Integration System contains all government business applications. It (1) removes redundancy (2) integrates all applications so that they are interoperable. It simplifies building enterprise architecture by centralizing the processes and artifacts of enterprise architecture. For example, all counties would share the same, single inventory system, which would interoperate seamlessly with the procurement system.
Universal Menu creates an understandable map of the Government Integration System's applications by creating a common language so that business people become IT planning partners with enterprise architects. For example, all city planners see the same terms and functionality as other city planners, and they see the functions in an enterprise context allowing them to work closer with architects because the Universal Menu produces enterprise-wide visualization.
Forums are coupled to the Universal Menu items so that for example, all district attorneys general in a state can collectively discuss improvements in automating evidence reports.
Developers can be from government or private industry. They add components to the system as directed by enterprise architects and test them in the Universal Laboratory so that enterprise-wide interoperability is assured.
Suggestions to create or update components can come from private industry, government IT managers or business users to bring a confluence of government improvement ideas.

Categories of computer applications that can be shared

Out of the categories of shared applications below, the Government Integration System can operate as a centralized system for the first four items.

Apps that only need an additional field to identify entity client, can be shared by two or more organizations. There will be only one, shared centralized app. which brings economies of scale in security, energy, human resources and other costs. Data would be integrated within the whole government and summaries would be rolled up for sharing organizations to state legislatures, governors or US federal legislature and President. An additional field means for example, if there is an inventory system with 2 columns (item serial number, and item name), all that is required to make the system sharable by many organizations is to add an extra field, organization_ID. Then all organizations could share the same inventory system. The system software would only display each organization's data to itself by means of the organization_ID. EXAMPLES=>Project portfolio management, web page automation, Intranet hosting, web page hosting, wiki hosting, blog hosting, parking lot management and many others shared by both federal and state government. LOCATION=> the ONE centralized government system. BUDGET/FINANCING: Paid for by clients that share the application.
Applications that are identical as the above, but for security reasons do not share the same server and data with other agencies; agencies instead host their own copy. The apps receive the same version updates as the single, centralized shared one, but the organization that has it would have to install updates themselves and use their own servers and security. To roll data up to higher budget, legislative or other authorities, they would have to extract the summaries themselves and send it to the authorities themselves. SOURCE=> the ONE centralized government site.
Directory of free sharable data, utilities or functions (mortgage calculators, etc.) on the government web site. E.g., surveyMonkey. LOCATION=> the ONE centralized government site for this.
Stand alone free or open source utilities developed by government or the general public that have no data sharing capabilities. An important distinction is that it does not have data sharing component. A centralized government web site could contain or link to all of the free downloads. EXAMPLES=> SFTP software, PERL utilities, javascript utilities, PDF processing tools, UML software. LOCATION=> the ONE centralized government site has links to these.
Calls to centralized functions - PLATFORM=> SOA, web apps EXAMPLES=> Mortgage calculator, currency conversion. SOURCE=> Many different government agencies. This area is already very well handled by existing Enterprise Architecture frameworks. Nothing new in this area is offered by this site or the author.
Data sharing. PLATFORM=> SOA, Web Services, SFTP, XML EXAMPLES=> field data from fed and state environmental studies, criminal justice data shared between corrections and CHP. SOURCE=> Many different government agencies. This area is already very well handled by exiting Enterprise Architecture framework. Nothing new in this area is offered by this site or the author.

Interoperability Policy

There is a need for policy at various levels, including legislation that mandates government and private developers create interoperability windows for business software. An example is a mandate that sharable apps be made more easily sharable by adding a single additional ID column (UUID) or UUID and category column (e.g., COUNTY). If government programmers develop the app, then it is instantly available to all government with relatively minor interface modifications. Private developers must go through a longer process involving payment for their software.