Developing and improving software or IT services is challenging. With change the only constant and competition fierce, organizations often live and die by their ability to adapt.
Unfortunately, most organizations are not structured to adapt quickly. Many fool themselves with superficial agile practices without building any real understanding. Some hire external consultants whose benefit ends with their consulting engagement. Others undergo discrete transformations, unaware that adaptation is continuous.
I find it helpful to think of software or IT services requiring three primary foci.
The first is automation. Usually fulfilled by software developers, this is what most people think of with software or IT services.
The second is knowing the customer. For example, an IT service targeting health may need to understand how doctors or clinicians work. A network management service requires understanding routers, networking and network security.
Multi-sided markets may require understanding multiple customer types. Uber, for example, requires understanding both passengers and drivers.
The third is providing the service. This focus includes onboarding/offboarding, billing, service desk/support, security and scalability/performance. Multiple roles within an organization often handle these.
The challenge with most organizations, and a significant reason they have difficulty adapting, is they hire specialists for each focus. Software developers, for example, are usually hired solely for their ability to write software.
Unfortunately, understanding one focus can only take you so far. For example, if you only understand the customer, you risk creating an uneconomical or impractical service. If you only understand automation, you risk automating things of little value. If you do not understand delivering a service, you will struggle to provide one efficiently and economically.
There are exceptions. Product Management is often familiar with the customer (second focus) and providing a service (third). They understand the economics and finances. However, they often distance themselves from automation to prevent a bias toward what their existing services can easily provide.
Management also absorbs a little of all three foci. However, their understanding is often shallow. Their attention is usually broader than just product improvement.
The solution is to identify and then incentivize specific staff to generalize across all three foci. They need to learn enough of each to (1) understand the impacts of a decision or change in one focus on the other foci and (2) identify when opportunities in one can provide a nett benefit.
By comparison, separate individuals struggle with this, even those who communicate well. We often think we know more about others’ roles and needs than we actually do. There is a “critical mass” of understanding that these generalists need to achieve.
The concept of hiring generalists or “T-shaped” skills is not new. However, this usually applies within one of the foci. For example, software developer generalists are often “full stack” developers, not ones familiar with non-technical areas.
Finding generalists is difficult. Each business is different and has different needs. While many universities offer combined IT and business degrees, they usually produce IT management candidates. While some universities provide mixed degrees, they often neglect the third focus on effective service delivery.
Similarly, many want to specialize and master their chosen craft. It is a better understood and measured career trajectory.
Importantly, these generalists do not replace specialists. Organizations need sufficient specialists to deliver each focus.
However, the best generalist candidates demonstrate interest or passion across all three areas. Submerge them in each focus, challenge them to translate the challenges and benefits of each and then task them with identifying bottlenecks and potential improvements.
One of the first hurdles they usually encounter is management structures. Organizations are usually built around similar skills, not business output. Organizations usually incentivize teams or departments around cost minimization and throughput, not customer value.
However, with executive support, creating and supporting these generalists will break down barriers and help the organization adapt quickly. Without doing so, organizations will stagnate, often too siloed or distracted by short-term problems.
Charles Darwin was right. Natural selection applies to organizations, too. Those that cannot adapt will be replaced by those that can.
It is hard not to find advice on being a great IT architect. Beyond modelling and technical details, good advice includes effective persuasion, people skills and persistence. However, the need for non-technical skills is often left as self-evident or explained superficially. It also glosses over important details and distinctions.
Traditionally, IT has two types of roles. The first role is the implementor, such as a software developer, network engineer or QA. They produce non-delegatable outcomes. The second role is a manager or executive, someone accountable when something goes well or poorly.
IT architects fit into neither role. Their value becomes apparent when the project or organization gets big, complex or conflicts with team objectives. They are not more intelligent or more capable than implementors or management. Instead, they solve an emergent need.
IT architects are internal consultants, helping team members to execute and management be successful. Enterprise and senior solution architects increasingly provide executive decision support instead of design, almost becoming a separate role.
However, being a consultant has two fundamental but often missed implications for IT architects. The first implication is an IT architect has no intrinsic authority. Their authority stems from the stakeholders, usually management or executives, that their architectures enable or support.
Whose authority is usually evident in client-facing product teams who share a reporting structure. However, this is often unclear in projects spanning multiple reporting lines, such as large or siloed organizations or internal IT projects. Shared responsibilities between business and IT muddy this further.
The second implication of an IT architect being consultative is people often incorrectly think IT architects, like consultants, are paid for their opinions. Yes, implementors consume the artifacts produced by IT architects, like designs and principles (“opinions”). However, neither stakeholders nor implementors blindly accept them.
Instead, an IT architect should prioritize and justify their outputs as stakeholders do to their superiors. This approach consists of three pillars.
The first pillar is financial. How do the IT architect’s actions make money, save money or lose less money? Start with understanding how the organization funds projects. For example, if maintenance and operation costs are separate, the IT architect may need to justify up-front efforts to reduce each to different stakeholders. A move to IaaS cloud hosting is easier if the organization favours OpEx over CapEx.
The second pillar is metrics. Executives and managers often have objectives, measures or other targets they need to reach. While they are rarely perfect, an IT architect should understand them and reference them. For example, if cost-saving is a metric for a critical stakeholder, ensure the design reduces net cost.
The third pillar is language. The IT architect should learn and use the terms used by executives and managers. Such language varies between organizations and shifts over time but talking like decision-makers helps an IT architect seem credible.
Another question is how much authority the IT architect holds. There is no definitive answer. Less technical management and executives often dismiss the question as an IT issue. IT management may lack the strategic incentives to avoid cutting corners. Organizations rarely question the level and nature of authority when successful. However, they can scramble when things go downhill.
Aligning expectations and processes beforehand, both individual IT architects and the team, is a practical first step. How is development tracked against the architecture? Is there a process for changing or disregarding parts of an architecture? How do you differentiate poor execution from a good architecture or vice versa?
Once an IT architect establishes this, IT architects can then differentiate the value of their project from their value as IT architects. The accountability for a project rests with the appropriate executives and management, not the architect. The IT architect needs to focus on their part in it.
Selling an architecture or design and selling the value of an IT architect are related but different activities. Selling a design, for example, requires helping the customer meet their own goals more effectively. It happens periodically, usually once per project. It makes you authoritative for that project. Selling an IT architect role and understanding stakeholder needs are both ongoing, continuous processes.
IT architects are a bit like CEOs. CEOs’ primary customers are the investors or owners of the organization. While ignoring actual customers or staff seems cynical, good investors care about the organization as a whole and beyond just customers’ short term needs.
An IT architect’s “investors” are their stakeholders. Like CEOs, IT architects will rarely keep everyone happy. Not every team will have every need met. Every change involves winners (profit, less work) and losers (more work, more responsibility).
The success of an IT architect relies on their ability to identify and sell their value to the correct set of stakeholders. Selling is challenging and complex. Stakeholders are rarely technical, at least from an architect’s viewpoint, and require empathy.
For example, non-IT management wants justification in business terms, usually financial. They often regard “good design practices” as an unnecessary expense. While organizations are using more technology, technology is rarely a core business competency or differentiator. The onus is on the IT architect to justify anything beyond a minimal expenditure.
Having to justify technology use constantly is frustrating. IT architects often evolve from technologists who “look up” or “see the big picture”. However, the big picture is not really about technology. It is about the application of technology to broad, often ill-defined and contradictory goals. If it were easy, we would not need good IT architects.
For most of us, smartphones replaced paper maps long ago. You enter your destination, and it presents you with multiple potential routes. Given one route is often fastest, why bother?
The smartphone may not have all the information, such as weather or traffic. The phone does not know that an alternate route may be faster.
Perhaps the environment changes after navigation starts. Having a prepared alternate makes switching routes easier.
Speed may not be the crucial attribute. Maybe the driver wants the psychological safety of a familiar but slower route. Maybe one route is more enjoyable and scenic. Maybe the driver wants to shop on the way.
The fastest route may also have variability or risk. Maybe a football game at the local sports ground will finish soon. If time is tight, the time of a slower route may be more predictable and, therefore, better.
These reasons also apply to IT architectures at any level, whether technical/component, solution or enterprise.
The problem is most IT architects come from an implementor background, like software developers or network engineers. Good implementors build complex and deep mental models of their systems. These models allow implementors to both isolate issues and plan small to moderate changes quickly and effectively.
Organizations incentivize implementors to make changes quickly and with low risk. Having a good mental model facilitates that. The sooner an implementor can envisage and choose a solution, the sooner they can implement it and the sooner it can ship. This speed inspires confidence and provides technical leadership.
However, architects need to think differently to implementors. They still need higher-level mental models but should think more strategically (“Are we solving the correct problems? Is the solution complete?”). IT architects also need to think politically (“How do I convince stakeholders of the solution’s value and my value?”).
An architect should own all technical solutions in a business problem space. Providing a single solution implies the architect owns the solution, not the problem space. Subsequent design changes, even improvements, may diminish the architect’s credibility.
Focusing on a single solution alters how people justify them. The more assured people are that a solution is best, the less strongly they argue for it. They lose empathy with others to whom the solution’s merits are less clear. They often think beyond the design and evaluation stage and are frustrated when yanked back. Alternatives contrast and identify the solution’s pros and cons.
Providing multiple solutions helps generate discussion. Stakeholders may have differing preferences. Presenting different solutions, like playtesting a game’s rules or A/B testing a website, can draw out these preferences and derive the best solution. Stakeholders are customers.
Creating good alternatives and fighting an implementor’s instincts is difficult. The trade-offs are situation- and stakeholder-dependent.
That said, most organizations treat IT purely as a cost. Therefore, the biggest concern in any IT system is cost, including staff, time, and money. Create alternatives that minimize one or more of these by dropping, substituting or minimizing features.
Never sacrifice quality when creating alternatives. Stakeholders, particularly executives, are often not accountable for maintainability, security, availability, and the like. If they are not accountable, they do not care. For those that are accountable, quality is hard to quantify or demonstrate, so executives almost always delegate it.
Another alternative source is the “shortest path to value” (SPV). SPV identifies small projects within large ones with the biggest “bang for buck”, embodying the Pareto principle or 80:20 rule. SPV reduces otherwise massive projects that are hard to scope or have high schedule risk, making them more concrete and predictable.
Consider implementing the project using different technologies (tools or frameworks) or teams. Another team, even if only hypothetical, may take a different approach. Using or avoiding the technology de jour also opens possibilities. A greenfield project has advantages and disadvantages over non-greenfield projects.
Re-examine constraints or “bad ideas”. Even “hard” constraints are sometimes malleable. People often shun anything close to bad ideas. However, unrecognized good ideas often surround bad ideas.
Providing a single “best” solution undermines the architect’s credibility and removes agency from stakeholders. Like smartphone navigation, an IT architect often lacks full knowledge, may not grasp all requirements or environment, or solutions may provide unexpected opportunities for stakeholders. The biggest barrier is frequently identifying good alternates.
However, the biggest reason why alternatives are so powerful is IT architects need to differentiate themselves and sell their role. IT architects are not accountable like managers or responsible like implementors. Their value proposition is technical insights and good designs. Creating, evaluating and comparing the alternatives provides those insights and demonstrates the superiority of that design.
It seems every organization wants to transform itself to become more agile. They want to respond to opportunities quickly and cost-effectively. They want to adapt faster than their competition in the Darwinian corporate landscape. COVID-19, for example, required a quick shift to remote working for their employees and remote interactions with clients and suppliers. Geopolitical changes alter supply chains and increase legislation. Cloud, IoT and similar internal IT trends accelerate.
An agile transformation often starts with a consultant-led agile processes adoption. These range from methodologies like Scrum at the small scale and Scaled Agile Framework (SAFe) at the highest. Despite some negativity in the agile community aimed at higher scale methodologies, these methodologies help by providing structure, vocabulary, and expectations.
However, following anagile process is the least important part of being agile. An organization attempting to increase agility solely by adopting a new process usually creates superficial changes that foster change fatigue, at best, or failure, at worst. This failure is often then incorrectly attributed to the process without any more profound and helpful introspection, leading to the negativity mentioned earlier.
An agile organization needs agile systems. “Agile systems” does not refer to using a tool like JIRA to track work. Agile systems, both IT and business processes, are easily changed and provide feedback for timely validation or correction.
Modern software development practices are a good example. Frequent demos to users and stakeholders and automated testing and deployment, for instance, ritualize change and create tighter feedback loops.
However, an organization’s systems are not agile if only their software development teams are agile. For example, consultants often build organizations’ back office and operational systems by customizing third-party tools. Organizations then maintain them with skeleton teams and, therefore, usually lack the skills or the environment to change them safely and cost-effectively.
Product Owners are not the answer. Product Owners can shield their team’s backlog to encourage agility. However, systems are more extensive than just the team or teams that maintain or implement them. Product Owners are also usually experts in the business area and handling internal politics. They are rarely also design experts and incentivized to think strategically.
Agility extends to data. Organizations are under increasing pressure to collect and monetize data. Agility requires knowing where that data is (“systems of record”), ensuring its quality and integrating it with other systems (“systems of engagement” or “systems of transformation”).
Governance systems must adapt. Regulatory, financial, legal, risk, IT security, privacy and similar teams must work in smaller batches. A lengthy, formal review of a completed system is often too late.
Unfortunately, articulating the benefits of agile systems is difficult. Pruning teams to their minimums has clear short-term financial benefits. Executives often overstate their systems’ capabilities through ignorance or self-promotion. Product teams may fall into the trap of a short-term, sales-oriented focus under the guise of being customer-focused. Asystem’s agility often depends on an executive’s skill at shielding budgets or convincing stakeholders.
These problems may extend to company culture. Business processes sometimes lack an agreed, empowered business owner. IT is sometimes “seen and not heard”. Insufficient executive representation or ownership means minimal focus and support, making agility practically impossible.
An agile organization also needs an agile structure. This statement may sound tautological. However, an otherwise agile organization that cannot leverage and benefit from that agility wastes that effort.
A good example is what SAFe terms the “network” versus the “hierarchy”. Most organizations structure themselves hierarchically around similar skills for ease of management. For example, an organization often has a legal department for lawyers, a sales department for salespeople and an IT department for developers and system administrators.
However, work frequently requires people across different teams to cooperate, called the “network”. Identifying value chains then building and supporting these multidisciplinary teams to implement and enhance them increases flow, ownership, and individuals’ agency. Effective use of “networks” requires different management techniques and incentivizing outcomes, not throughput. These often fail without executive support.
Organizations are rarely homogeneous. Some teams or systems may be more agile than others, such as through mergers/acquisitions or pockets of conscientious staff. Tracking and aligning these is vital. Otherwise, some teams may adopt inconsistent processes or tools, be omitted from the transformation or optimize at others’ expense.
This all assumes the organization’s bottleneck is the lack of agility. Organizations frequently want to decrease “friction” but cannot articulate it beyond the highest level. Defining friction by actionable, measurable metrics is a prerequisite. Increasing agility also only highlights any poor prioritization or lack of focus.
The “transformation” concept is also a misnomer. Agile thinking encourages constant self-evaluation and improvement, and this “transformation” does not end when the consulting engagement does. From the executive viewpoint, this can scarily move the fulcrum of structural control into the middle and lower levels of the organization.
The chosen agile methodology’s principles best guide agile transformations. Unfortunately, people easily gloss over these in favour of the easily implemented and more prescriptive processes. However, these are often what the more prescriptive parts are derived from, not vice versa. If you want to be agile, internalize the principles!
Agile transformations are more than superficial changes. Focusing too much on process changes instead of systems and structures often stalls or blocks agile transformations. Instead, these transformations require people to move outside their comfort zones, particularly executives. The problem with agile transformation is it is hard but increasingly necessary.
You have just presented your architecture to management. You slaved over every technical detail, followed all the standard templates and convinced all the technical leads. Every “i” is dotted and “t” crossed. Expecting praise for a job well done, the presentation never really engaged with the audience. The R&D manager asked about an off-the-shelf solution instead and the operations and IT managers argued over who would operate the system. Others seemed disinterested. What went wrong?
Software developers, infrastructure engineers and other technical roles reflexively solve problems using their technical expertise. It is their strength and value to the organization. However, it gives them tunnel vision on both the possible solutions and how to present them.
As we scale up architecture to solution or enterprise architecture; the economic, staffing, tooling and political impact increases. Architects are not salespeople and our audience wants us to help solve their problems. However, architecture is not just about presenting technical solutions. It is about persuading stakeholders that the solution presented is the best.
To do so, first understand the true scope of the problem and the solution. In addition to systems and tools (where architects from technical background excel), a business comprises people and process too (where architects from technical backgrounds fare less well). If in doubt, identify and engage those knowledgeable to assist.
This is where different architecture representations excel. While many technical architects focus on application, infrastructure or data architecture, also capture process (e.g. BPMN or flowcharts) and people/functions (e.g. use case diagrams). Use existing repositories, tools or standards if they exist to avoid duplication. Pictures and diagrams are generally more effective than blocks of text. If a new system requires staffing changes, work with the appropriate managers first and avoid open discussion of this until details are finalized.
Second, preempt questions and concerns. The architecture presentation should not be is the first time you learn of a concern. Put yourself in the shoes of stakeholders. Apply analysis not just to the problem but also the audience. Asking stakeholders for advice is almost always received positively.
List the other possible solutions for each key decision and justify the chosen solution, like the TOGAF “Consolidated Gaps, Solutions, and Dependencies Matrix”. Less experienced architects may find it difficult to even articulate each decision because they are instinctively leaping to a sound technical solution and not taking the requisite steps back. The best architects argue against their own architectures to find gaps. Have this list accessible because you never know when you may be ambushed in the corridor.
In this justification, consider looking outside your organization. While you are not writing an academic article with a minimum required number of citations, referencing industry standards and publications can help stakeholders unfamiliar with an area understand this is not new ground.
More experienced architects take an economic view. Architects need not detail exact cost amounts (it will usually be wrong) but the most cost-effective solution may not be the technically best solution.
Another technique is to create different material for each audience, like TOGAF views satisfying viewpoints. Remove some technical detail for non-technical audiences and use the material for the different perspectives described above. While time-consuming; a succinct, relevant case is more persuasive than a longer, less-relevant one.
Third, make your slides or material attractive. If you want people looking at it, it needs to be something pleasant to look at. Consistent formatting, notation and color schemes are all important. Storytelling and similar techniques can also help but should be used sparingly – architects are not salespeople.
Fourth, own problems or areas, not solutions. Senior stakeholders are very good at sensing hidden agendas, like an architect pushing their preferred design. If someone has a point, acknowledge it and, if you need time to think it over, ask for it. Argue strongly but hold opinions weakly.
Lastly, architects need to be thought leaders in their organization by shaping terminology and direction while understanding the technical and business environment they are responsible for. An architect’s goal is to shepherd the business toward a better state than it is now.
Many architects mistake thought leadership for being more technically knowledgeable and skilled than developers or engineers. This can be sustained in the short term but technical subject matter experts (SMEs) will eventually surpass the architect. They devote more time to it – it is their function. It also can bias the architect toward the status quo and technical solutions – something that may dissuade less technical stakeholders.
Instead, architects should learn about as many different perspectives as possible. Architects need to be the team of “know” instead of the team of “no”. Listening is power and understanding peoples’ needs and wants, including technical SMEs, is the first step toward satisfying them. It also builds trust and, ultimately, persuasion is built on trust.
Many things about IT architecture simultaneously attract and repulse people. Architects are technical decision makers but often leave the implementation to others. They translate between the business and technical, taking an economic view of IT.
Fortunately and unfortunately, architects are not managers. While this frees them from budgets, staffing and directly managing people; it also means every decision they make is really a decision making aide for other managers. Architects are all responsibility but no authority.
Architectural authority is only granted through the authority of the management responsible. While managers can perform an architecture function, often in smaller teams, architects are usually senior individual contributor roles. Teams implement an architect’s designs because the manager says so.
Acting through managers’ authority also means architects must influence to ensure their architectures are adhered to. While some architecture teams take a more dictatorial approach, most architecture teams ensure their designs have clear benefits for all stakeholders and contributors. If a team sees no value to them from following the architects’ directions, they can often ignore it.
Even governance – ensuring other’s designs are complete, follow the broader architectural vision and are implemented as specified – works via influence. A lower level manager may baulk at his or her team doing significant work that does not benefit their team but there are often constraints or impacts outside their team. Higher level management must step in to ensure teams meet broader business goals, not just their own.
Like managers, architects engage with multiple teams and senior management. They need to communicate at different levels with different strategies (like management), switch frequently (like management) and are ultimately judged by outcomes (like management).
This means the architect depends on others to ultimately implement the systems involved. Like managers, architects need to tailor their output to their teams. An architect can delegate much of the lower-level details to a capable team familiar with the problem may need only high-level direction. An inexperienced team working on an unfamiliar problem may need a lot more help. An architect’s failure can doom the project.
Like management, architects handle ambiguity and conflicting requirements. These require a mix of technical, business and political knowledge to navigate but also allow the architect (or manager) to demonstrate his or her experience and value. Architects, like managers, should be looking at the bigger picture, considering the economic impact and giving non-technical solutions their due.
Of course, there are many things managers need to consider that architects do not. For example, architects can rarely delegate. Architects are individual contributors tasked with ensuring minor, often technical details do not compromise strategic goals.
Unlike management, architects need to evangelize their work and value more than management because they lack management’s built-in responsibilities. They may be the driving force behind a project but the success may be attributed elsewhere.
However, the overlap between management and architecture is larger than many realise. This overlap is why architecture is a senior role. When an architect sneezes, their areas of responsibility catch a cold. Architects are not managers but they players in the same game. They do a lot of managing anyway, whether that be up or down.
IT architects often pride themselves on their technical knowledge. Tasked with designing a system from end-to-end and taking responsibility for that design, they need to ensure the details are right. They also need to demonstrate technical prowess to earn respect from technical developers and engineers.
However, as discussed in previous posts, architects also have to talk to non-technical people to gather requirements, understand the business context and assure them that a design will meet their needs. For people used to delving into the technical details, this context and mindset switch can be challenging.
First, understand the value the architect’s proposed changes bring to stakeholders and organization. Understand not just what each stakeholder has asked for but how that stakeholder’s performance is measured and describe the impact of proposals in those terms.
Taking an operations manager as an example, describe how this will reduce incident frequency or severity. For a salesperson, relate this to imminent or key deals. For any management, ensure they understand how the changes relate to KPIs, long-term objectives or organizational policies.
A quick way to do this is to describe a technical change then ask “So what?”. Relate it to each stakeholder in a sentence or two then invite questions. Take note of anything asked and ensure it is covered next time.
Sometimes non-technical people suggest technical solutions. While most IT architect’s immediate reaction is to dismiss these as ill-informed, a better response is to understand the reasons behind it. Did this suggestion work last time? Is the relative cost for the asker small? Is a suggested tool the only one the asker is familiar with?
A better response from an architect is to evaluate suggestions and provide quicker, cheaper and/or better alternatives. Sometimes, however, it is important to buy-in by using elements of their suggestion, even if it is technically suboptimal.
Unless the organization has prescribed formulas or a culture of doing so, avoid trying to express impacts in financial terms. Chances are architects will get it wrong. Be careful using jargon or discipline-specific terms, too. Technical people cringe when non-technical people misuse technical terms. It happens the other way around, too.
Describe the context of a technical change in both technical and business terms. What existing systems or processes are impacted? What can we do now that we could not before? What can we do better or cheaper? What additional work is required or what work is saved?
No system exists in a vacuum and there are always flow-on effects for every change. If an architect cannot articulate these, chances are the requirements were not fully understood or analysis was lacking.
Describe the impact constraints have on the design or team implementing the design. Do not just list them (“We only have three engineers”). Say how this impacts the solution (“Option A is a better solution but, because we have a small team and a tight deadline, we are going for option B”).
Everyone in the organization has to deal with constraints. Sharing them helps build trust across teams. It also invites stakeholders, who sometimes have more experience, to suggest better ways of dealing with them.
Produce and use good quality communication. Consider using multiple views of a solution for different audiences, emphasizing different aspects. Use aesthetically pleasing diagrams with consistent use of symbols and colour. Do not be afraid of detail – it gives the audience the impression you have a deep understanding of the problem and solution – but ensure the communication is broad, covering the value and context as outlined above, instead of deep. Provide overviews or summaries to help time challenged people understand important points.
Communication should also cover solutions that were not selected or implemented. The implemented design or change will be evident. Understanding what alternatives were considered is often forgotten, particularly for trade-offs or others’ suggestions.
Beyond communicating better with non-technical people, these practices help architects understand the impact of technical changes on the organization beyond the immediate. It raises questions about larger impacts and exposes gaps in the architects understanding. It also helps build relationships.
Ultimately, being able to communicate effectively with non-technical people makes the architect a better architect. IT architects are more than just designers. They are collaborators and evangelists and they cannot do this if they can only talk and think like engineers. Architects are often the face of the team, department or company and the impression the architect needs to make a good impression.
Moreover, an architect’s technical solution exists within the organization’s social and political environments, not just technical. The architect is responsible for their work’s political and organizational success, too.
Many IT engineers aspire to be architects. They want to dictate the course of their products or services, leading their fellow engineers. To do so, they focus on designing the best and largest systems, learning all about design patterns, notations and understanding technology from top-to-bottom.
However, if such a thing can be said to exist, even the best design is wasted if it does not solve the right problem. Architects should start here, instead.
Depending on the organization, requirements are often supplied by product management, business analysts or management. During requirements analysis, architect validation identifies ambiguities, omissions, estimated time and resource costs and likely tradeoffs. The resulting requirements and priorities may differ substantially from the original as trade-offs and discoveries are made.
Requirements often present the business understanding of what technology should do, not the most impactful or beneficial things technology can do. Architects are in the best place bridge the gap, driving technology from the bottom-up instead of the top-down.
Business-supplied requirements often lack quality attributes or non-functional requirements like availability, performance and security. These are either assumed or difficult for non-technical people to articulate and architects are the best equipped to specify these.
Architects need to listen more than they talk, learning as much as they can about the business context of their work and its business value. Drilling into requirements is a good start, helping to understand requirements’ context, assumptions and priorities. There is no point where an architect understands everything, only a process to continually learn.
While it is tempting for a newly appointed architect to focus on their pet technical problems, ensuring they have a good pipeline of requirements helps architects to align their efforts to solve others’ problems, not just the ones they perceive. They also need to ensure the business outcomes are met, not just the technical enhancemnts.
Looking at it another way, a design is not just a model (approximation) of the implementation. A design is the requirements for the implementation. Like requirements gathering, design is iterative and may change through the review or implementation process. Like requirements gathering, design is a trade-off. Like requirements gathering, it is an abstraction, leaving some details to implementers. If an architect cannot understand or provide good requirements, their designs are going to be misunderstood, at best, or ignored, at worst.
Moreover, architects are leaders. Not leaders in the management sense but leaders by collaboration, communication and example.
While the technical leadership of architects is well understood, good architects move out of their comfortable technical conversations and into the less comfortable business conversations. As mentioned above, some requirements sit between the technical and business and stakeholders need assurance the system will meet their needs. No design pattern or notation will achieve this.
Architects should focus on outcomes and end-to-end systems, not the minutiae of their designs, particularly in agile environments where just-in-time design occurs or where component responsibility is delegated to teams. Trusting implementors by giving them clear interfaces, scope and direction is the best way to foster their trust in architects.
Architects must own their communication. The responsibility for implementors and stakeholders understanding the design and vision rests with the architects. A design or vision that is not communicated is not understood and an architect producing designs no one understands has zero business value.
An architect must also facilitate communication between teams, particularly when design changes ripple through other teams’ work.
Architects must be accountable for systems they architect. They need to listen to implementors to understand their challenges and how to mitigate them in current or future designs. They need to accept criticism from stakeholders when requirements are not met. They also need to be applauded when their projects or systems succeed.
While designs are the architect’s deliverables in many projects, an architect’s success is driven by their ability to ensure they are solving the right problems and assure people of that direction. Good architects look down toward the technical detail and ensure it is correct. Great architects also look up and around to understand how they can best provide value to the business, sometimes better than the business can.
I am a self-motivated, adaptable, outcome-focused enterprise and solution architect that gravitates toward technical leadership roles. My experience covers architecture, management, security and software development roles over 20 years, from multiple startups to global technology companies. I am an inventor of multiple patents; hold a variety of security, IT and agile certifications and contribute to open source software.
I have worked as an enterprise and solution architect at global technology companies like NTT Limited and Symantec. My focus has always been client-facing services, ideally ones that mix software development and IT management.
This blog explores the deeper thinking and processes behind writing software, building IT systems, and how they fit into the wider IT and business landscape.
Opinions expressed in this blog are the author's and not necessarily those of his employer or its affiliates.
Content is published under the Creative Commons Attribution-Noncommercial-No Derivative Works 4.0 License.
The header image and blog icon are from the blog Random Acts of Photography. This is used with kind permission from the author and under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License.
![pros-cons[1]](https://randomarchitecture.files.wordpress.com/2018/05/pros-cons1.jpg?w=300)
IT architects often pride themselves on their technical knowledge. Tasked with designing a system from end-to-end and taking responsibility for that design, they need to ensure the details are right. They also need to demonstrate technical prowess to earn respect from technical developers and engineers.
Anthony Langsworth
@alangsworth
anthonylangsworth
Random Acts of Architecture 