On October 3rd and 4th, 2022, Apiumhub organized the Global Software Architecture Summit, an event that reunited over 460 professionals to learn about software architecture metrics. In addition to talks from industry experts, GSAS also featured hands-on workshops where speakers introduced a few topics for discussion. GSAS workshops were useful for debating, brainstorming ideas, and developing solutions.

I had the opportunity to attend the workshop “Become a Software Design Company,” which was presented by Michael Keeling, software engineer at Kiavi, and George Fairbanks, software engineer at Google. The latter had to present remotely since he could not attend the conference. They wanted to demonstrate to us how they could effectively implement significant changes in their businesses so that we could use the lessons learned to improve our own experiences.

Once upon a time…

In the GSAS workshop, Keeling and Fairbanks explained that they had delivered a completely new service to their customers with success in a relatively short period of time. They were able to manage that change because previously they had learned that software design was a central part of how they developed software. All the members of the team were aligned with that mantra.

But to reach that point, they had to overcome some challenges, because the idea of having a team that is knowledgeable in everything is ideal but far from the truth. There are always so many things to overcome:

• Missing skills
• Knowledge gaps
• Focus on features
• Short-term thinking
• Crushed by tech debt
• Fear, uncertainty, doubt

These are undoubtedly well-known problems that any organization may encounter, and we must understand how to handle them. They achieved this by learning how to use various tools , thinking about distinct ways to move forward, and bit by bit having a better crew doing some exercises like, for example:

• Whiteboard jams
• Architecture gardens
• Example mapping
• Concise, comprehensive design docs
• Discussed design during code review
• Architecture Decision Records (ADRs)
• Architectural guide rails
• APIs as contracts
• Test for design rules

In a nutshell, software design companies put design at the center of their software practice.

What happens when you don’t think about design?

When writing any software, if you don’t think about the design (which in the end is another “type” of design), you will face problems sooner or later. Writing software should be more than just throwing lines into our IDE because, in the short term, you’ll find so many problems such as:

• Feature treadmills, rarely (or never) pause for design
• Quickly produce lots of features
• New features “bolted on”
• Architecture might or might not be a good fit
• Technical debt increases
• Over time development slows
• Some new features are infeasible to add
• Rewrite is the only option

Premise

To become a software design company, developers must grow their software design skills.

IMEO Framework

Having that premise in mind, they presented how to reach that point and how to make everyone sufficiently knowledgeable: using the IMEO Framework. It is a planning tool for helping figure out how to spread software design ideas throughout an organization. It’s divided into 4 parts, which can be followed in any order:

Idea

Invisible knowledge or skills. What are the abilities we want to share? For example, knowledge about patterns, object-oriented or functional paradigms, and domain modeling.

Medium

A visible activity or artifact that spreads an idea. How will we share the idea? Examples: design reviews, code reviews, architecture docs, ADRs, training, risk storming, book clubs, internal blogs, pair programming, and sonnarQ.

Entry Point

The initial target audience within the organization for a design idea. Who is going to be the first to try it? Examples: tech leads, suffering teams, new hires, individuals.

Obstacles

Impediments that might prevent an idea from spreading in a given medium. Which are the possible difficulties we’ll find while sharing the idea? Examples: egos, organizational chunks, lack of mentors…

In summary, for any new design idea, select a medium, identify an entry point, and remove obstacles that prevent or slow adoption. Persistence. Repeat as many times as many ideas to be spread.

One example

A squad decides to start writing ADRs (architecture decision records) that help to keep track of the architectural decisions next to the code, so they are aware of all the changes through time.

But of course, they are going to face unnamed obstacles like :

• Obstacle 1: Design undervalued – “I just want to write code!”

  • Approach: Tap a “first mate” Set team policy

• Obstacle 2: Missing skills – architecture decisions, how to write an ADR

  • Approach: Coaching through Pull Requests

• Obstacle 3: Schedule pressure – “We don’t have time to write docs”

  • Approach: Tech Lead: “ADRs are short. Let’s try an experiment.”

So in the beginning, the entry point is the tech lead of a pilot team, and he is the only one who writes ADRs. Once the format is defined, the teaching lead chooses a member of the squad who starts writing ADRs with his help, which may be through pairing or via reviews in a pull request. From here, the knowledge is spread to all the members of the company, who start writing the documentation records. Of course, they need to have persistence in order to keep the practice going. In the long term, everyone has incorporated the habit, and now anyone can write an ADR to document every architectural change in the project.

Our GSAS Workshop

In small groups, we were talking during the GSAS workshop about general issues we had in our own projects, and how we could apply the IMEO framework and have at least one actionable plan for introducing important design ideas into your organization. In our group, we came up with:

• Idea: We wanted to apply good practices among all the members of the team.
• Medium: Usage of activities to spread this knowledge could be done with frequent pair/mob programming explaining how to write code with testing, applying patterns…
• Entry point: the less experienced members of the squad.
• Obstacles: Egos may be a problem to be faced when showing people how to do things in a different way than they are used to. Time is always a constraint, but it’s an important investment for the whole project.

Conclusion learned from GSAS Workshop

The IMEO framework defines specific points for how an idea can be spread through the team. It asks for some time to think about a problem and to check for real solutions, the ones that can be applied from the very beginning.

The framework is made of a few simple points that won’t help you by themselves unless you put the outputs into practice, but it gives particular guidelines that may help the team’s growth. Give it a try!

This year’s edition of GSAS will take place on October 9, 10, and 11 at the Axa Auditorium in Barcelona. Get your ticket hereto enjoy two full days of talks from industry experts and an extra day of hands-on workshops.