Selling better web app architecture to your stakeholders

The commercial side of things doesn’t always come naturally for many programmers and architects, a large portion of us lack interest in the business side and would prefer to hone our technical skills. However I believe a commercial understand is necessary for developers to be really good at what they do and thats why the aim of my blog is to cover both the commercial and technical side of key areas in development. In this vain I wanted to write about the commercial side of my previous post on The Power of Distributed Architecture in Web Apps. While the technical benefits of our DLAPI architecture may be painfully obvious to us ‘geeks’, you may find you have trouble justifying any additional cost and time scales involved in taking this approach. Hopefully, in most cases the key to getting your boss on-board with you will be a simple case of assuring them that you know what you’re doing and  ‘if it wasn’t better, why would we come up with this stuff?’ will clear up any misunderstandings. However if your boss is not so trusting, and wants to know what the extra 15 grand is for, you might need to do a little better than that. You could start by explaining that the initial outlay will more than pay for itself in the long haul, because if you do it right, this will be very true. When arguing this point you might wish to check out the equations for calculating ‘Payback Period’ which describes the length of time it takes for the investment to pay for itself. You could use this equation to show that while your initial out-lay will be a little higher, your payback period may actually be shorter due to reduced maintained overhead, increased performance (better SERPs, less time lost waiting), and large chunks of money saved on future development, especially new clients. If that’s not enough, and they need more convincing, you may need to put together for the full-on business case for your proposed decision. Put projections together to compare building with a distributed architecture vs an integrated one. Compare time and cost to build, maintenance hours, cost over 1, 3, and 5 years, ROI over 1,3 and 5 years, difference in hours for later extension projects, hardware costs, availability, training time (new team members / contractors), potential additional revenue sources (external API access etc..) and any other variables you can think of between the two approaches which may hit a business nerve. If you can show your boss and/or client you have thought about these things for them, and come up with some sensible numbers, your argument won’t get ignored. Telling stackholders that you want to build a distributed api system because ‘it’s new and cool and I wanna try node js” will lead to FAIL, show your boss a graph, you’ll be right ‘in there’. WinZip Full Version - 56Kilobit Whist searching for a cheesy sales graph image for my post I found this and decided it was too funny not to use instead. Here’s a characteristics / benefits list for distributed architecture to arm yourself with:
  1. Increase upfront development schedule and cost but higher ROI long term
  2. Reduced time and cost to roll out later clients
  3. Increased performance – CDN, Fast API, AJAX client, Web sockets. Good for SERPs, UX, and stress
  4. Increase maintainability – Everything is not interconnected in one mass of code – so much easier to maintain
  5. Increased flexibility – You could easily swap in a new interface without even touching the business logic or vice versa
  6. Increased expandability – You could add additional functions to your API or create a new /v2/ api in parallel with running /v1/
  7. Much easier upgradability – As above, run versioned APIs. You are also able to upgrade components individually, API, Client, Database etc..
  8. Ability to more easily consume third party services.
  9. Ability to more easily push content to third party services (great for marketing networks)
  10. Ability to sell third party access to your API
If you present all the above information to your boss / client (including a graph) and they still don’t get it, then at least your have done your best to up-hold your developer integrity by educating them and providing the commercial facts. In the process you also get yourself  a  ‘I told you so’ bargaining chip for when the integrated system they ordered-up costs more to maintain than it did to build and they have to hire 2 new engineers to look after it whilst continuously upgrade infrastructure to meet performance demands (drama). The information above is not just speculative. I wish I failed to land a pitch a few months ago which I’m sure I could have won had I taken the above approach and  I’ve since succeeded in bringing people way around to my way of thinking using this advice. I hope the ideas are of some use to you.