From Accidental to Intentional: Your Roadmap to Architectural Excellence
By Garey Hoffman and Mike Pleimann
The first article of this two-part series discussed how to identify Accidental Architecture and the challenges it can cause an organization. We defined Intentional Architecture as a deliberate system architecture that is created from a set of goals, trade-offs, team structure, and constraints under which it’s built and maintained.
If you’re stuck in the muck of Accidental Architecture, taking action is certainly the right course. That said, the wrong series of actions can have consequences that are just as dire as no action. Our roadmap to Intentional Architecture is paved with insights gleaned from countless organizations that have navigated through the challenges of Accidental Architecture.
Preparing for the Journey
The mechanisms to move a system from Accidental to Intentional Architecture are simple to describe, but they may be difficult to implement. It requires commitment from business and technical leaders and a proper understanding of its importance. In short, Intentional Architecture requires alignment between technology and business goals.
There is a journey ahead for any organization that is committed to achieving an Intentional Architecture. And, ensuring your organization is ready for the journey is critical. Without real support, the odds of completing the journey — or even making meaningful progress — are very low.
This is the stopping point of this journey if your organization is not able to do the work of aligning business and technology goals. We invite you to resume this journey when your organization is ready to create the conditions where that alignment can happen.
The Roadmap to Intentional Architecture
After working with many clients, we have found the following guide on advancing Intentional Architecture is successful within organizations that are ready for this journey. Here’s a roadmap to get you started:
Mission Possible: Defining Your IT Purpose
One place to start is by identifying the primary purpose of IT in the organization. We’ve experienced all sorts of responses when we propose this as a starting point. From quizzical looks to downright shock is common. Yet, when organizations really take a look at their own internal beliefs, there is a wide discrepancy in the view of purpose.
For example, a mission statement for an IT organization could read something like this:
Empower teams to build reliable, efficient, and user-friendly software that delivers competitive features with reduced cost, risk, and time to delivery.
A clear and inspiring mission statement is crucial to prepare your organization for the technological journey ahead. Your organization should have a statement that is more specific to your organization than our example. It should act as a mandate, empowering your tech team and guiding their work. Think of visionary leadership — a bold leader who can clearly articulate the future. Or in some organizations, this can be found in a grassroots campaign where leadership is gained through a track record of success. An inspiring leader, whether internal or external, can ignite a movement within your organization to embrace intentional architecture.It may even be an outside evangelist who inspires and directs an internal groundswell.
Agreeing on the Path
Hopefully, this doesn’t occur with a traumatic incident like a major system crash or security breach. (Sadly, these are real events that take place.) The goal is to establish alignment between business decision-makers and technical leadership on the purpose of your application or system that suffers from Accidental Architecture. An assessment of responsibilities or a joint workshop may be necessary to uncover all relevant information and create a coalition.
A common discussion with our clients includes a session to understand the pain points that they experience. Importantly, we work to learn who experiences the pain. We find it common for decision makers to disproportionately feel a lesser amount of pain under its current architectural state. Understanding why decision-makers feel less pain (and may not be aware of the depth of pain felt by other stakeholders) is a critical part of these discussions.
Your technical team likely faces challenges meeting deadlines and budgets beyond their control, often accumulating technical debt. Technical debt is often the result of working around architectural deficiencies to meet these deadlines and remain within budget.
The accumulation of substantial technical debt is the single largest symptom of Accidental Architecture. However, we cannot stress enough the importance of understanding the types of technical debt your organization may hold.
Driving a Culture of Improvement
To build a culture of improvement, start by providing the space and resources your team needs to tackle these challenges head-on. Continue by facilitating open dialogue between teams; seek outside consultation when needed. This is an investment in your organization’s future success. If this is counter to your corporate culture, we recommend collaborating with change management specialists.
Examples of tackling this task with our clients include:
- Conveying the full risk profile they bear under large technical debt loads.
- Illustrating how to classify technical debt as benign, moderate, risky, or dangerous.
- Creating efficient and effective workflows and processes that stop (or slow down) the accumulation of more technical debt.
- Collaborating on how to create realistic roadmaps for emergence from Accidental Architecture, building hope and trust.
- Helping them create the business case that ties improvements in technical debt to new initiatives or new feature development.
Prioritizing Your “Ilities”: What Matters Most?
While all aspects of quality in an Intentional Architecture are important, after some thought you’ll certainly find that some aspects are more important than others. Choose 3 to 5 “ilities” — essential quality attributes — that are most important to your business and systems.
Here are some of the most popular attributes to consider:
- Reliability
- Scalability
- Efficiency
- Security
- Familiarity
- Safety
- Maintainability
- Adaptability
- Portability
- Resilience
- Responsiveness
Many of these overlap in concept. Often depth in one must be traded for another. Ranking your choices according to their relative importance to your business is crucial. While highly subjective, the ranking will communicate your priorities so that stakeholders can make reasonable trade-offs.
Establishing a Baseline (and Stop Making It Worse)
Gather the stakeholders for each component or subsystem that knows where the skeletons are hiding. Document a baseline score indicating how close the component is to achieving each of the attributes that were selected from the “ilities” attributes. This again is subjective, but that’s OK. Be honest and base the evaluation on the experience of all stakeholders–including the technical teams.
Mapping Out a Plan: Defining Intentional Architecture with Quality Targets
Collaborate with technical leaders and engineers to define specific goals, known as fitness functions, for each component or sub-system. Fitness is the objective ability of a system or component to meet one more of the quality objectives. Is X fit for purpose? What is “acceptable” as an objective target will depend on the particular requirements of your system, your tolerance for variation, and any immovable obstacles such as compliance requirements.
Here’s an example list of (simplified) technical target statements with their corresponding business targets:
Note: Meeting these targets is not free. The more stringent the target, the more it will cost to meet, and the more trade-offs will need to be made to satisfy it. Ensure that your targets are reasonable and in line with the requirements of your business and risk tolerance. This is the primary motivation for choosing no more than five qualities that are most important to your business.
Incrementally Improving While Continuously Validating Against Targets
Intentional Architecture is not a one-time activity — it becomes woven into the fabric of an organization. It is the adoption of a different mindset and a different way of thinking. Both business and technical teams should be connecting throughout the software development lifecycle and discussing design choices that positively and negatively impact quality targets.
You may be asking “are we there yet” at this point, and the answer is yes and no. This journey of crafting intentional software and systems architecture is a continuous loop of evaluation, adaptation, and refinement. The team must constantly assess the established guidelines, adjusting their course as conditions and needs evolve. New guidelines may emerge as they explore the landscape while existing ones are reaffirmed or retired based on their continued relevance.
Just like a team of seasoned explorers navigating uncharted territory, achieving this requires a deep understanding of the system’s inner workings and the constraints of the environment it operates within. Skill, training, and experience are essential for traversing these complexities, ultimately leading to a successful team “conquering” the challenge of Accidental Architecture.
Did the steps we’ve outlined provide clear guidance on transitioning from Accidental to Intentional Architecture? What additional challenges or questions do you have about implementing Intentional Architecture? Please comment to let us know!
If our team of experienced consultants, strategists, and architects can help you navigate this journey, contact us to schedule a consultation and discover how we can help you achieve your business goals.
Garey Hoffman is a Partner and Vice President of Engineering of Object Computing. Hoffman plays a pivotal role in overseeing and driving the technical aspects of the organization. He is involved in managing a team of skilled engineers, architects, and technical professionals to deliver quality solutions and services to clients. He is also responsible for aligning technical strategies with business objectives, ensuring the successful execution of projects, and maintaining a strong focus on innovation and emerging technologies. Outside of the office, Garey is a lifelong builder and can be found enjoying the outdoors with his family.
Mike Pleimann has 15 years of experience as an Application Architect and almost 25 years in software engineering. Currently leading the Application Architecture team, he combines technical proficiency with managerial skills to guide teams toward success in large-scale software architecture and engineering programs. As a seasoned leader in the field, he brings a wealth of knowledge and strategic vision to his projects in telecom, collections, defense, and gaming industries. He is dedicated to crafting robust, scalable solutions that are fit for purpose and has consistently earned accolades from clients and peers. Mike holds a BS in Computer Science from Missouri S&T.
