Architecture Principles streamline development
Architecture Principles guide the development, design, and operation of software systems.
Architectural principles streamline the development process by setting clear guidelines and standards. However, they only do so if everyone, from top to bottom, is aligned on those principles. When everyone is aligned, all levels of the organization benefit. When everyone has different principles, it leads to conflicts, confusion, and frustration.
I use Architecture Principles to make positive cultural shifts, simplify development processes, and increase the quality of the software delivered. Continue reading to learn how I introduce, choose, and use them.
Awareness
Whether you're aware or not, your company, whether they are aware or not, is already using architectural principles.
What's that you say; your company has no architectural principles?
It might not be easy to see them. But they guide big system-wide decisions as well as small, every day, one-line-of-code-at-a-time decisions.
Each developer has their own set of architectural principles they work with. Each team implicitly has them based on the collection of developers and past implementations. Engineering leaders have them whether they're technical or not. The CTO and CEO have them.
The problem arises when everyone has architectural principles but does not know what everyone else's is. Software development suffers when everyone is not aligned on Architecture Principles.
Okay, everyone has architectural principles, so what?
For developers, architectural principles offer clear direction and a framework for decision-making. They foster a culture of autonomy, allowing teams to make decisions and develop solutions independently, free from constant oversight or approval from a central authority. This independence empowers teams to innovate, iterate, and quickly adapt to changing requirements.
For businesses, architectural principles clarify the business's technical goals. This reduces technical debt by promoting consistent, scalable, and maintainable software. That leads to robust, adaptable systems that make change easy. Which, in effect, increases market responsiveness and competitive edge. They foster a culture of quality, enhancing customer trust and satisfaction.
For customers, architectural principles may not be directly visible, but their impact is evident in the quality, reliability, and user experience. Good principles guide the creation of software systems that are secure, scalable, and have a user-centric design. Ultimately, the principles contribute to the timely delivery of features and solutions that meet customer needs and expectations.
Alignment of architectural principles is critical to achieving these positive effects. They define the boundaries and guidelines within which teams should work while still granting them the freedom to innovate and make independent decisions. By adhering to these principles, teams can align their designs with the organization's overall objectives.
When are the principles used?
I prefer design processes that do not require central approval. Architecture Principles are a key component that enables autonomy in software development. Whenever a member of the team has a decision to make or a design to create, they reference the Architecture Principles for guidance. When the team adheres to the principles, their decisions will align with business and architectural goals.
During the review of a design for fitness to a solution, the team verifies it adheres to the principles. Concerns can be raised by anyone on the team, including Engineers, Architects, QA, Product Managers, etc.
For the design processes I champion, if a design adheres to Architecture Principles and uses only technology from a Tech Menu/Radar, then the team is empowered to self-approve the designs. My goal is to minimize oversight and give teams the autonomy to make their own decisions.
However, sometimes there is a legitimate reason to ignore or go against an Architecture Principle. In that case, autonomy can't be maintained, and the decision must be approved by a higher authority. This is typically done by an Architecture Advisory Forum (AAF), Architecture Board, Engineering Leaders, etc.
What do Architecture Principles look like?
Architecture Principles typically address various aspects, ranging from system security, performance, and scalability to coding standards, data management, and user experience.
A few common principles are:
API First: Treat APIs as a user-facing and critical part of the product. Design APIs first -- before implementation -- to ensure they meet a user need, are interoperable, and ease integration.
Don't Reinvent: Avoid "Not Invented Here" Syndrome by preferring to use existing products, services, and libraries instead of developing them in-house. Buy -- not build.
User-Centric: Focus on end-user needs, preferences, and feedback in design and development. Endeavor to understand why a user needs a solution and how that solution serves the user's needs.
What makes a good principle?
Principles should be SMART (Specific, Measurable, Achievable, Realistic, and Testable).
First, let's consider a principle that is not SMART: Zero Bugs.
Specific: Unclear what defines a "bug" universally.
Measurable: Proving zero bugs across scenarios is nearly impossible.
Achievable: Reaching zero bugs is unrealistic due to complexity.
Relevant: Aiming for zero bugs may divert crucial resources.
Testable: Testing for the absence of all bugs is virtually impossible.
Let's see how the example principles are SMART.
API First
Specific: Design APIs before implementation for a user need and make them public.
Measurable: Quality of integration, interoperability, and documentation can be assessed.
Achievable: Can be implemented with proper planning and design.
Realistic: Within the capability of most development teams.
Testable: CI can enforce that API specifications are present and covered with automated tests.
Don't Reinvent
Specific: Use existing solutions over in-house development.
Measurable: Time and cost savings can be evaluated.
Achievable: Solutions can be found in commercial or open-source products and services.
Realistic: Aligns with the capabilities and resources of the team.
Testable: The value between buying and building can be clearly assessed.
User-Centric
Specific: Designing based on end-user needs and preferences.
Measurable: Customer satisfaction and user experience can be quantified.
Achievable: Can be implemented through research and user feedback.
Realistic: Possible with the right mindset and team focus.
Testable: User satisfaction and experience can be tested.
How do I choose Architecture Principles?
There are a few ground rules I set for choosing principles:
They must align with business goals.
They must be sourced from the teams.
All teams must accept and actively support them.
Principles should be tightly aligned with the organization's goals, vision, and mission. Good principles positively influence the behavior and culture of the team. They should inspire and guide without stifling innovation or being too rigid.
To help align principles to business goals, first, define the business goals. If you’ve already done that, then great, make them available to everyone. If the business goals aren’t clearly defined, that’s another topic, but start with acute problems the business is facing. Are you trying to grow the user base, increase customer satisfaction, improve reliability, improve quality, etc?
How many principles you need largely depends on your goals. I typically start with 6 principles to address acute issues. As your needs grow in complexity and variety, add principles to address them. Companies tend to end up with around a dozen. You’ll want to evaluate principles regularly, every six months or so, and remove ones that are no longer providing value.
How do I source principles from the team?
You’ll need to get alignment and buy-in across the organization, but you have to start somewhere. I like to start with a small group of representatives from every team to draft the initial 6 principles. Then run through a roll-out strategy with checkpoints to get alignment amongst all the teams.
A typical process that I use:
Assemble Architects, Principal Engineers, and engineering leaders for a brainstorming session.
Use DACI: Elect an Architect or leader to Drive this exercise. The engineering group will be Approvers by voting (see below). Everyone is by nature a Collaborator, and other people (such as Product) may be consulted. The entire engineering organization will be Informed.
Have each member pre-read this article (possibly with a silent meeting).
Lay out the business goals.
Review example principles.
Put the example principles in a spreadsheet as a starting point. Only put principles that you can reasonably align with business goals.
Have everyone raise additional principles for consideration. Whoever raises a principle should explain how it’s applicable, aligned with business goals, and SMART.
Each member only gets half the votes for the number of principles we want. So, in this case, everyone gets 3 votes.
Add a column to the spreadsheet for each member.
Each member will put a ranking, 1, 2, or 3, alongside up to 3 principles.
Tally the totals for each principle.
Take the top-voted half (in this case 3) of principles and automatically “ratify” them.
Discuss and debate the remaining top-voted principles to see what else belongs on the list of 6.
The Driver will refine the principles and record the results.
The Driver will create one Any Decision Record (ADR) per principle.
At this point, you might be satisfied approving the ADRs but hold off so you can get feedback from the rollout process. An Architecture Advisory Forum (AAF) could be used, but this group likely is the same group as the AAF.
The Driver will start the rollout process.
What is the rollout process?
“Geez, it’s like you have a process for everything,” you might say. Well, yes, everything has a process, whether we explicitly state it or not. I like to make processes explicit so everyone understands where we are and what to expect next.
If you have a small team and everyone was well-represented during the selection process above, you’re done! Approve the ADRs, and inform anyone who missed out. Don’t worry; principles are reversible by design, so don’t fret about being too hasty with the approve button.
However, if you have a large team, which you likely do because you weren’t already aligned on principles, then a roll-out strategy is needed to get alignment. Alignment is required. If your teams don’t believe in and agree with the principles you’ve chosen, they will not use them, and they will have false autonomy.
Here’s the rollout strategy I’ve used:
Start with getting alignment with Staff+ Engineers. The Principal Engineers will drive this, with the support of the architecture team.
Give the Staff+ Engineers this article as pre-reading material.
Call a meeting to discuss the principles you’re considering adopting. Make it clear you want feedback before moving forward.
Discuss each principle you’ve chosen and, most importantly, why you chose it and how it meets business needs.
Discuss some of the other principles you considered and why you didn’t ultimately choose them.
Ask for feedback. Are there any other principles you should have considered? Were the assumptions of why the principles were chosen wrong? Are any principles in actuality untenable?
If there is no alignment, refine the principles and repeat. This might involve going back to choosing different principles. If so, there are likely some larger communication problems between engineering leadership and individual contributors to address. If there is alignment, move forward.
Have the Staff+ Engineers repeat this exercise with the rest of their team. Their resident Principal Engineer or Architect can sit in for support. If any revisions are needed, the Principal Engineer should drive it.
This should result in all engineering teams having a chance to collaborate and provide enough feedback for the Architects, Principal Engineers, and engineering leadership to approve.
Approve the ADRs.
Inform the rest of the company about the decisions, especially close partners like Product, User Experiences, Customer Support, QA, etc.
What's next?
Learn more about autonomy in software development.
Check out these example principles as inspiration for your own.
Use your chosen Architecture Principles for guidance in your day-to-day work.
Evaluate your principles a couple of times a year, keep what's providing value, drop what's no longer useful, and add what's needed.
Related Reading
Art of Scalability discusses Architecture Principles in greater detail.