Debunking the monolithic build

It is now common knowledge. Imaging is dead and ‘Automated Device Enrolment’ is king. Gone are the days of monolithic device images with every application and device setting (even the kitchen sink) thrown into one image. 

Why then is the monolithic approach still the most prevalent when it comes to device deployment design? In this blog post, I will be debunking the monolithic build. 

What is a monolithic build?

The monolithic build approach is still undertaken by many organisations, even when a device follows a ‘zero touch’ enrolment via automated device enrolment. However, once the device is enrolled into the fleet’s MDM (Mobile Device Management), a tightly specified monolithic build begins to deploy to the recently enrolled device. 

This build may contain everything the end user will ever need on their device, from four different browsers to two different FTP clients – even every font available on Google – this build has all the system settings required for all departments. Some organisations might even split these monolithic builds into several different roles, duplicating these large builds. These roles will still have the same system settings deployed, but might include one or two different applications as per the needs of the role in question. 

The single monolithic image has now been replaced by an equally prescriptive monolithic configuration.

Debunking the approach

While monolithic builds (and previously, images) once had a firm place in the world of device management, a more effective approach is to simplify the device build entirely. The old approach would have involved an IT department receiving your shiny, new Apple device, unboxing it straightaway (ruining the fun of that ‘new device smell’ experience) and proceeding to set up your device for you. In this scenario, the monolithic build approach would benefit most IT teams, as they are the experts and can ensure the device passes the required tests to confirm it is operating to the company’s required specifications. 

With the move to ‘remote first’, I am a firm believer the monolithic build approach should be well and truly dead. The new method of remote first changes the requirements of device building; even if an employee is not remote and is predominantly in the office, the same approach should still be followed. Keeping the device builds as linear as possible not only reduces the build time, it also allows for little error when shipping new devices around the world. 

It is also worth noting that, while most corporate networks have the luxury of a fast internet connection, the majority of users working from home do not. Using a simplified build alleviates home users’ internet speed causing a problem.

Other benefits 

There are a wide variety of other benefits of not running a monolithic build. I have listed some below:

• easier to maintain/manage
• easier for junior engineers to help and assist
• encourages end users to find and interact with the system to get the required software
• easier to document the on-boarding process for new devices/builds
• fluid on-boarding process that can easily be changed/updated
• fewer dependencies
• improved licensing control of paid-for apps
• less tech debt
• fewer bespoke systems

What is the ‘correct’ approach?

The argument put forward in this article for the correct approach when designing/updating your device build, is to take a simplistic look at what is actually needed to be deployed during setup, then enable and seed control to the user, within a well–managed framework. Ironically, this is more a managerial challenge to solve than a technical one – but this is where Apple device management has been heading in recent years, has it not?

Ask yourself, what are the bare minimum requirements this device has in order for an employee to be able to work with it functionally?

My advice here would always be to contact departmental heads and check if that ‘vital’ piece of software is still required. You might be shocked to discover this title is no longer in use and has been clogging up useful disk space and build time across your fleet. A simplified build should only contain the required security/restrictions, plus the main Apple applications (such as Safari), accompanied by any security software and/or VPN. If your company’s policy is to use Chrome as a web browser, then of course it can be added to your build. However, requesting to have two other additional web browsers installed as well as Chrome would be overkill and does not serve to benefit the institution or the user.

This approach works by adding all the non-essential software to your MDM’s Self-Service application. This can vary depending on your installation and configuration. For example, if you are using MDM with Munki, you would need to ensure Munki has all of the software in the Managed Software Centre for the end user to find. For datajar.mobi/Jamf/Mosyle users, add all the additional software to Self Service. This helps to create a great user experience as the end user does not end up with a device full of software they may not even use and/or ever benefit from. However, if they require a piece of software, they can request this to be placed in the Self Service/Managed Software Centre apps. Everyone benefits from this approach. 

Below is a diagram showing some of the differences between a monolithic and simplistic build:

The benefits of the simplified build

While a simplified build might not work for everyone all the time (an example of this might be in education and school labs), the approach should still be considered and widely used. A monolithic approach to software engineering no longer has a place when it comes to Mac management in 2022. It will not scale with your department’s needs or the needs of your end users. Monolithic builds tend to be complex beings, which grow to be over-complicated as they are passed down from engineer to engineer without ever being questioned; this approach then just becomes the norm. To avoid inheriting these kinds of issues, never be afraid to challenge what you have in place, no matter how tried and tested it may be. 

What makes us great is our ability to evolve and learn, so why should your enrolment builds not do the same?