Software architecture is often discussed in terms of knowledge. Which architectural patterns do you know? Do you understand Domain-Driven Design? Can you design distributed systems? Do you understand cloud architecture, Event-Driven Architecture, security, scalability, and resilience?
These are important questions. But after years of working with software ecosystems, sociotechnical systems and transformation initiatives, I have become increasingly convinced that knowledge alone does not make someone an effective software architect.
There is another way of looking at this. In The 7 Habits of Highly Effective People, Stephen R. Covey defines a habit as the intersection of three dimensions: Knowledge, Skill and Desire.
In Covey’s definition1, knowledge represents what to do and why, skill represents how to do it, and desire represents the motivation or willingness to do it.
I find this model surprisingly relevant to software architecture. Architecture is not shaped only by what an architect knows, but also by the ability to apply that knowledge and the willingness to do so consistently in everyday work. Looking at architecture through these three dimensions gives us a different way to think about what makes an architect effective.
In the following sections, I will explore knowledge, skill, and desire individually and translate each of them into the daily practice of software architecture.
Knowledge: Knowing What and Why
For a software architect, knowledge goes far beyond knowing technologies. It includes architectural principles, patterns, distributed systems, integration approaches, security, cloud platforms, data, and software design. But it also includes understanding the business domain, organizational context, and constraints within which the architecture exists.
Architectural knowledge, however, is not simply knowing what can be done. An architect needs to understand why a particular decision makes sense in a particular context.
- Why should the system be spitted this way?
- Why should these components communicate asynchronously?
- Why is this domain boundary appropriate?
- Why should technical debt be accepted now rather than addressed immediately?
The same architectural solution can be appropriate in one context and completely wrong in another.
This is what makes knowledge an essential part of an architectural habit. A software architect architect should be able not only to propose a solution, but also to explain the reasoning, assumptions, trade-offs, and consequences behind it.
Knowing what without understanding why leads to applying solutions. Knowing what and why leads to making architectural decisions.
This idea is strongly reflected in the work of Mark Richards and Neal Ford, who define “Why is more important than how” as the Second Law of Software Architecture2.
Their argument is that understanding how an architecture works is not enough. Architects must understand and preserve the reasoning behind important decisions: why a particular structure was chosen, why one trade-off was accepted over another, and what context shaped the decision.
Without this reasoning, an architecture diagram may explain the solution, but it cannot explain the architecture behind it.
Skill: Turning Knowledge into Action
For a software architect, skill is the ability to turn knowledge into effective action. Understanding Domain-Driven Design, architectural patterns, distributed systems, or cloud technologies is valuable, but knowing these concepts does not necessarily mean being able to apply them. Architectural skill develops when an architect can use that knowledge to address real problems within the constraints of a real system and organization.
This becomes particularly visible when architects face ambiguity and trade-offs. Understanding Domain-Driven Design conceptually is different from discovering meaningful domain boundaries in a complex organization via workshops like EventStorming and Domain StoryTelling.
Knowing several architectural patterns is different from determining which one fits the actual problem. Similarly, understanding architectural trade-offs is different from being able to evaluate them and communicate their consequences to developers, product managers, and executives.
Knowledge provides the foundation, but skill is what enables an architect to put that knowledge into practice.
Architectural skill therefore includes designing and evolving systems, evaluating trade-offs, modeling architectures, identifying risks, facilitating discussions, communicating decisions, and guiding implementation. It also extends beyond purely technical abilities. As matter of fact, architects need to listen, communicate, negotiate, and bring different perspectives together.
Desire: The Often Forgotten Dimension
For a software architect, desire is the willingness to consistently put knowledge and skill into practice. An architect may understand why architectural decisions should be documented and have the skill to write an Architecture Decision Record, but neither guarantees that it will actually happen.
Desire is what creates the motivation and discipline to act.
This becomes especially important when architectural work becomes uncomfortable. An architect may know that assumptions should be challenged and have the communication skills to do so, but are they willing to ask the difficult question in a meeting?
They may recognize that a previous architectural decision no longer fits the current context, but are they willing to reconsider their own decision? Architecture requires curiosity, openness, responsibility, and the willingness to accept uncertainty rather than simply defend what has already been decided.
Desire is therefore what turns architectural capability into consistent behavior. It encourages architects to keep learning, listen to different perspectives, question assumptions, resist unnecessary complexity, and respond when the system or its context changes. Sometimes, it is also the willingness to acknowledge the limits of our knowledge and simply say, I don’t know yet.
Architectural Habits in Practice
An architectural habit emerges when knowledge, skill, and desire come together in everyday architectural work. Based on Covey’s model, I define an architectural habit as:
An architectural habit is the intersection of knowing what and why, being able to act on it, and having the desire to do so consistently.
Consider Domain-Driven Design:
- Understanding its concepts and principles represents knowledge.
- Being able to discover meaningful domain boundaries and translate them into software structures requires skill.
- Continuously questioning whether those boundaries still reflect the evolving business requires desire.
Together, these dimensions turn the application of Domain-Driven Design into an architectural habit. The same applies to practices such as managing technical debt or documenting architectural decisions.
- Understanding why technical debt matters is knowledge;
- being able to identify, communicate, and manage it is skill; and
- having the discipline to address it continuously requires desire.
Similarly, an architect may understand the value of Architecture Decision Records and know how to create them, but maintaining them as a regular part of architectural work requires all three dimensions.
Architectural habits are therefore not defined by what architects know, but by what they repeatedly put into practice.
Architecture Through Habit
Architecture is not simply a body of knowledge that an architect acquires and then possesses. Systems change, businesses evolve, teams reorganize, technologies emerge, and constraints shift. What an architect knows today therefore cannot be enough for every situation tomorrow.
Architectural practice depends on repeated behaviors: observing the system, asking questions, evaluating trade-offs, communicating decisions, learning from feedback, and revisiting assumptions when the context changes. These are not isolated activities performed once during the design of a system. They need to become part of the architect’s everyday way of working.
Over time, these repeated behaviors become architectural habits, influencing not only how architectures are designed but also how they evolve. The distinction between knowing architecture and practicing architecture can therefore be summarized simply:
- knowledge tells us what and why,
- skill enables us to act, and
- desire makes us do it consistently.
Where these three dimensions intersect, architectural habits emerge.
Architectural Habits and SEDA
This idea of architectural habits also connects closely to the Systemic Event Discovery Approach (SEDA). SEDA treats architecture and transformation as an ongoing cycle of discovering the system, understanding its domains, observing emergent behavior and feedback, and sustaining evolution as conditions change.
Knowledge and skill enable architects to understand the system and act on what they discover. But desire is what keeps the cycle moving. It is the willingness to return to the system, observe new signals, question previous assumptions, learn from feedback, and adapt architectural decisions when the context changes.
In this sense, SEDA provides a practical environment in which architectural habits can develop. The repeated cycle of observe, understand, act, learn, and adapt turns architectural thinking from an occasional design activity into a continuous practice. Architecture evolves because architects develop the habit of evolving it.
Beyond Habit: The Effective Architect
The idea of architectural habits should not be confused with a complete definition of what makes an architect effective. Gregor Hohpe offers another useful perspective in The Software Architect Elevator. In the chapter An Architect Stands on Three Legs, he argues that a successful architect stands on three legs: skill, impact, and leadership3.
- Skill is the foundation of architectural practice,
- impact reflects how that skill benefits the organization, and
- leadership represents the architect’s contribution to advancing the practice itself.
Hohpe’s model and the knowledge, skill, and desire model discussed here address different dimensions of architectural practice. Knowledge, skill, and desire explain what enables a behavior to become an architectural habit. Hohpe’s model looks further outward: whether an architect can turn capability into organizational impact and eventually use experience to influence, mentor, and advance others.
The two perspectives therefore do not contradict each other; they operate at different levels.
There is also an important connection between them. Hohpe describes skill as requiring knowledge and the ability to apply it to solve real problems. This closely connects with the knowledge and skill dimensions of architectural habits.
But effective architecture cannot stop there. Repeatedly applying those capabilities with discipline and intention creates the behaviors through which architects can generate impact. As their experience and influence grow, those behaviors can also contribute to leadership. I therefore see architectural habits as part of the foundation on which Hohpe’s three legs can develop.
Knowledge, skill, and desire shape how architects practice; skill, impact, and leadership describe how that practice grows into broader professional effectiveness.
- Stephan Covey, The author of The 7 Habits of Highly Effective People ↩︎
- Mark Richards & Neal Ford, Fundamentals of Software Architecture: An Engineering Approach, O’Reilly Media ↩︎
- Gregor Hohpe, The Software Architect Elevator, O’Reilly Media ↩︎
