Application Level Reuse and Google Maps

I found this, once again, on kottke.org. Someone has used Google Maps to map out the casualties of the Iraq War. Each click on the (+) on the left of the screen shows 30 more casualties.

I think the reason I find this so cool is not because of what this application is mapping out (which is cool — don’t get me wrong), but the fact that it was able to be written at all. Software written this way leverages the Wisdom of Crowds concept, allowing software to be written that the original authors had no idea would be an application of the technology they were creating at the time.

More than even that though, we are seeing a lot of what I call “application level reuse”. The distributed nature of Internet applications such as Google Maps allows the application to be used as a subset of a completely different application that serves a specific, specialized purpose. Applications can be written stringing together multiple applications like this, creating something brand new and extremely useful.

I think corporate IT shops, in most instances, aren’t getting the concept. They continue to write software in a very closed, monolithic fashion, that force their view of the world on their customers and do not allow that view to change — unless they agree and make the change themselves, increasing their development costs.

Amazon.com is another company that gets the concept. All patent issues aside, they were the first company that I remember that created a service oriented API to their application that allowed their customers to actually build their own store fronts if they wanted to. These APIs were used in ways Amazon wouldn’t even have thought of. The Amazon plugin for WordPress I use on the site is a really good example of this.

I think the world has already turned to this model of development and big corporations are missing it. Hell, even SAP, one of the most monolithic software applications in the world right now is getting it. The time has come where your customers want to use your software to make their own models of the world, that are specific to them. They want you to be transparent. They do not want your branding, they want the services you provide. Your branding has a place, but not everywhere.

I believe that customers are moving to the point where they just don’t want you to intrude on them. They want you to be invisible. Being able to integrate your software into theirs in a service-oriented fashion allows you to be invisible and to be integrated into the world they actually work in, rather than the world you think they live in (or worse, making them change worlds to work with you). The more you increase your transparency, the more you can be integrated. The more you are integrated, the more invisible you become. Pretty soon, you are used by default because you are part of your customers world , rather than a vendor that must be dealt with in an additional context shift.

Now, the problem with a paradigm shift like this is that it doesn’t come for free. Employees and business users have to be taught to think this way. Software has to be redesigned with this paradigm in mind. It’s not cheap — but I’m willing to bet its a lot more rewarding, from both a financial perspective, and a customer satisfaction perspective. Once the shift happens, you can stop worrying about “features and functionality” for the customer and start thinking about services the customers can use to make their own “features and functionality”. You can start focusing on the core services you provide.

The additional advantage is if you develop these services with customer use in mind, you can use them too. You can leverage the same services your customers use to constitute new functionality in your software. This also, can decrease your development costs.

This is how I see the world. But then again, who am I? I could be wrong. I doubt it, but I guess it’s possible.