By David Kreth Allen
In this article, I outline some goals and practices I have found that allow me to be an effective architect. I hope it will be helpful to others who wish to be effective architects. For each idea, I call out some common challenges I have faced in my career and how I overcame them. Effective architecture must be relevant, achievable, and delivered in a timely manner.
Relevance: Aligning with Business Goals
There are two parts to relevance. The first is about the output of the architect, and the second is about the process used to deliver the architectural artifacts.
The output of an architect has to be relevant to the organization’s goals, focusing on delivering tangible outcomes. Architects need to understand business strategy, market trends, and internal culture to design solutions that solve real-world problems and create value. Without relevance, architecture risks becoming an isolated, theoretical exercise.
To ensure the artifacts of architecture are aligned to the business requires a passion for the industry you serve. I had a CIO who told me that to be an effective architect, I needed to learn about our business. If you serve healthcare or consumer products, it means you understand the elements of that dimension. In the olden days (meaning pre-AI), it took an architect a long time to learn about an industry and an organization. One could work on projects, and sit at the table for your organization’s operational specialists to ask them probing questions about their strategy. Advantages of this approach are that you learned just what was needed for the project you were working on. This allowed me to deliver relevant results quickly. By sitting at the table with the operational team, and trying to help them deliver improvements, it also allowed me to build trust and connections needed to succeed. On the downside, I observed that while operational leaders may be knowledgeable about their fields, they are human just like me. They may have blind spots or gaps in their experience. To compensate, I would read books and articles, and take training courses in the business. Those traditional means are still relevant. But with the advent of widely available generative AI tools like ChatGPT, or Gemini Advanced Deep Research, it becomes much easier to get a research summary of an operational practice.
Another challenge I have faced is the expectation among operational leaders that I am “merely” a technical resource to give direction to engineers, and that I have no value in discussing business strategy. This partly stems from the fact that I have always been in the Technology organization. This is where diligent study has allowed me to understand the business well enough to converse with the operational leaders and earn their trust. I am not trying to be “smarter” than they are in their field. That would be arrogant. I am merely trying to be knowledgeable enough to converse with them without asking them to define the most basic ideas every few minutes.
The other aspect of relevance is about the process you follow. Any architect who has sought to follow a “standard” architectural process like TOGAF or Zachman, quickly realizes that tailoring the process to your situation is required. And that tailoring is always “left to the reader as an exercise” as my old college textbooks used to say. One has to adapt the process to the unique culture and constraints of the organization you are in. I have seen many architects at work, and have never seen one who did it like another. Just saying… So while I DO encourage you to study common architectural methods, do not expect to find a crisp recipe for how to do architecture in your organization. You won’t find it. And the sooner you realize that, the more quickly you can accept the challenge of adapting one of these frameworks to your unique needs.
Speed: Deliver on-Time
In a fast-paced business landscape, architecture must be agile. Speed means enabling quick pivots and adjustments as needs evolve. This requires modular and iterative approaches that avoid prolonged development cycles, fostering collaboration and embracing automation to maintain agility. Whether you are an enterprise architect or a project-oriented solutions architect, you must deliver something of value in time to be useful. A good-enough architecture, delivered on time, is better than a “perfect” architecture delivered late.
Learning to do “good enough” work instead of “perfect” work may be one of the hardest things you ever do.
In many of the projects I have worked on, I have felt I needed more time to “get it right.” Yet we seemed to deliver a working product on time. However, in a few cases, we really did need more time. And we were really sorry we rushed the work. I have no magic answer for you here. My tips for coping include
- Carefully document your arguments for why more time is required, and what the consequences of rushing are. Make sure those are in the written record. Make sure there IS a written record of decisions.
- If decision-makers do not agree with you, do not take it as a personal failure (to persuade). Strive to listen to their considerations and understand them. They may know things you do not know. They are ultimately accountable for making the decision. You are not. You must respect that.
I once worked on a project that I could see was going to be a train-wreck. In the past, I had left organizations over such things. It was too painful to witness. This time, I decided I would simply do my best, call out the risks, and stay onboard the train and watch the train-wreck from a front-row seat (to mix some metaphors). I told myself that even though it was going to be a train-wreck, I could learn by hanging around and doing the best I could in such situations. In truth, “train wreck” was merely a metaphor. We were not making space shuttles or pacemakers. Nobody was going to die if we messed up. It was a good experience. I learned at a visceral level what NOT to do on a project.
In dealing with such situations, the two extremes of fighting to get more time at any cost, and giving up entirely and just watching it wreck, are not the best choices. A better choice is to articulate what you can foresee, do your best to compensate for the shortcoming, and avoid saying “I told you so” when the predictable happens. If you are lucky, maybe it will turn out to merely be a bumpy ride instead of a train wreck.
Realism: Balancing Vision and Constraints
Realism involves designing within the constraints of existing systems, skills, and budgets. Architects must balance ambition with practicality, considering technical debt and organizational maturity. Realistic solutions avoid over-idealistic designs and ensure that plans are executable in the current environment. For architects who have grown up as software engineers, this can be hard to do. Programming teaches you to be precise. Programs don’t work when code is “approximately correct.” It is either correct or it has a defect. As architects, we deal with impossibly messy requirements, aggressive timelines, and incomplete knowledge. Being precise where possible, and letting go where appropriate is actually a difficult skill to develop.
One technique I find helpful is to maintain a formal technical-debt journal. It is a journal of compromises that were made in the architecture, typically done for expedience, to protect timelines or cost. It explains the ideal architecture, the one we chose, the downside to the choice we made, and why we made it. This helps one to respond to arm-chair architects who would challenge the decisions later. It is also a great tool for discussing the consequences of always taking the shortest path to the finish-line.
Concepts around agile architecture have been a help to me in balancing ideal long-term thinking with achievable short-term thinking.
In closing, effective architecture hinges on relevance to business goals, timely delivery, and a realistic understanding of constraints.