Skip to main content

What does your tech say about your organization?

communication technology
(Image credit: Image source: Shutterstock/violetkaipa)

Businesses are constantly striving to be better with more innovation and profit. When identifying potential business problems, companies will often focus on the bigger picture, looking at the company as a whole and slowly looking inwards. In reality, starting down in the weeds with the company’s technology can offer a much wider, comprehensive and more detailed understanding of that bigger picture. 

With organizations rapidly evolving in the wake of the pandemic and attempting digital transformation projects, with a high percentage unable to complete them successfully, it is crucial to have an understanding of how decisions that you have made with your technology, will aid or hinder progress.

What exactly can we learn about a company from their technology? 

How teams are assembled, interact and work together can have a profound impact on the final design of your product. We refer to this as Conway's Law - the structure of software (opens in new tab) will inadvertently mirror the communication model of the team that built it. Arguably, the organization of the company is the principal factor to consider when designing a product. 

organizational processes and architecture are intrinsically linked - meaning that they affect and constrain each other. We must keep this in mind when diagnosing any potential issues that arise and use that knowledge to gain key insights into how the company is structured, why problems are cropping up and how we can combat them. If your engineering team is not reaching their objectives, it may be worth assessing how the team is arranged and what this might mean for achieving the desired outcomes.

Monolithic vs microservices architecture 

There are several different architecture structures that can be produced depending on how teams are organized. Small, distributed teams are more likely to produce modular, microservices-based architecture. If the team is larger and not aligned with components of the product architecture, they will likely create monolithic architecture. Monolithic architecture is familiar to many, as traditional IT systems or business applications are often created this way. For both types of architecture, there are key advantages and disadvantages that must be taken into account. 

For teams that have set out on digital transformation projects, part of the task might be setting aside legacy, monolithic applications in favor of new, modern microservices. There are significant strengths to this type of design, as it allows greater flexibility to implement changes without disruption and can enable better scalability. However, monolithic architecture is much easier to implement and deploy. This often makes it the best choice for small, simple app development and is often found in early-stage start-ups. In contrast to microservices, monolithic architecture is more difficult to scale because the work needs to align between different teams with various objectives. Getting the team structure wrong might slow the design process down and cause greater challenges down the line.

An organization's successful, or unsuccessful deployment of microservices architecture reveals a great deal about the decisions they have made, and if there are any deep-rooted issues with the communications structure in the organization. When considering if you need to break up a monolith and move to microservices architecture, it is important to make sure that the anatomy of your organization will support whichever architecture you choose to pursue. 

Service bloat  

In some cases, it might be uncovered that the number of microservices is greater than the number of engineers. This is called service bloat - which is problematic, because it will result in decreased developer velocity and availability. This is a key reason why it is risky to create microservices without careful design and ensuring the team structure supports this plan. 

Service bloat is an indication that a thoughtful architectural lens has not been applied by the team - it shows that there is little knowledge of how each service depends on the other. This will often result in microservices anti-patterns which will lower availability and cause delays when attempting to roll out new features. Ideally, no organization would like to end up in this situation.

Conducting an architecture walk

In addition to taking note of the organizational anatomy and the impact that this has on architecture, it is also important to assess how everything is wired to identify root causes of potential issues with your product. To do this, conduct a simple architecture walk. To carry out an architecture walk, you will need to examine how everything is wired from the device or application, all the way to the data tier and back with the response. There are a few key things to keep in mind when conducting an architecture walk:

  • It is important to look for single points of failure, services that are dependent on each other at run time and components that will not scale with increased demand. 
  • Consider statefulness – this involves analyzing where data is stored from session to session between users and how that data is maintained.
  • Keep an eye out for large databases that are not sharded, and calls being made across regions as part of a public cloud (opens in new tab) or self-hosted data centers.
  • Look for use of platform as a service (PaaS) or cloud database as a service (DBaaS) where public cloud failures create cross-region calls.

All the factors above are just some areas that should be considered for remediation of any potential roadblocks with your product. The timing to implement should take into consideration both features and architecture needs for best possible results. 

What do senior product engineers need to know about this? 

A focus for senior product engineering leaders should be to ensure scalability and availability planning and technical debt inventorying is occurring on a regular basis to troubleshoot potential problems before they pop up. A product architect or a small team of senior engineers should establish principles that product teams can use to design for the right level of scale and high availability.

Tools like CodeScene can be used to detect dependencies across services and help to inventory risks in how the codebase behaves. The results help to inform the backlog of refactoring needs and technical debt.

With the needs of businesses constantly evolving to align with a rapidly growing tech sector – it is critically important to have a solid understanding of what your technology divulges about past decisions. These learnings can then be used to inform and prevent similar mistakes from occurring in the future, as well as help your organization learn how their team design can be used as a tool to help meet objectives and reach new heights.

Dave Berardi, Partner, AKF Partners (opens in new tab)

Dave Berardi, Partner, AKF Partners.