To be honest and fair, these are not my thoughts but great principles I have learnt in my programming career. Its a unassorted list of references that I keep going back to, when discussing architectural concepts with development teams. Penning it here as my own reference.
Service Oriented Design
Services are the building blocks of architecture. They need to be simple, self contained and designed for re-use; right from the start. Application features expose their data and functionality through service interfaces. Services communicate with each other only through the interface over the network (Http / Messaging). No other communication allowed - binary dependency, direct data store access, shared memory model and all other backdoor access should be disallowed. All services should be designed to be externalizable.
Design Paradigms
API Driven - Abstraction is the key component of providing an integrated service offering. Applications needs to be built on top of a rich API which assists down the line with integration with downstream and upstream systems and implementations can be changed without impact.
Scalable - Applications should be decomposed into small, loosely coupled, stateless building blocks that can be scaled independently. Architecture should always bear cost in mind and allow business levers to scale both horizontally and vertically as necessary.
Adaptive - Dont make applications more complicated than they should ever be. Follow the KISS principle. Look for Apple product design guidelines as an inspiration to make things as intuitive as possible.
Resilient - Protecting your organization's / customer's data is the first priority for applications. Applications must be able to absorb individual failures and provide a seamless degradation of service based on availability. Don't treat failure as an exception but as an event of regular happening.
Secure - Integrating security into applications should be a ground-up activity and not an afterthought. Enterprise level of authentication, access-controls and data encryption should be applied from basic design.
Ref:
Embracing uncertainty
Clean architecture
Distributed Systems
Designing a good API
Design for failure - The Simian Army
Frequency reduces difficulty
Embracing uncertainty
Clean architecture
Distributed Systems
Designing a good API
Design for failure - The Simian Army
Frequency reduces difficulty
Continuous Delivery
Principles vs Practices - Best practices are subjective and depend largely on context, while principles are eternal and universal. The delivery lifecycle should be based on fundamental 'agile manifesto' rather than beating around on specific development practices. - http://simpleprogrammer.com/2013/02/17/principles-are-timeless-best-practices-are-fads/
Continuous business value vs Time-boxed iterations - The delivery should be based on providing continuous business value in the form of small functional releases rather than arbitrary time boxes. - http://kief.com/iterations-considered-harmful.html
Measurements and analytics - You really have to treat the software development process more like a relationship than like a factory. Instead of focussing on measurements and metrics, the emphasis should be given to trends and variance of the development lifecycle. - http://simpleprogrammer.com/2013/02/11/we-cant-measure-anything-in-software-development/
Philosophy on Estimations - The key is that you first accept that making accurate long-term estimates is fundamentally impossible. - http://blog.hut8labs.com/coding-fast-and-slow.html