Building a Front End for a Complex Architecture: Strategies for Team Collaboration

In today’s fast-paced tech ecosystem, organizations often find themselves managing multiple teams with distinct responsibilities and specializations. At my organization, we have two primary teams: the Edge team, which focuses on machine learning and on-premises servers, and the Cloud team, which develops configurable front ends to visualize and interact with data generated by the Edge team’s applications. Recently, the Cloud team was tasked with building customer-facing front ends that allow users to configure elements of the Edge system. However, past attempts to bridge the Edge and Cloud divide have taught us valuable lessons about collaboration, ownership, and system architecture.

The Challenge: A Messy Collaboration

Our initial approach involved constructing a new microservice designed to facilitate communication between the Edge and Cloud systems. Both teams contributed to this microservice, resulting in a convoluted process where every change required coordination between both sides. When a modification was needed, the workflow would look something like this:

1. Edge: Update the edge system.
2. Edge-Cloud API: Adjust the API to accommodate changes.
3. Cloud: Modify the cloud-side services.
4. Frontend API: Update the frontend API.
5. Frontend: Finally, adjust the user interface.

This approach led to slow progress, excessive communication, unclear ownership, and ultimately, frustration for both teams. It became clear that we needed a more effective strategy to build customer-facing front ends without burdening either team unnecessarily.

Finding a Balanced Approach

1. Simplifying the API

One suggestion from the community was to redesign the Edge API to be data series agnostic. This means creating a versatile API that can handle a broad range of operations on various data series without the need for tightly coupled endpoints. For instance, instead of having specific endpoints for each data series, you could implement a single endpoint for querying available data series and others for point queries, searches, and aggregations. This method allows for future scalability and flexibility in how data can be accessed and manipulated.

2. Leveraging Established Tools

Given that the Edge team primarily deals with sensor data and machine learning, it might be beneficial to offload some of the data management to established tools. Publishing Edge data to a time series database and exposing that data via Prometheus can streamline the process. Internally, using Grafana can grant complete access to the data, while allowing the Cloud team to build a custom frontend that displays pre-defined PromQL queries for customers. By leveraging existing tools, we can avoid reinventing the wheel and focus on delivering value to our users.

3. Addressing Complexity with Experience

As one insightful comment pointed out, the front end (FE) will reflect the complexity of the underlying system. If the architecture is intricate, the front end will inevitably become complex as well. This situation is exacerbated when less experienced developers are involved. A solution lies in investing in skill development and ensuring that team members are well-versed in best practices for building complex front ends. Regular training and mentorship can help bridge the gap and create a more competent team.

4. Vertical Team Ownership

Another compelling strategy is to assign each team ownership over different sections of the front end. This approach helps maintain separation and clarity of responsibility, allowing teams to work more independently. For example, the Cloud team could focus on the user interface while the Edge team manages the backend functionalities. This separation can foster a sense of ownership and accountability while minimizing interdependencies.

5. Considering Micro-Frontends

Finally, while it might be overkill for two teams, exploring a micro-frontend architecture could be beneficial. In a micro-frontend setup, each team develops a specific section of the frontend independently, allowing for better scalability and team autonomy. This structure can facilitate faster development cycles and easier maintenance, as each team can iterate on their section without being hindered by changes in other parts of the application.

Conclusion: A Path Forward

Building a customer-facing front end for a complex architecture involving multiple teams is undoubtedly a challenging endeavor. However, by simplifying APIs, leveraging established tools, investing in team experience, maintaining clear ownership, and considering micro-frontend architectures, we can create a more efficient and collaborative development environment. As we move forward, these strategies will not only enhance our workflow but also ensure that we deliver intuitive and user-friendly experiences for our customers.

In the ever-evolving landscape of technology, adopting a proactive and flexible approach will be key to our success. Collaboration, communication, and continuous improvement will guide us as we build the next generation of customer-facing applications that bridge the Edge and Cloud divide effectively.