Application vs Platform Teams

Every time I split an engineering team into a 'platform' team and an 'application' team, I swear it will be the last. But time and time again, I end up repeating the same pattern. What are application and platform teams? Why do they tend to create organizational nightmares? What makes them irresistible to architects? Find out in today's article!

Let's start by defining "platform" and "application" (at least how I will use them in this article¹). Often, when computer engineers think about platforms, we think about Operating Systems – general-purpose subsystems that provide application developers with some abstraction from the lower layers (eg. the hardware), resource management (e.g. memory and time-slicing), and common services (e.g. storage and graphic APIs). Over the years, other general-purpose platforms have been developed higher up in the stack: development platforms (like .NET and Java) and Cloud services platforms (like Google Cloud, AWS, and Azure), etc. 

But many/most engineering teams of a certain size develop their own 'platforms' for internal or limited customer use-cases. These platforms have the same fundamental properties as general-purpose platforms. That is, they usually provide some abstraction over lower layers, provide some sort of resource management, and provide a common set of services for application developers. Applications, in contrast, are built on top of platforms to perform a specific function for the user/customer (Think MS Paint, Twitter, or Mint). 

My first professional experience with the challenging dynamics that can occur when you have an application and platform team occurred at Quack.com. Quack developed a voice portal infrastructure capable of hosting "sites" that allowed users to complete transactions and access information services, including movie listings, news, weather, and email. By the time Quack was purchased by Americal Online, there was only one site, AOLByPhone - but we were divided into separate application and platform teams that sat in opposite wings of the building (and blamed each other when anything went wrong). 

According to the platform team, the application team was where engineers that couldn't do 'real' development went. We believed that if the app developers just used the platform as intended, everything would be just fine. Instead, they kept trying to hack around things and created a huge mess. Of course, if you asked the application team, they would tell you that the platform was an unstable and unusable monstrosity, and their lives would be so much better if they didn't have to use it. Not exactly a healthy relationship².

In last week's article, I alluded to another similar dynamic that arose during the development of the Operating System Deployment (OSD) feature in Systems Management Server 2007. In that case, the developers were split into a task sequencing team (responsible for building the basic 'platform' that would orchestrate tasks throughout the re-imaging process) and an OSD team³ (responsible for developing the OS deployment-specific actions). Each team reported through a separate management chain, had its own team meetings, and generally operated independently⁴. The results were pretty bad: teams blamed each other for mistakes, re-wrote each other's code, and had more than one spec review devolve into a shouting match.  

So if application and platform teams have such dysfunctional tendencies, why do I (and most other architects) continue to split responsibility this way? Are we all sadistic jerks that take delight in the suffering of others? Well, maybe. But there is also a method to our madness. When carefully managed, separating an architecture into a platform and application team can create healthy tension. 

Consider what happens when we don't do this. Suppose you start with just a single 'application' team tasked with solving a specific problem (say Operating System deployment). You end up with just that – an application that solves a specific problem (like the SMS 2003 OS Deployment Feature Pack). Even when the team sets out with the best intentions to isolate reusable 'platform' pieces of the application – shortcuts get taken (due to schedule pressure, lack of foresight, or simply laziness). The platform tends to lose its general purposeness. Likewise, trying to build a platform first (without the aid of an application team to feed in requirements, challenge assumptions, and apply schedule pressure) is equally as fraught with changes. Like it or not, we usually end up coding our org structure – so architects use this to our advantage. Creating two teams with separate charters (one focused on making a general-purpose platform and the other using the platform to solve a specific problem) is the only way I have found to ensure a balance.

So how can we avoid having the teams devolve into a dysfunctional mess? I have found the following works pretty well:

• Shared goals and milestones - While both the platform and the application team should have their own goals, it is essential to have a set of shared goals and joint milestones where the teams present their progress together. Asking the teams to present jointly helps ensure that management understands the benefits of both components and builds a sense of 'team.'
• Frequent Integrations - Carefully crafting 'steel thread' scenarios to ensure early and regular app/plat integrations helps minimize misunderstandings between the teams. I have found that Integration Days, which I talked about in an article a few weeks ago, are an effective and fun way to do this. 
• Sit Together - It is generally best to seat the teams together (e.g. in neighbouring team rooms). When not possible, it is crucial to at least create a virtual sense of closeness by holding frequent cross-team engineering syncs and creating cross-team 'tiger' teams to tackle shared problems.
• Have Platform responsible for a slice of the app - I find giving the platform team a small part of the application (built on top of the platform) helps build empathy and helps the platform 'share the pain' when something goes wrong lower down in the stack. It also helps give the platform team a testbed and something that they can demo that is consumable by management.

Using one or more of these approaches helps quell the worst dysfunction cases while still producing a good platform. However, it is still critical to closely monitor the team's temperature and make adjustments along the way. 

Have you ever been on a platform team where the application folks kept messing things up? Ever been on an application team building an unstable mess of a platform? Have you experienced a healthy app/plat relationship? Comment below!

Be Happy!

Like this post?  Please consider sharing, checking out my other articles, and subscribing to my weekly Flegg’s Follies newsletter for more articles on software engineering and careers in tech.

Footnotes

1. The line between “application” and “platform” is incredibly blurry in practice. For example, what is Microsoft Word? At first glance, it appears to be a textbook application used by people who have not yet discovered how much better Google Docs is. But you are probably still using MS Word at work because many companies have built whole workflow processes on top of it. Microsoft Office is so sticky because it is a platform, not just an application.  
2. Bear in mind that this was about 25 years ago, and my memory of the whole thing is pretty blurry. I could be remembering this whole thing wrong – I don’t want to reignite any feuds between former Quackers.
3. Later on, the team also took on responsibilities for asset inventory and software metering and was renamed the OSD and Inventory/Metering Team (osdamit@microsoft.com) – not quite as much geek cred as the  SMS Code Reduction and Pruning team – but pretty close.
4. To this day, you will find you have both an osdcore.dll and tscore.dll file in your CCM directory – remnants of a long-forgotten disagreement over how to structure our shared libraries.

Please note that the opinions stated here are my own, not those of my company.