Design Orientation and Optimization

Much has been written about vertical and horizontal optimization over the years in software engineering, where vertical typically represents depth of functionality in a domain use-case and horizontal represents either common domain functions or foundational technical features. This optimization sits at the intersection of technical architecture, development methodology, and organizational design. Approaches for optimizing the technical axis are often described with combinations of terms such as “services,” “data,” “mesh,” architecture,” and “micro,” to name a few. Conversations on the development methodology & organization axis could include “tribe,” “guild,” “squad,” “chapter,” “team,” “autonomous,” and “lean.” Irrespective of what labels are being applied, the fundamental question being raised is how to concurrently maximize output on both axes. The answer is that first, this is a hard problem. Second, don’t let anyone tell you different.

Autonomous Is The New Silo

Having a team be “autonomous” is a popular organizational concept and is frequently paired with the phrase “self-directed” in terms of requirements and goal setting. The intent behind having an autonomous team is to minimize external dependencies and potential progress blockers, and this is an admirable goal. The very definition of an “autonomous team” implies that every minute spent thinking outside the team’s priorities is a minute wasted; otherwise, it wouldn’t be an autonomous team. Consequently, an autonomous team tends to be vertically oriented, having strictly defined stakeholders and use-cases. There is another term for this structure: a silo. Enthusiasts of autonomous teams might not appreciate the comparison, but it’s true—and it’s not inherently a bad thing, as each team is charging towards an identified and documented goal.

The logical extreme of multiple fully autonomous teams within a single organization isn’t pretty, however, as the consequence of letting each team select their own cloud provider, development languages, source code framework, build frameworks, storage frameworks, process scheduling frameworks, monitoring frameworks, security approaches and governance, etc., on top of removing any internal dependencies (read: potentially re-solving problems another team has already solved), could result in a highly fragmented environment with inconsistent handling of core issues. Each team would be “enabled” in one sense—so that is a benefit—but at a high potential cost of portfolio cohesion. A more pragmatic approach for efficiency and sanity would argue for some commonality of horizontal components and technical consistency. But how much commonality is enough? How much to silo?

A Look Back At Matrix And Conway

These questions should all sound familiar because as an industry we have been here before. Quite a few times, in fact. Matrix Management started in the 1950s and really took off in the 1970s (Digital Equipment Corporation was apparently a proponent). Matrix management was supposed to break down silos by creating an org-chart with multiple lines of reporting with the goals being improved inter-team communication and collaboration. Again, admirable goals. Management is essentially one person saying to another,”I need you to complete this task.” The problem is that Matrix Management is another person asking you to do something else on top of that. Hopefully the additional task aligns with the primary responsibility, but this is not guaranteed. The worst case is not only having resource and timing misalignment, but in being assigned a secondary task that fundamentally is in conflict with the primary task. Who resolves this conflict? It is tempting to suggest “yet another manager” as the answer, but in Matrix Management, it may not be that simple, as complex topics may require several layers of discussions and escalations to resolve a thorny topic.

Organizational structure and governance is clearly important for determining collective priorities, but its effect on resulting software deliverables can go even further. Conway’s Law is an adage dating from the 1960s which states that organizations design systems that mirror their own communication structure. This might initially seem like an admonition or a warning, but there are practical reasons why this mirroring happens. People on the same team, generally speaking, will converge on the same answers for aforementioned topics such as development languages, source code frameworks, storage frameworks, etc., out of necessity because it is exhausting to re-debate these topics from release to release and project to project with co-workers. Conway’s Law is describing an optimization strategy, and the effects of either full- or semi-autonomous teams decades before the term became fashionable. For any given team’s perspective, the natural emphasis is necessarily to prioritize vertical (intra-team) over horizontal (inter-team) interactions.

Vertical First, Then Horizontal

Thus, the two poles are vertical optimization (team & functional use-case oriented) and horizontal optimization (global and aiming for inter-team consistency). The former can provide benefits for any single team at the cost of cohesion for an organization. The latter aims for 100% consistency for an organization at the likely cost of flexibility and responsiveness. As with so many things in life, the sweet spot is probably somewhere in the middle with case-by-case trade-offs, and this requires both functional and technical leadership. This is not easy, even if magic words like “squad,” “tribe,” and “mesh” are applied.

At least from my personal experience, prioritizing the vertical first, then looking for horizontal opportunities, makes for the most pragmatic approach for developing solutions within an organization’s portfolio. While this is an article about software development, physical products tend to make this point more plain: understanding the vertical is the difference between understanding the general need for a “vehicle” vs. the need for a specific need for a sedan, truck, or tank. Each has a purpose, but they aren’t the same thing, and supporting one feature typically means not being able to support something else, or at least not very well. It’s hard enough to design for one of those cases well, much less wildly inefficient combinations or inappropriate variants, such as an 18-wheel-sedan-truck or a sedan-tank hybrid, respectively.

A cautionary real-life physical-object use-case for horizontal optimization is the F-35 joint strike fighter. Designed to replace at least four different planes (F-16, A-10, F-18, and Harrier) its requirements included both vertical take-off and landing, as well as supersonic flight, and no shortage of other requirements. This took a couple decades of development and cost at least a trillion U.S. dollars by most estimates. While the F-35 is undoubtedly advanced, most software projects don’t have this kind of runway in terms of time and money for product development under the banner ‘internal technical consistency.’ There is some small irony that the F-35 was delivered with three variants (only one of which utilized vertical take-off), and I would hazard a guess that most software engineers have experienced a conceptually similar situation where a feature initially described as “everybody needs” wound up being an expensive special case.

Lastly, horizontal functions do matter, but should validated by multiple vertical use-cases. There is no point in building a horizontal service without a user. Although most horizontal services may wind up being “internal,” they are still effectively products in their own right and should be staffed accordingly, and need their own development roadmap, release, and support functions.

 

Doug Meil is a software architect in healthcare data management and analytics. He also founded the Cleveland Big Data Meetup in 2010. More of his BLOG@CACM posts can be found at https://www.linkedin.com/pulse/publications-doug-meil