Transportation Policy

1. Cost

Pay close attention to upfront and ongoing costs for each option, typically, custom solutions will have deceptively low ongoing costs with huge upfront costs that hide the inevitable, massive rebuild cost when the technology becomes obsolete (think of a new car that devalues as soon as it leaves the lot). This is because the low ongoing cost will only cover the basics to maintain the system, not keep it up-to-date with new product features and technology updates. Enter SaaS, typically lower upfront costs but higher ongoing costs for precisely the reason above – constant updates so large fees due to obsolescence never occur and the system continuously improves.

2. Speed

Custom solutions are exactly that, custom – meaning it takes additional time to gather requirements and build from scratch. SaaS solutions typically have out-of-the-box platforms that can be spun-up very quickly while allowing for configurations that would adapt the platform to the client’s specific needs. Within agencies today, as various point solutions are adopted for different functional needs – the idea of interoperable data becomes even more important. 

3. Flexibility

Custom solutions due to initial customization and pricing structure are generally set in stone after they are launched barring minor changes here and there, material modifications are both difficult and costly, SaaS solutions on the other hand, are highly adaptable and generally straightforward to modify by nature of the continuous product and technology updates.  

While it may seem obvious that we feel this way, think on these three points and check out our SaaS solution: ProjectTracker in the meantime if you like, no pressure! Stay tuned for part 2.

In today’s complex organizations, no single job or the system used to support a job can afford to be a lone island.  

That’s why any software must make sense within the broader technology ecosystem it needs to fit within for its end user.

Take transportation planning or capital programming for example – planners use cloud-based solutions like ProjectTracker to streamline their main workflow of planning and programming capital projects. 

At the same time, planners may also need to integrate programming data with financial system data for budgeting, push or pull FMIS obligation data from FHWA for federal funding updates, pull contract award and letting data from AASHTOWARE for visibility on project delivery status – among other examples of system integration needs for programming.

Here are some some insights we’ve learned from years of work with government agencies on what to consider when choosing a software that needs to integrate with other systems:

1. Identify software with a track record of existing functional connection to your preferred system as much as possible

Often teams with no prior experience on a particular system will underestimate the effort and time it takes to develop a robust integration for the very first time. 

This is an aspect of custom development that always ends up taking longer and more costly than expected. This is especially true when integrating with systems that do not have mature APIs. At one end of the spectrum, a system with well-documented API presents the easiest point of integration. As an example, If ESRI has a well documented API, it’s relatively straightforward for any reputable software company to establish a simple integration. 

However, many legacy or custom built systems do not have APIs – especially in the government space. FHWA’s FMIS is an example. The level of effort to unpack the FMIS data, transform and perform operations on it, build the data pipe in a first integration attempt can be magnitudes of degrees higher than anything else and possibly take years. 

As much as possible – find solutions that have a functional integration already with the system you need. 

2. Develop a robust, centralized data warehouse in the agency

Within agencies today, as various point solutions are adopted for different functional needs – the idea of interoperable data becomes even more important. 

It’s valuable to not only be able to import data from other systems – it also becomes critical to easily export data out of each system so data can be centralized and normalized. 

Enter the centralized data warehouse. 

We’ve seen agencies successfully invest the staff resources in developing and maintaining a comprehensive, centralized data warehouse. 

Such a warehouse pipes in data from all software at the agency, and allows designated technical staff to create complex and custom reports, visualizations and ad-hoc or ongoing queries to extract useful insights from all of the data captured across the whole organization. 

This gives agencies unprecedented transparency and visibility to all of the data generated across all its systems, and augments the reporting capabilities that exist across individual software platforms. 

Centralized data warehouse puts the control back in the hands of the agency of its entire data across the whole work lifecycle of its organization. 

In your procurement process, look for software with an API or direct database connection to easily export data out of the platform for integration with an internal data warehouse. 

3. Consider choosing the path of direct database connection for data warehouse integration

When exploring a software’s capability to work with an internal data warehouse, one option (if available) that can save agencies much time and effort is to choose a live, direct database connection. 

This connection capability allows the client agency to directly tap into another software’s database without having to do essentially any development work. 

This approach works especially well for agencies using advanced BI tools like Tableau or Power BI, and wish to add another data source from a software in a manner requiring zero work outside of credentials to establish the connection for the first time. 

Once established, the live direct database connection allows your BI tool to “see” instant changes to the dataset in the connected system – and utilize those updates right away in your reporting. 

These days, government departments are increasingly seeing the benefit of choosing the best-in-class point solution for specific needs, vs. using an all-encompassing heavy software that does everything but meeting various specific needs only half-way. The fact that many modern software has configuration capabilities to display different types and layouts of data from other systems makes the choice even more compelling. 

We hope the above suggestions can help any transportation programmer or planner wrestling with how to ensure a technology transformation will achieve successful integrations with other internal tools.