I love my iPhone.  I mean, seriously, I am obsessed. It started off slowly with just Email, Safari, Words, Kindle, Rotowire, Pandora, YouTube and Yahoo! Fantasy Football. Then it picked up some steam with Yelp, Sportacular, Facebook, SiriusXM, PocketGod and MapQuest. Then things really got crazy after adding Twitter, Foursquare, Google+, MobileRSS, Analytics and Pac-Man CE. Now it is to the point where I basically stare at my iPhone all day long.

It is pretty crazy to think about the amount of innovation and change that occurs on a device that fits in your pocket. The most amazing thing about the iPhone, however, is not as much the device itself, but the underlying design. The “app”-based design of the iPhone is the source of its power.  This design has been duplicated by many others that have created their own App Marketplaces. Every major software application, regardless of whether it is mobile or not, would benefit by following this trend. In other words, every large system should have an App Marketplace.

What Does a Marketplace Look Like?

For the purposes of this discussion, an App Marketplace does not just mean the Apple App Store. Rather, I am using it as a more general term to describe a place where users can find or build and share components that utilize a particular open platform.  Users should be able to quickly and easily build functionality (i.e. an app) on top of the base platform (i.e. your core system). An “app” can be a program running in the context of a particular device or system (i.e. a widget) or a separate, remote application. Examples of this abound.

• Facebook – Create widgets that can run on your website, Facebook or a mobile device
• Twitter – Allows users to search Twitter and get info about Twitter users
• LinkedIn – Interact with people, groups, companies, job postings, etc.
• Chrome – Modeled after the iPhone App Store with many of the same types of apps available
• Firefox – Firefox Add-ons have been around for longer than the iPhone
• Hubspot – Will soon be the largest online app store for marketing after they complete their integration with recently acquired social media company oneforty. Hubspot also has built a number of apps on top of other platforms such as WhoRetweetedMe.com which utilizes the Twitter API.

There are three primary characteristics of a system that has its own App Marketplace.

1. Good API Design - Not all App Marketplaces have good APIs (some people point to Facebook as an example of a bad API), but the point here is that any API flaws will be painfully obvious as the number of users grow over time. You will be forced to either improve your API or get buried under a wave of complaints and constant issues. Joshua Bloch, an Engineer from Google, does a good job of summarizing some of the characteristics of a good API in his classic 2005 presentation How to Design a Good API and Why it Matters:
• Easy to learn
• Easy to use
• Hard to misuse
• Easy to extend
2. Strong Infrastructure - Essentially, marketplace services should just work. Period. The moment you have to worry about a slow service or servers being unavailable or sensitive data being compromised is the moment you start losing customers. Functionality pulls in customers, but poor infrastructure turns them away. Strong infrastructure usually covers these three areas:
• Performance – There is no magic number (i.e. every service must respond within .x seconds), but the thing to keep in mind that generally the acceptable performance of a web application is between 1 – 3 seconds. Web applications may need to call 3 – 5 external API services during those 1 – 3 seconds which means that each service should likely be less than .5 seconds (sometimes a lot less).
• High Availability – Mostly this means load balancing and an automated DR strategy, but this also includes stopping hacker attacks that are designed to take down your website. Fore example, while most hosting companies provide protection against DoS attacks, many people are not aware of the more deadly DDoS attacks (even Amazon and SalesForce.com have recently fell victim).
• Security – There are a number of ways to secure your services (i.e. OAuth, SSL, SAML, etc.). Just make sure you implement something that is strong, flexible and easy for clients to implement.
3. Rapid Delivery – As the use of your open API increases, two could things happen. If the API is anything less than perfect, the pain felt from those inefficiencies (i.e. customer complaints, difficulty making changes, etc.) are magnified. If the API is popular and breads innovation customers will demand upgrades and new features. In either case, you need to be able to make changes quickly and efficiently.  Open API customers won’t wait for 6 – 12 months to get minor fixes and updates. There are many things go into rapid software development (perhaps a future article topic on its own), but a few that I think are important include:
• Continuous Integration – Martin Fowler has a great article on Continuous Integration where he explains that the primary issue with delaying integration testing is that you are leaving a large unknown to the end of development. A bug becomes more and more “expensive”  the longer it takes to find and correct the issue. So, by forcing developers to integrate their code and test early and often, you end up saving time and improve overall quality in the long run.
• Automated Deployments – Many legacy applications have a semi-manual, complicated, error-prone deployment process. A true “marketplace” has a fast, robust, automated way of deploying changes.
• Automated Testing – The only way changes to shared services can get to production quickly without bugs on a consistent basis is if there is a mechanism to do automated regression testing. If this is not in place, you would either need to deploy changes without the proper level of testing (and thus likely experience issues) or take a much longer amount of time to do a full manual regression test.

The Value of an App Marketplace

As developers may have noticed, these three characteristics of an App Marketplace are in fact best practices for all well designed systems in general. The statement that all systems should have their own App Marketplace really means that all systems should follow software development best practices. That is sort of an obvious statement, but the concept of an App Marketplace more importantly can play a crucial role in the implementation of those best practices within a system. Typically, there are a number of different reasons why software development practices are not followed:

• Inexperience – The best practice may not be known or understood by the developer.
• Time-to-Market – The Technical Debt situation where a less-than-perfect design is accepted in order to get changes into production faster.
• Grey Area – There are many situations where the perfect design it is not 100% clear. Only after getting the changes in production and seeing the results is the optimal design revealed.
• Brain Farts – Code Complete is a big book. It is very difficult for developers to have every single best practice in their minds at all times.

There is clearly a big difference between reading about best practices and actually implementing best practices. The concept of an App Marketplace for your system helps to ensure the implementation of best practices because Good API Design, Strong Infrastructure and Rapid Delivery are not just nice-to-haves when you are dealing with a marketplace. They are essential components of exposing your services to unknown external clients. Instead of thinking about 100 different individual best practices, you just focus on the fact that your service will be used by many different people in many different ways. It is then easy to remember and follow these best practices because you know the moment your API is flawed, there are infrastructure problems or you can’t deliver changes quickly, you will hear about it from your clients.

Conclusion

So, really what we are talking about is playing off a popular concept (i.e. everyone has an understanding of the iPhone and Apple App Store) to help promote and enforce good development practices. And, since the use of an App Marketplace helps us to enforce best practices within our systems, why not apply the concept to all major systems? For enterprise applications that are not externally facing, you can create an internal marketplace and just “pretend” that your customers are unknown. This may seem a little weird, but by doing that you can enforce all the best practices mentioned here and reap the rewards of having a highly dynamic, open marketplace.

Although it may be easier to do something like this with .NET or Java-based systems, even legacy systems can have their own marketplace. In fact, the idea of a marketplace with legacy systems can help to drive the modernization efforts. That will be the topic of my article next week, 4 Steps to Help You Get Rid of Your Legacy System.

• Part 1 (What is bad) – The Root of All Evil (in software)
• Part 2 (What is good) – Why Every System Should Have an App Marketplace
• Part 3 (From bad to good) – 4 Steps to Help You Get Rid of Your Legacy System