Learning the hard way why systems scalability counts

By Mike Steyn, Director at Aspire Solutions.

One of the most useful exercises any business manager can undertake is a regular “put yourself in your customer’s shoes” session. The perspective gets lost very easily in the daily rush of operations – but we all know the insights it yields are priceless.

Map-making may be a very ancient art, but nowadays most of us deliver our maps and map-based information mainly via screens, and increasingly often via web-like interfaces. These systems can get extremely complex, which makes it all the more important to remember the customer’s point of view.

As customers, we don’t care how big or complex the systems behind the final screen are: We just want them to deliver what we want, as quickly and efficiently as possible. So whether we’re planning a complex delivery route or viewing a simple map to the local pizza restaurant, we expect the same level of service.

As Aspire Solutions we’ve learned the hard way that no matter how lean our maps are and how small the user base at the beginning of a project, it pays to design systems that can deliver the speeds people are used to — whether we’re getting 400 viewers a month or 400 viewers a second.

When we built our first mapping solutions, we used a traditional, monolithic architecture that built services directly on top of the underlying database. We learned very quickly that, with a small amount of extra effort, we can instead use a services-oriented architecture that allows us to add, remove, change and upgrade services at will without affecting the underlying data.

This is the way the world is moving: Data owners publish application programming interfaces (APIs) that developers can use to build whatever services they can imagine — without compromising the security or integrity of the underlying database.

Developers love this kind of architecture because it’s lean, efficient and scalable. As business managers, we love it because it makes developing new products and services much, much quicker and easier.

One consequence of the rise of service-oriented architecture has been an explosion of innovation. APIs lower the risks to data owners of making their data available – and also the risks to developers of trying something new. In the mapping environment, the number of data providers is growing all the time, from global players like TomTom and Navteq to providers of traffic and weather data. All of this enables a flourishing of new services.

Collaboration is also easier and less risky. In one of our current projects for an EU-based client, we’re pulling together information from many different databases, with many different owners, into a single application to deliver real-time traffic information to millions of users. This is a project that simply wouldn’t be possible without service-oriented architecture.

So anytime you build or commission a new application, it makes sense to insist on a services-oriented approach. Monolithic architectures no longer make sense. Even if you think your user base is going to stay small, don’t cut yourself off from the opportunity to add new data feeds and functionality in future.