Companies are constantly striving to be better with more innovation and profit. When identifying potential business issues, companies often focus on the big picture, looking at the business as a whole and slowly looking inward. In fact, starting out in the weeds with corporate technology can provide a much larger, more complete, and more detailed understanding of that larger picture.
As organizations move quickly in the wake of the pandemic and attempt digital transformation projects, with a high percentage unable to complete them, it’s crucial to understand how the decisions you’ve made with your technology will help or hinder the business. progress.
What exactly can we learn about a business from its technology?
The way teams are formed, interact and work together can have a profound impact on the final design of your product. We call it Conway’s Law – the structure of the software will inadvertently mirror the communication model of the team that built it. It can be argued that the organization of the business is the main factor to consider when designing a product.
organizational processes and architecture are intrinsically linked, that is, they influence and constrain each other. We need to keep this in mind when diagnosing any potential issues that arise and use this knowledge to gain key insights into how the business is structured, why issues arise and how we can combat them. If your engineering team is not meeting their goals, it can be helpful to assess how the team is organized and what it may mean to achieve the desired results.
Monolithic architecture vs microservices
There are several different architectural structures that can be produced depending on the organization of the teams. Small, distributed teams are more likely to produce a modular architecture based on microservices. If the team is larger and is not aligned with the components of the product architecture, they will likely create a monolithic architecture. The monolithic architecture is familiar to many, as traditional computer systems or business applications are often created this way. For both types of architecture, there are key advantages and disadvantages that should be considered.
For teams that have embarked on digital transformation projects, part of the job may be to put aside legacy monolithic applications in favor of new, modern microservices. This type of design has important strengths, as it allows greater flexibility to implement changes without disruption and may allow for better scalability. However, the monolithic architecture is much easier to implement and deploy. This often makes them the best choice for developing simple and small applications and is often found in early stage start-ups. Unlike microservices, the monolithic architecture is more difficult to scale because work has to align between different teams with different goals. Poor team structure can slow down the design process and lead to greater challenges down the line.
The successful or unsuccessful deployment of a microservices architecture by an organization reveals a lot about the decisions it has made and whether there are any deep-rooted issues with the organization’s communications structure. When determining whether to break a monolith and move to a microservices architecture, it’s important to make sure that your organization’s anatomy will support the architecture you choose to pursue.
Bloating of services
In some cases, it may be discovered that the number of microservices is greater than the number of engineers. This is called service bloat – which is problematic, as it will lead to decreased speed and uptime for developers. This is one of the main reasons why it is risky to build microservices without careful design and without making sure that the team structure supports this plan.
The bloating of services is an indication that a thoughtful architectural lens was not applied by the team – it shows that there is little knowledge about how each service depends on the other. This will often lead to microservices anti-models which will reduce availability and cause delays when trying to deploy new features. Ideally, no organization would want to find itself in this situation.
Realization of an architectural walk
Along with taking note of organizational anatomy and the impact this has on architecture, it’s also important to assess how everything is wired to identify the root causes of potential issues with your product. To do this, take a simple architectural walk. To take an architecture tour, you will need to examine how everything is wired from the device or application, down to the data level and back with the response. There are a few key things to keep in mind when leading an architectural walk:
- It is important to look for single points of failure, services that depend on each other at run time, and components that will not adapt to increased demand.
- Consider state – this involves analyzing where data is stored from session to session between users and how that data is kept.
- Keep an eye out for large databases that aren’t fragmented and calls made between regions in public cloud or self-hosted data centers.
- Look for Platform as a Service (PaaS) or Cloud Database as a Service (DBaaS) usage where public cloud failures create cross-region calls.
All of the above factors are just a few areas that should be considered when addressing any potential roadblocks with your product. The implementation schedule should take into account both functionality and architectural needs to achieve the best possible results.
What should senior product engineers know about this?
A goal for senior product engineering managers should be to ensure that scalability and availability planning and technical debt inventory take place on a regular basis to resolve potential issues before they occur. arise. A product architect or a small team of senior engineers should establish principles that product teams can use to design the right level of scale and high availability.
Tools such as CodeScene can be used to detect dependencies between services and help inventory the risks associated with code base behavior. The results help inform the backlog of refactoring needs and technical debt.
With the ever-changing needs of businesses to align with a rapidly growing tech industry, it’s vitally important to have a solid understanding of what your technology is disclosing about past decisions. These learnings can then be used to inform and prevent similar mistakes from happening in the future, as well as to help your organization learn how their team design can be used as a tool to achieve goals and achieve new ones. tops.
Dave Berardi, partner, AKF partners