Archive

The Dulin Report

Browsable archive from the WordPress export.

2015

On Managing Stress, Multitasking and Other New Year's Resolutions Jan 1, 2015 Configuring Master-Slave Replication With PostgreSQL Jan 31, 2015 Trying to Replace Cassandra with DynamoDB ? Not so fast Feb 2, 2015 On apprenticeship Feb 13, 2015 Where AWS Elastic BeanStalk Could be Better Mar 3, 2015 Finding Unused Elastic Load Balancers Mar 24, 2015 Do not apply data science methods without understanding them Mar 25, 2015 Microsoft and Apple Have Everything to Lose if Chromebooks Succeed Mar 31, 2015 Two developers choose to take a class Apr 1, 2015 What can Evernote Teach Us About Enterprise App Architecture Apr 2, 2015 Exploration of the Software Engineering as a Profession Apr 8, 2015 Ordered Sets and Logs in Cassandra vs SQL Apr 8, 2015 Building a Supercomputer in AWS: Is it even worth it ? Apr 13, 2015 Apple is (or was) the Biggest User of Apache Cassandra Apr 23, 2015 My Brief Affair With Android Apr 25, 2015 Why I am not Getting an Apple Watch For Now: Or Ever Apr 26, 2015 The Clarkson School Class of 2015 Commencement May 5, 2015 The Clarkson School Class of 2015 Commencement speech May 5, 2015 We Need a Cloud Version of Cassandra May 7, 2015 Guaranteeing Delivery of Messages with AWS SQS May 9, 2015 Smart IT Departments Own Their Business API and Take Ownership of Data Governance May 13, 2015 Big Data is not all about Hadoop May 30, 2015 The longer the chain of responsibility the less likely there is anyone in the hierarchy who can actually accept it Jun 7, 2015 Your IT Department's Kodak Moment Jun 17, 2015 Attracting STEM Graduates to Traditional Enterprise IT Jul 4, 2015 Book Review: "Shop Class As Soulcraft" By Matthew B. Crawford Jul 5, 2015 The Three Myths About JavaScript Simplicity Jul 10, 2015 Social Media Detox Jul 11, 2015 Big Data Should Be Used To Make Ads More Relevant Jul 29, 2015 On Maintaining Personal Brand as a Software Engineer Aug 2, 2015 Ten Questions to Consider Before Choosing Cassandra Aug 8, 2015 What Every College Computer Science Freshman Should Know Aug 14, 2015 We Live in a Mobile Device Notification Hell Aug 22, 2015 Top Ten Differences Between ActiveMQ and Amazon SQS Sep 5, 2015 Setting Up Cross-Region Replication of AWS RDS for PostgreSQL Sep 12, 2015 I Stand With Ahmed Sep 19, 2015 Banking Technology is in Dire Need of Standartization and Openness Sep 28, 2015 IT departments must transform in the face of the cloud revolution Nov 9, 2015 Operations costs are the Achille's heel of NoSQL Nov 23, 2015 Our civilization has a single point of failure Dec 16, 2015

What can Evernote Teach Us About Enterprise App Architecture

April 2, 2015

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:




  1. 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.

  2. Evernote Premium does not require subscribing to any service other than Evernote itself.

  3. Evernote is cross platform. Evernote app runs on any conceivable platform, and neither platform has a superior version of the app than others.

  4. 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.