Given that innovation is something new, introduced as an improvement to existing technology, and given that quality flows from those improvements, I invite you to ponder this (a question that might multiply your contribution): What would it take to make your innovation so that it is easy to innovate upon?
We know that every idea and project doesn’t get implemented, but if you are lucky, your concept may spark an even better idea in someone else. With that thought in mind, I was recently building a mobile-friendly website that runs on some geocode data, and my team and I chose to make specific architectural tradeoffs to facilitate more innovation.
Our idea
The project was an innovation on how we currently locate nearby customers while traveling or while situated within a certain geographic area, and compiling latitude and longitude on addresses was a requirement for this idea. We gathered the addresses, geocoded them, and stored the results in our database. We then wrote a user interface (UI) in Ruby to display the results of a search using HTML5 geolocation calls.
The first iteration simply called the database from the UI to fetch the list of customers and display them on a page. It worked well, but was obviously tightly coupled. This was fine for a quick innovation idea and initial demo, but as we were building the application, my mind was thinking about 10 other apps I could build from this data and 10 other uses of extending the geocoding information.
Knowing that I didn’t have time to build all the ideas myself and that I didn’t fully conceptualize every one, I decided to split this idea into two. I moved the database to a new project, wrapped it with some web services, and exposed it to the original app. I also rewrote the original app to call the service instead of the database directly. The net result was an easier way for others to iterate on the idea without significantly changing my app.
Tradeoffs
The tradeoff or sacrifice includes performance and maintenance. All of my data is retrieved through a web service, marshaled and un-marshaled, and parsed before it’s ready for use. However, this iteration was never designed to be scalable, production-ready code, so the performance tradeoff was not a concern. Maintenance was a slightly bigger issue. I could have made two repositories (and still might if they need to scale differently), but for now, I wrapped both pieces in the same project, same deployable, and used localhost to call my service endpoints. Other projects can call the machine by name, but no reason for me to do so.
With some small and calculated tradeoffs, a part of any project can become the basis for many other ideas and projects. In the case, even if the company doesn’t roll out our idea, I’m confident someone else will create an even better project that will.
How have you designed your project so that it was easily innovated upon? What tradeoffs did you make? Did anyone else build a better project on top of yours? Please continue the discussion below!
Leave a Comment