By Ashley Wilkinson, CitySourced – Facebook, Twitter, World Wide Web
There has never been a better time to be involved in gov tech; we’re in an unprecedented era of exciting new technologies being built and deployed by governments. But when any new movement is underway, there is bound to be significant misconceptions, which I’ll debunk today. Govtech brilliantly describes the abundant potential in gov tech:
“There are scores of new inventions each day — but the civic tech movement, in its immaturity, leaves untouched even more territory, more potential to realize its simple directive of making the nation’s cities, counties and states better places to live.”
#1. “I Can’t Possibly Need Another New App”
One of the biggest hurdles that occurs with adopting new technology, is the requirement to form a relationship with a new vendor. As is no surprise, procurement isn’t the easiest process in local government. But, your organization has to make a philosophical decision in regards to adopting technology.
If you believe in this best-of-breed philosophy, then you’re going to go out and find the best tool, procurement hurdles be damned, period.
On the other side of this coin, you believe that you can get everything you need from a select few number of vendors or just have your own employees build the technology in-house. This approach tends to favor large, established companies that will incrementally add on to their existing products, but they are unlikely to make significant pushes in innovation because it’s not their model.
Working with established vendors is the safe route. Governments are generally more risk-averse, but the tide is shifting.
Don’t get me wrong, there are definitely benefits to using your existing vendors, such as reducing procurement hurdles, eliminating the risk associated with working with a new vendor, and the warm fuzzies you feel when you’re familiarity bias kicks into gear.
But, not taking a best-of-breed approach leads to complacency. You’re artificially limiting your options by saying that, rather than picking the very best option, we’re going to pick the easiest option by picking the one where we have an established relationship.
#2. It’s Too Expensive to Adopt New Technology Platforms
While any new technology is going to have costs associated with it, there are really two distinct forms of costs to consider when deploying new technology.
One is the financial cost, and the second is the resource cost.
From a monetary perspective, there has never been a better time to be riding the technology wave, either as a vendor building new tools or as a local gov professional who’s involved in purchasing new tools. As opposed to 10-15 years ago, it is no longer a capital-intensive undertaking to deploy new tools.
Today, with vendors embracing SaaS business models, the upfront cost is greatly reduced and you can structure both contract length and payment terms that allow you to cancel, leaving you relatively unscathed if you’re unhappy with the results.
In addition, for non-subscription based services, new vendors are always going to be more willing to structure creative contracts (but you didn’t hear that from me ?), which can help you push the dollars you commit to the project to be based on delivery of very specific and tangible milestones. Again, more protection for you in the unlikely scenario where a vendor doesn’t deliver.
From a staff resource perspective, we’re biased as a vendor, but your IT and technical teams should not be building and maintaining tools in-house, but instead should become experts in the process of working with best-of-breed vendors which will result in a more robust technology suite for your organization.
From IT’s perspective, they have to look at the growing technology demands and realize that it’s not feasible or scalable for them to be the expert on all aspects of gov tech.
When your IT makes this realization, they will become experts in structuring deployments with new technology companies in a way that minimizes staff resources. This model will always win over a siloed, in-house approach to local government IT.
#3. Too Many Tech Systems That Don’t Talk to Each Other
The fear is that each time you add a new tool to your technology system, you’re going to have too many disparate systems. The result will be a complicated, difficult to maintain technology stack. Plus, the location of data in different systems will cause confusion over time.
Basically, your organization’s information will be spread out too broadly.
We wholly believe that all data should be accessible and in order to achieve this result we must rely on technology systems that are built to be web friendly. Generally speaking, if your application is hosted in the cloud, you’re all set, or if it is stored on an internal server but is provided with the right tools to open it up to other systems hosted onsite and online, you’re also good to go.
You want a system that is built with the mindset that it will be hosted in an environment that is easily accessible for other developers, your own internal staff, and any other vendors that you work with in the future.
At CitySourced, it is built into our DNA that we want you to push data into the other systems. Our API (a fancy way of saying how programs communicate), is something that we maintain and provide all customers for free. This policy is not universal.
We’ve seen other vendors that make their API an afterthought, or worse, turn it into an expensive upsell charge, which is typically meant to disincentivize you and your organization from moving data into any system that’s not theirs. IMHO, this is a huge red flag and should signal to you that this vendor is practicing an antiquated, walled garden approach that they believe if they keep you locked into their system, you’ll be happier and stay longer. This short-term mindset is not where web development, in general, is going and not where gov tech will go in the future.