Your very own third party service
Posted on Jan 19th, 2021

I often pretend that some parts of our platform are actually services provided by third party organisations. Doing so helps me draw borders between our products that have large overlaps. This way I also avoid irrelevant details and stay on the right level of abstraction while solving a design problem.

For example, say we are working on an educational network that offers services both to universities and students. We have two products. The first one is a marketplace of online courses. And the second one is a system for universities to process student applications. It is expected that students who complete an online course will be interested to continue their education by pursuing a degree.

Both products have concepts ofstudents,universities,courses,lecturersandtutors. However, these terms have a different meaning in each case. A course in the online learning portal is a single product to be purchased by a student. It contains all the relevant educational material. As for the university applications a "course" is just a title and a description of a course that a student is going to be taught as part of the degree.

example of a unified language

You can imagine how much more complication this can cause with hundreds related products within a platform. And I don't mean just database representation or classes diagram. Trying to cover everything within the same language affects designers, copywriters and even customer support. Think the reverse effect of the Conway's law. The one size fits all domain view makes internal communications more complicated.

Let's now imagine if these two products were built by two different companies: the University Applications Ltd and the Online Courses Ltd. Each of these companies would have much simpler worldview:

example of the divided approach

We can let each of the imaginary companies use their own language. As a result the terms scoped within a specific context will be cleaner and more straightforward.

Let's imagine that these companies have built two completely different web applications. Some time passes and University Applications Ltd acquires the Online Courses Ltd. Now they need to talk about an integration.

They quickly realise that the only integration that matters is that students can use the same accounts across the two products. University representatives managing online courses and application administrators are employed by different departments and are happy to use separate products - each suited for their own needs. A simple reporting tool will easily let analysts combine all data for a given university or student across both databases.

Mental experiments like this help me ensure that distinct parts of our platform always have one and only one duty. Just as theUnix philosophyteaches us: "Write programs that do one thing and do it well".

Do you have a question on this or maybe a different opinion?
Send me a private message
Do you want to know about new posts?
Follow me to receive updates
Latest publications
Jul 28th, 2021Growth by doingJun 19th, 2021The Systems LensMay 25th, 2021Research, Shaping, MakingFeb 25th, 2021Running a remote teamFeb 12th, 2021Low risk integrationsJan 19th, 2021Your very own third party serviceJan 8th, 2021The three types of work