Picture of hand reviewing a blueprint from Pexles.com

You wouldn’t (hopefully) think of building a house without first sitting down with an architect to come up with a good plan.

While building a house is a waterfall process, that doesn't mean we can throw out good architecture when moving to an Agile methodology in software development. Sound architectural principles allow team autonomy to select and ensure that any new significant design meets standards for high availability and scalability of your website, product, or service.

Good architectural principles ensure stability, compatibility, and reliability. Many post mortems after a major incident with which I’ve been involved have uncovered root causes resulting from teams not following agreed-upon architectural principles – and unfortunately more often than not – seeing that teams do not have written and followed architecture standards.

Architectural Principles Are Guidelines for Success

Often in Agile software development, we confuse the desire to innovate and do things in new and differentiating ways with a similar antagonist notion that we shouldn’t be shackled with rules and procedures. Many upstarts and smaller companies offer freedom from layers of policy and red tape that stifle out speed, time to delivery, and innovation – and adding in architectural standards and review boards can sound very bureaucratic.

Architectural Principles are not meant to be restrictive. When written and executed properly, they are meant to aid growth and ensure future success. Structured architecture should keep things simple, expandable, and resilient and help teams establish autonomy rather than anarchy.

Successful companies are able to balance consistency with speed, which ensures future efforts aren’t encumbered by bugs, having to refactor excessive amounts of code, or be haunted by the sins of past shortcuts. The key is to keep things simple and dependable!

… match the effort and approach to the complexity of the problem. Not every solution has the same complexity—take the simplest approach to achieve the desired outcome.

(Abbott, Martin L. Scalability Rules. Pearson Education. Kindle Edition.)

AKF Architectural Principles

On the many technical due diligence and extended workshops I’ve attended in my tenure with AKF, I’ve seen how successful companies comply – and struggling companies avoid – the following principles:


AKF Architectural Principles Slide: Use Mature Technology, Use Commodity Hardware, Scale Out - Not Up, Isolate Faults, Design for all three Axes of the AKF Scale Cube, Design for Multiple Live and Independent Sites, N+2 Design, and Design to be Disabled


AKF Architectural Principles Slide 2: Microservices for Breadth, Libraries for Depth - decompose monoliths, Buy when non-core, Build small, release small, fail fast - crawl walk run, automate everything, use stateless systems, always design asynchronous communications, design to be monitored, and design for rollback and to be disabled

Everything we develop should be based on a set of architectural principles and standards that define and guide what we do. Successful software engineering teams employ architectural review boards to meet with teams and review existing and planned systems to ensure principles are being followed. Extremely successful companies have a culture that constantly looks at ways to better implement their agreed-upon architectural principles so that review boards are only a second set of eyes instead of a policing force.

With 12 years of product architecture and strategy experience, AKF Partners is uniquely positioned to be your technology partner. Let us know how we can help your organization.

This is the first of a series of articles that will go into greater depth of each of the above principles:

Image Credit - Pexels.com