Welcome to OpenGov Developers

Jawahar Malhotra
OpenGov Developers
Published in
4 min readMay 25, 2016

--

OpenGov operates in a market full of challenges. Our mission is to transform the way the world analyzes, shares, compares, and allocates public money. Given the state of technology within government organizations, this transformation in itself is a formidable challenge.

Our purpose is to derive intelligence from the data we collect from governments. This is data that contains information about the operations — financial and non-financial — of governments. We get to the heart of budgets and general ledgers that live inside accounting systems. We also collect, cleanse and use data about outcomes that result from spending. OpenGov maintains a curated collection of data from a variety of sources such as the United States Census Bureau, the National Center for Education Statistics, the FBI, among others.

Our unique angle of approach is to view this data with a financial lens. We have the unique capability to derive intelligence from Budget and Spending data, making these data actionable. We have developed the ability to slice and dice this data using a government’s own Chart of Accounts (CoA). This artifact is like an organization chart for all the revenue and spending accounts a government has. It is essential to guide the interpretation and categorization of the data, which in turn enables us to link spending with outcomes.

Our ability to make sense of CoAs breathes fresh life into data that typically lies dormant inside multi-hundred-page budget books posted on websites of most local, county, and state governments. Furthermore, our deep knowledge-base of these CoAs enables powerful cross-government use cases, such as comparing the spending — and other benchmarks — of one government with other similar governments.

The technology to accomplish these goals is full of interesting challenges. It starts with the extraction and transformation of data from a variety of accounting and ERP systems. It is essential to be able to disambiguate this data — especially the Chart of Accounts and references to it in the revenue and spending data. Because CoA are complex and potentially large tree structures of varying breadth and depth, presenting them in an interface that allows complex transformations, while ensuring the integrity of the CoA, is hard. It poses significant usability and scalability challenges.

Aggregating the revenue or spending data using the CoA as a guide presents many scalability and performance challenges. Apples-to-apples comparisons of one government’s data to another requires normalization of their CoAs, an interesting ontology problem that we will elaborate on in future posts in this space.

We have adopted React as our primary technology for the front-end. We’ve consolidated around a unified front-end architecture based on React. Given that this is not how we started developing our front-end apps, we have a “legacy” of inter-operating apps that needed to be migrated into this new unified front-end architecture. Migrating these apps has taught us a great deal about how to use React to accomplish this goal.

PostgreSQL is the primary engine powering our data analytics capabilities. Slicing and dicing financial data, providing rollups at any node of the CoA tree are all accomplished with Postgres queries. We have learnt how to maximize performance for these types of queries on Postgres. Datasets with geospatial information are very common in governments. Common use cases require storing and querying this data. The PostGIS extension to PostgreSQL powers most of our geospatial use cases.

Apache Spark enables us to crunch through large volumes of data. We use Spark at OpenGov to perform distributed computing queries and transformations of our data. The technology enables us to design larger data operations with ability to scale the process significantly without making code or architectural changes. The nature of how the framework operates means adding more resources will solve larger problems without being limited by the size of a single machine. Future posts will cover our usage of Spark.

Open source is important to our success, and we believe in contributing back to the open source community. We recently developed a ClusterLayer component as an extension of the React Leaflet library. We’ve made it available to the open source community under the MIT license.

Over the course of the coming months and years, we will share our practices — technology and other. We will use this forum to create awareness of available data, APIs, insights, and use cases, to highlight the impact our technology is having on the transformation of governments, and to share news about developments to OpenGov as it relates to the tech, developer, and open source community. Thanks for being a part of this community.

--

--