Random Acts of Architecture

Tales of an architect trying to bring order to the chaos that is modern information technology.

Tag Archives: Stakeholder management

Talking Non-Tech

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.

Image Credit: http://www.thebluediamondgallery.com/wooden-tile/v/value.html under Creative Commons 3 License (CC BY-SA 3.0)

Requirements and leadership, not design, are the keys to architecture

Listen Understand Act

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.

Image from https://www.flickr.com/photos/highersights/6231641551. Used under creative commons license.

Architect/Stakeholder Inversion

Stakeholder Architect InversionArchitect/stakeholder inversion occurs when non-technical stakeholders tell software architects how a system should work, not what it should do. Without the “what”, software architects are left trying to guess or reverse engineer it. The resulting system may not solve the customer problem or may bloat with features attempting to do so.

Architect/stakeholder inversion is not a stakeholder wanting to move a system into the cloud to reduce costs. It is not wanting a mobile app to reach a different, younger market or offer a better user experience. It is not marketing pushing for a better analytics tool. They have business justifications.

Architect/stakeholder inversion is wanting two products integrated without saying what data to share or tasks to provide. It is creating a report engine without knowing the reports it will run. It is any framework created solely to handle nebulous requirements.

Architect/stakeholder inversion occurs due to one of three reasons. First, non-technical stakeholders feel they need to give low-level, technical requirements. Usually a sign of inexperience or frustration, the stakeholder bypasses discussion with technical details.

Alternatively, software developers may be used to implementing what they are told. This is common in environments with many ancillary roles (user experience, visual design, business analysis, copy writing, solution architecture, application architecture, agile coach, project manager, scrum master, team leader, etc) and stakeholders may take advantage of this.

Second, stakeholders often make technical assumptions and present those assumptions as solutions. They may not even realize they made assumptions.

Technical people may miss the business impacts of technical choices. However, non-technical stakeholders may miss technical impacts of business choices, too. For example, while the ongoing costs of moving to an “Infrastructure as a Service” (IaaS) or “Platform as a Service” (PaaS) provider may be lower, non-technical stakeholders may not consider the transition cost and impacts on compliance, security, jurisdiction, privacy, bandwidth and latency. The stakeholder might not have considered other benefits, such as elasticity (rapid scale up or scale down), built-in monitoring and management tools and cheap creation of test and staging environments, either.

Stakeholders with technical backgrounds may exacerbate the problem. While the technical solution requested may be good, the business context is still needed. Software architects are part of the checks and balances for the business requirements and stakeholder technical knowledge does not negate this.

Third, stakeholders may not yet know the business goals of the system. This may be driven by schedule (“We need to start coding now so that we will hit the deadline”), a misunderstanding of agile processes (“We will work it out as we go”) or a lack of preparation.

Architect/stakeholder inversion is usually solved by highlighting assumptions or providing alternate solutions. Forming these into questions (“Have we considered doing X instead of Y?”) and prototypes/spikes are effective. However, if software architects are on a “need to know” basis, stakeholders set direction solely by intuition instead of evidence or stakeholders take offence at challenges or questions, there may be wider organizational problems.

Architects and stakeholders should cooperate and respectfully challenge each other, providing greater understanding to both sides. Software architects can make better informed design decisions and glean insight into wider and future direction. The stakeholder can get a better understanding of and confidence in the solution.

That said, there are no sides here. Both the stakeholders and architects are working toward the same goal. If the organization has appointed stakeholders and architects, it realizes the value of each. Architect/stakeholder inversion contradicts this and produces a lower quality product.

Update: This post is featured in a discussion in the International Association of Software Architects (IASA) group on Linkedin.

%d bloggers like this: