• This article describes an approach to being an architect in IT organizations. It is a written statement, based on my experiences, on what it means to be an architect, how architects need to develop, and why architects should work together.
  • The article’s central message is that we need to develop architects as organizational superglue - people that hold architecture, technical details, business needs, and people together across an organization or complex projects.

With this article, I want to, based on my experiences, create a written statement on:

  • what it means to be an architect in an IT organization
  • how architects need to develop
  • how architects should work together

I consider the people the central and the essential part of architecture activities. Developing architecture as a discipline in an IT organization requires having competent, empowered, and motivated architects. In other words, Strong Architecture = Strong Architects.

Strong Architecture = Strong Architects.

In the next section, I elaborate on the role of individual architects. Then, I describe how I think we should develop architects. Lastly, I discuss the importance of creating a community of architects and describe expected architects’ activities in more detail.

1. Architects

In my view, architects in IT organizations should develop as “superglue.” I borrow this view from Adam Bar-Niv and Amir Shenhav from Intel. They pointed out that instead of the superhero, we need “super glue” architects - the fellows who hold architecture, technical details, business needs, and people together across a large organization or complex projects.

The superglue characteristics mean serving as the organizational connective tissue, linking the “business wheelhouse” and the “engine room.” Architects, of course, need to be technically strong. But their unique strengths should stem from being able to relate, or glue, technical issues with business and broader issues.

Architects, of course, need to be technically strong. But their unique strengths should stem from being able to relate technical issues with business and broader issues.

From discussions I’ve had with our technology leaders, engineers, architects, the picture below has crystallized as a representation of the “superglue” metaphor for architects (Figure 1).

Figure 1: Architects serve as a superglue, connecting development teams with business stakeholders while also linking their teams with the internal communities and the external world.

IT organizations need persons who look broader, linking architecture, technical details, business needs, and people together. These persons may not necessarily have a title of an architect. But they need to have good working relationships with developer teams and the local business stakeholders and functions. Simultaneously, such a person is well connected with the internal communities and has external visibility. They promote what we are doing, and on the other hand, they bring back the ideas from the outside.

2. Developing Architect as Superglue

Setting the architects’ goals to be “superglue” also requires some thought on developing as a superglue. Borrowing from Gregor Hohpe’s view on architect development from his book Software Architecture Elevator, I share the view that our architects should stand on three legs:

  • Skills
  • Impact
  • Thought leadership

Skills. Architects have to have proper skill sets. By skills, I mean possessing knowledge and the ability to apply relevant knowledge in practice. These skills should include both technical (e.g., cloud architecture or Kubernetes technology) as well as communication and influence skills.

Impact. Impact should be measured as a benefit for the business. Architects need to ensure that what they are doing profits the business. New architects start as students or trainees having skills but little impact. But sooner than later, fresh architects need to get out into the world and make an impact. Architects that do not make an impact do not have a place in a for-profit business.

Though leadership. Thought leadership acknowledges that experienced architects should do more than make architecture. This “more” can have different forms but should include at least some of the following activities: mentoring junior architects and engineers, publishing articles, giving talks, starting initiatives, and driving decisions.

Architects need to have minimal “length” of all of these “legs” to be successful. For instance, having skills and impact without leadership frequently leads to hitting a glass ceiling. Such architects plateau at an intermediate level and cannot lead the company to innovative or transformative solutions. Leadership without impact lacks foundation and may signal that you have become an ivory tower architect with a weak relation to reality.

In all scenarios, it is crucial for an organization that a senior architect mentors junior architects. Feedback cycles in (software) architecture are inherently slow. Mentoring can save new architects many years of learning by doing and making mistakes.

3. Gluing Together Superglue Architects in Strong Communites

Do not underestimate the power of building community and authentic relationships.

Architects are always a part of some team, where they may be the only architects. But they can and should collaborate globally with architects in other units. For instance, I work with a virtual team of architects. In this peer-to-peer community, we were collectively responsible for identifying and growing architectural talent, mentoring, and helping each other.

While the exact structure of communities may differ per organization and change over time, it is crucial to keep developing such groups as a vibrant, diverse community where they can leverage and build on each other’s work.

As a strong community, such a group can transform individual experiences into collective knowledge that can benefit the whole organization.

Figure 2: Architects work together as community of peers helping each other in their architectural activities.

4. Making An Impact

When we have strong architects and strong communities, we can do lots of impactful things. I classify the key activities that superglue architects could do into five categories:

  • Maximizing organizational learnings
  • Internalizing technology trends
  • Increasing transparency and bringing the data
  • Improving the quality of decision making
  • Facilitating alignment & decision making

3.1 Maximizing Organizational Learnings

” I expect you to learn to be better each day. I challenge you to look at each working day as an opportunity to learn more, and by doing so, to grow as a person.” – L. David Marquet

“Good judgment comes from experience, and experience comes from bad judgment.” – Fred Brooks

One of our primary daily tasks is learning. We need to discover new things about our domain, teams, new tools, and technologies. As individual architects, we need to use each day as an opportunity to learn something new. We need to maximize personal learnings, transforming individual lessons learned into shared guidelines.

