Self Contained Systems Part 7 — Web Components

Don’t miss the other posts in the series:

• Part 1 — An architecture for scaling dev organizations.
• Part 2 — Data Follows UI
• Part 3 — Data Replication
• Part 4 — Data SLAs
• Part 5 — Ownership of Writes
• Part 6 — Data Tricks

Splitting your system into nice neat vertical slices is great in theory but in the real world it can be messy. Often you will find you need to build several discrete UIs that cut across your system. A great example is you build an app for your customers and you build a different app so your operations team that can help aide your customers. The optimal user interface generally involves a different user experience per persona.

In a perfect world of self contained systems (SCS) you would see one SCS owning the write of a piece of data with multiple SCS being able to present a read-only view of that data. If you have multiple UIs that need to mutate a piece of data then how are you going to meet this ideal?

Unfortunately the front end doesn’t end up as clean as the backend does, but we will talk about a way to use web components to get as close as we can to the ideal.

It is tempting to split your system up by personas and the applications that they use. In this workflow Team A works on the customer facing app and Team B works on the app that the ops people will use.

In the fifth article in this series Ownership of Writes we presented a system with three vertical slices: Scheduling, Dispatching, and Fulfillment. In our customer facing app and our ops facing app we will most likely want to participate in creating and updating all three concepts. Instead of having each team own an app, we are going to have each SCS create the UI for all personas that need access to their business concept. We are going to do that by producing web components instead of writing entire apps.

Web Frameworks

There are two main models of web app consumption. Some people are writing web apps where you are fighting to convince the user to return to your site. A lot of Software-As-A-Service (SAAS) apps fall into this category including mega-sites like Facebook. The user has a million other things they could do and you have to have a compelling reason for them to choose to spend time on your app.

The second model is where your users have no choice but to use your web app. Many internal company apps fall into this category. Your fellow employees have to use your app for booking a trip if they want to remain employed. Many times these employees have to spend a good part of their day in your app.

In the first case small page load times is crucial every time. Your user is one excuse away from leaving you at any given time. Besides having too many tracking frameworks running, nothing kills page load times like downloading a new version of your Javascript framework. You will want to mandate rules around how often you update your major components/frameworks. If your users come to your site every day, then maybe you can bump the versions every Tuesday. If your users come once a week, then maybe you bump your versions no more often than once a month.

In the second case where there are long sessions you can be forgiven for a much slower load time once every day or so. In this case you might want to set a more aggressive upgrade cycle.

Components

Your web app choice may influence the way you structure your web components. That is fine, we aren’t going to talk about the implementation so much as talk about what our goals in creating them are. It is even possible to create generic components that will work across multiple web frameworks but again, implementation details we aren’t concerned with right now.

The purpose of these components is for the SCS that owns the write of certain data to provide the UI for mutating that data. It is easy for SCSs to provide read-only views of data that originated at another SCS (because of data replication) but having multiple SCS mutate the same data can be messy. By assigning write access to one SCS and then having that SCS provide a UI component for each place that data is mutated on the UI is one way to address this problem.

Unfortunately this isn’t the only way to solve this problem. There will be cases where calling an API on another SCS (perfectly valid) is the better choice. This may come in the form of a list of data that contains mostly data from one SCS but one piece of data from a different SCS. In that case you really have one save action on the front end and you will call an API for the other SCS in the backend.

Components should use semantic versioning so that consumers can make rational decisions about when it makes sense to upgrade their components. You will want to come up with a deprecation strategy because of the overhead of managing too many component versions at the same time.

Applications

Now that we have disassociated applications from single team ownership we are going to have to assign them to someone. This decision will really depend on how many components you integrate into your apps. If your applications end up mostly around one SCS then that SCS should own it and consume the occasional component from other SCSs.

If your a large portion of your application is made up of components then you need to choose a stewardship team that is going to manage common components (e.i. navigation, footers, etc) and coordinate component version bumps. You will also want to assign some type of quality process to make sure all the components adhere to the design ideals you have set. There is nothing worse than a rogue component taking up the wrong amount of screen real estate and ruining the UX of you application. You can create an integration team to handle several applications or you can treat this like an additional duty for an existing team.

Conclusion

SCS so far has been about giving teams as much autonomy as possible so your organization can grow while staying nimble and responsive. The UI presents certain challenges because of the need to provide a uniform presentation for your users benefits while minimizing the amount of data that needs to be downloaded. By using web components you can have teams realize the ideal of vertical stacks while still addressing some challenges unique to the front end.

Continue Reading in Part 8— Events