Image by Gerd Altmann from Pixabay

KEY POINTS:

  • This playbook described an approach to running an an IT architecture practice in larger organizations.
  • I called this approach "Grounded Architecture," highlighting the need for any IT architecture function to stay well-connected to all levels of an organization and led by data.
  • In this section, I summarize the key points from the playbook.

In this playbook, I explained an approach to running an architecture practice in larger organizations. I called this approach “grounded architecture,” highlighting the need for any architecture function to stay well-connected to all levels of an organization and led by data.

Grounded Architecture has two main parts:

  • Structure, defining elements you need to have to run Grounded Architecture practice, and
  • Reflections, a set of my considerations and guiding principles that can help put the ideas of Grounded Architecture into practice.

The following figure illustrates the structure of the Grounded Architecture consisting of three elements:

  • The Data Pillar,
  • The People Pillar,
  • The Architecture Activities Platform.

The Data Pillar ensures that architects can make data-informed decisions based on a real-time and complete overview of the organization’s technology landscape.

The People Pillar is another essential element of Grounded Architecture. A strong network of people doing architecture across the organization is crucial to ensure that architecture function has any tangible impact.

Lastly, the Architecture Activities Platform leverages data and people to create a data-informed, deep, and broad impact.

The following reflections provide some ideas and key lessons I learned while developing ideas of Grounded Architecture in practice:

When Grounded Architecture is in place, it can have a significant positive impact on the functioning of an organization:

  • Enable Execution of Architecture Function At Scale,
  • Increase the Quality of Decision-Making with Data,
  • Maximize Organizational Alignment,
  • Maximize Organizational Learning, and
  • Increase Architecture Function Adaptivity.

Remember that while you may borrow ideas from others, every organization is different in the end, and your approach must adapt to your context. When forming architecture functions, I always advise not to forget these two pieces of advice from Gregor Hohpe:

  • Your architecture team’s job is to solve your biggest problems. The best setup is the one that allows it to accomplish that.
  • Your organization has to earn its way to an effective architecture function. You can’t just plug some architects into the current mess and expect it to solve all your problems.
Reflections
← Rising The Bar: Architects' Career Paths
To Probe Further
Bookshelf →