What can Evernote Teach Us About Enterprise App Architecture
Evernote had 100 million users as of March 2014. In June 2012 they cited 1.4 million premium subscribers.
Evernote Premium costs $45 per year. Businesses can purchase enterprise subscriptions with a different pricing plan, but $45 seems to be the lower number, so let's stick with that. It means that with 1.4 million paid subscribers they have revenues of at least $63 million per year. They've received almost a third of a billion in funding as of today.
So, how does a simple note-taking app become so successful ? I can think of the following reasons:
- Evernote is a single-purpose app that does one thing and does it well: taking notes. It does not offer a cloud drive, word processing, and picture sharing while it is at it. It only takes notes and helps organize them in notebooks.
- Evernote Premium does not require subscribing to any service other than Evernote itself.
- Evernote is cross platform. Evernote app runs on any conceivable platform, and neither platform has a superior version of the app than others.
- Evernote plays well with others and fosters open-source community. If a feature is not available, someone is bound to build an app to fill the gap.
What can we learn from this ? In particular, what those of us building enterprise apps can learn from the success of Evernote ?
Well, to start of, let's stop overthinking our apps. Let's say you are building an HR app. Instead of building one bloated app with long release cycles you could build a suite of a handful of self-contained apps: one could be a pay stub viewer and reporting app, another could be a health benefit app, yet another could be a 401k manager app.
Each of these apps are simple and self-contained, and if you build them as web apps you could get away with 1 or 2 developers per app, independently releasing them as needed to provide the best quality of service to their users. Each app can maximize its utilization, value and return on investment.
For self-contained apps to communicate with one another they need a shared server platform with shared API. This is why PWC recommends:
One big reason behind the successful adoption of RESTful APIs is developers’ ability to build modular capabilities with lightweight interfaces that don’t require heavy integration. “RESTful interfaces create a level of simplicity that didn’t exist previously, and simplicity always speeds things up, making integrations cost-effective,” says John Musser, founder of ProgrammableWeb.
If all of these self-contained apps that are part of a suite are to communicate with one another they need to at the very least know who the user is. http://oauth.net/documentation/ is the right approach here. OAuth2 is used by software companies like Google and Facebook to give users a way to authorize 3rd party apps to act on their behalf against their data. Likewise, from enterprise architecture perspective implementing OAuth2 should be one of the top things on your API roadmap – whether you use a solution by your ERP vendor or you implement your own.
Finally, document your API. The possibilities your business can gain by allowing 3rd parties to build apps are limitless. Your REST API should be accessible to public Internet (yes) and secured using OAuth2 authorization. Now your API can be accessed from mobile devices and apps by your employees, by your customers, and by your partners and your suppliers.