One of the problems I frequently see in organizations, particularly complex and international ones, is that they may not have natural spaces for group knowledge sharing. Consequently, architects’ superglue attributes may uniquely position them to work together to create spaces for sharing knowledge about architecture and technology. These spaces include but are not limited to regular update calls, knowledge sharing sessions, or conferences.

In addition to creating spaces, as a community, we can further increase our learnings’ value by deriving generalized insights from cross-group cases.

I also believe that learning should also have an external component. We need to expose our knowledge externally. With external exposure, we promote what we are doing, and we get valuable external feedback. We need to look for opportunities to give talks, blog, or organize meetups.

“The world is moving so fast these days that the man who says it can’t be done is generally interrupted by someone doing it.” –Elbert Hubbard

Learning should not be only about our internal activities. We need to know what is going in the world and bring new ideas back home. One of the problems that many organizations face is that due to their complexity and size, they have more challenges in introducing new technologies compared to their disruptors (Figure 3). We have less time to understand and utilize new technology developments while the number of new technologies is increasing due to, e.g., continuous and accelerating evolution of cloud and mobile products.

As architects, we need to be proactive in the identification of relevant new technology developments. Based on our understanding of these developments, we need to create pragmatic technology recommendations for concrete platforms and across the organization.

Figure 3: One crucial aspect of Architects’ work is following external trends and finding pragmatic ways to introduce these trends in the organization. Credit:

3.3 Increasing Transparency and Bringing the Data

“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” -— Jim Barksdale

I genuinely believe that we should make our decision process as much as possible data-drive. Consequently, I see it as one of the most critical tasks to maintain high-quality data on relevant technology development, both internally and externally, providing fuel for data-driven decision-making.

One of the problems we face is that we have lots of data on technology, but they are not well connected, and manual data input and gathering are still frequent. For that reason, we need to work on developing automated tools that facilitate insights into technology and business.

In my recent positions, I’ve always aimed to get reliable data about technology with as much as possible automation. Some examples of tools I built and used include:

  • Source code contains an incredible amount of information about technology, people activity, team dependencies, and the quality of software systems. To get insights by pragmatic code analyses, I’ve started and still actively maintain the project Sokrates.
  • Public cloud usage reposts (e.g., billing reports), providing overview and trends on which team uses which services, regions, budgets.
  • Incident reports, looking at trends and dependencies among incidents.
  • Key business metrics, like the vibrancy.
  • Slack activity to understand team interactions.

I consider the data and transparency, together with architects, to be two main pillars of technology governance (Figure 4). Data and transparency provide a basis for data-informed decision-making. People enable governance to have an impact. Without these two strong pillars, the architecture becomes an abstract ivory tower exercise.

Figure 4: IT architecture relies on two pillars: transparency and community. Data and transparency provide a basis for data-informed decision-making. People enable governance to have an impact. Without these two strong pillars, the architecture becomes an abstract ivory tower exercise.

3.4 Improving Quality of Decision Making

“Most of the world will make decisions by either guessing or using their gut. They will be either lucky or wrong.” -– Suhail Doshi

We cannot centrally make all decisions. One-size-fits-all solutions do not work for everyone, and central decision-making does not scale. But we can at least make sure that the quality of decision-making is high.

In line with becoming more data-driven, we need to create shared frameworks to move from opinion-based decisions to data-driven economic risk modeling. Such frameworks should achieve the following:

  • dismantle the buzzwords, present the problem in clear terms, understandable to a broader audience
  • identify the real drivers behind buzzwords based on internal and external research
  • bring internal data and external trends
  • translate drivers into an economic risk model, and use the model to find the best spot for the given business context

In practice, I expect architects to be in continuous motion through organization layers and interact with diverse stakeholders (Figure 5). We need to work with business functions to define strategy, with other architects to define shared guiding principles, and with developers to ensure consistency among their practical decisions.

Figure 5: The daily work of an architect is in continuous motion. We need to work with management to define strategy, define guiding principles, and work with developers to ensure the consistency of practical decisions. Credit: Gregor Hophe.

3.5 Alignment & Decision Making

“Excessive complexity is nature’s punishment for organizations that are unable to make decisions.”
– Gregor Hohpe

In some cases, it makes perfect sense to make decisions together. We work on very similar issues but frequently reinvent the wheel. The goals of a community should be to prevent needled creativity to focus the work and creativity on making a difference for customers and business. In particular, architects must help align the organization on key strategic activities, e.g., cloud strategy, data strategy, or database technology choices.

4. Acknowledgments

Many people have provided feedback on the idea presented in this article. I would like to many of my colleagues who all provided helpful feedback on the early version of the “architects as superglue” concept.

5. To Probe Further

  1. The Software Architecture Elevator (2020), by Gregor Hohpe
  2. Can’t Find Superheroes to Help You Out of a Crisis? How About Some Architecture and Lots of Superglue? (2016), by Adam Bar-Niv (Intel), Amir Shenhav (Intel)