Enterprise-ready: things to consider

I have been talking about Enterprise-ready for over a year now on what is needed for a development organization to deliver enteprise ready product. So capturing some thoughts on what an Enterprise ready product should contain that need to be kept in mind during product development.

1. Basic product out of the box should simply work for what it is designed to do — Not just for happy path but also for not so happy paths and code detours that users might take.
2. Test more than what you code (Saying it again. I mean it. Test more than you code)
3. K.I.S.S. Use your brain. It is amazing how making things simple require some critical thinking.
4. Promote design patterns and architectural thinking before jumping on to code
5. Learn how to work well in a team; share; review; collaborate; learn, etc. Create team effect larger than the sum of all individuals.
6. Consider interfaces that people will rely on and pay lot of attention. Correcting any defect later will be hard to fix without introducing upheavel in the eco-system.
7. Document what you code
8. Consider global market impact — Language, Currency, TimeZone, Literal handling, etc.
9. Consider configurablity of the product to meet major use cases of the customer deployment. Say configuring a call center; dispatching calls; order of workflow; etc. Software configuration should be easy and simple to do that can be carried forward with each upgrade.
10. Consider how the product can be extended — it is better if extensibility is declarative. Best practices, APIs, guides, etc. should be made available addressing how to extend; test extension without affecting the base functionality; how to preserve extension as software gets upgraded, etc.
11. Consider how the product can be customized. Again, providing the necessary abstraction so that customization do not become invasive surgery on the base components and provide a path for future upgrades.
12. Consider product performance in Web environment. This should consider both for latency and bandwidth issues given companies are increasingly global and desire to achieve single global instance. Also, data centers are becoming huge and consolidation is the trend. Keep in mind several developing world may not have the best infrastructure available as well. Watch out for round trips and bad programming practices. Institure anti-patterns.
13. Consider product deployment choice — Hosted, Licenced, Multi-instance, Integrated environment, Global consolidated, etc.
14. Consider product scalability needs. It help if the product can be staless allowing better load balancing and clustering
15. Invest in user experience that can help end user get productive quickly. Make everyday tasks really easy to do and make it hard what you don’t want user to do, if can’t outrightly blocked it. As Krug and other usability experts would say — Don’t make me think. Idea should be represented intuitive and simple for user to get the task completed.
16. Consider making choices that most of end users will make. Sometime allowing every flexibility to be addressed by the end user makes a product hard to use and difficult to configure. Leaving less choices on the table is not a bad thing. Think iPod.
17. Centralize simple setup of similar product features — if acheiveing it is not possible for the entire product.
18. Invest in tools that can provide developer good information on vital statistics of code — complexity, path, memory checker, code scanners, etc.
19. Consider security and how application/technology fits in the larger enterprise eco system
20. Consider data quality issues and best practices needed to be deployed to keep data fresh. Keep in mind garbage in — garbage out. Think about purge and periodic reports on data.
21. Consider pre-seed data and setup data needed to get up and going quickly
22. Consider product development and implementation life cycle. How the change affects patch, update or upgrade.

Last but not the least… know developers are ultimately responsible for the quality of the products. Others in the value chain including QAs who touch the product either verifies or consumes what a developer develops. Hence…

• Learn quickly when a customer calls with a problem. It is not that customer don’t understand or use the product incorrectly. It is what the product allowed. You make more point with customer and marketplace by making the product work and share the learnings to avoid future pitfalls.