Monolith means “one stone”. That sounds like something old, something that takes a long time to build. When talking about organisations, we consider monoliths as large corporate structures we regard as indivisible and slow to change. That same definition applies to software, whether we are building it, or simply using it.
Successful organizations and businesses run due to good connections, but not just in regards to connecting a customer with a product. It’s commonly agreed nowadays that in order to be successful, a business needs to include cohesive departments via engaged cross-functional teams, filled with uniquely skilled individuals. Thus creating a culture, which surpasses process; is adaptable, agile, flexible and most importantly, independent.
By leveraging as well as building micro-service orientated software rather than monolithic applications, we can build a collaborative software eco-system for our businesses and add to the growing landscape. Even if it means we may need to remember a few more passwords.
Independence ultimately wins the day. Let’s take a look at one of the best battles in television history to highlight the pros and cons of each type of software. Star Trek’s United Federation of Planets will represent micro-systems and they’ll face up against The Borg Collective, representing the monoliths.
The Borg are a large, vast and powerful force which consumes civilizations, explaining to individuals that, “your biological and technological distinctiveness will be added to our own, resistance is futile.” The Borg whole, is exactly equal to the sum of it’s parts. Every new piece is bolted on to the existing, there is no independence. Unique species, cultures, emotions and imaginations are lost as they become one with The Borg. It does seem effective and is definitely efficient; a Borg drone probably only has to remember one password. However they have a key weakness, that is, Borg drones are completely connected and dependent on the hive mind to give them orders. Top down, no questions.
Our heroes, the crew of the USS Enterprise, led (not managed) by Captain Picard (and then Commander Riker once Picard is taken hostage by The Borg Collective) are a group of T-Shaped people, experts in their respective fields; engineering, command, science, security, etc but with a certain degree of knowledge in the other areas. Their perfect (or imperfect) cohesion makes the crew more than the sum of it’s parts. They may communicate slower, however their communication is collaboration, not just one way commands.
In the end, the resolution hinges on individuality. Captain Picard’s resistance (not so futile) to Borg assimilation allows him give an independent, imaginative idea to his crew, “sleep”, which Data (a micro-service of sorts himself) understands and acts on without being told how. The idea centers on the fact that the Borg monolith is so interdependent that when the command is given to shut down, it runs through the entire system. The monolithic Borg cube powers down and is left helpless. The individuals of the Federation, despite being heavily beaten at the battle of Wolf 359, were not completely dependent on each other and could fight on, the result:
The Enterprise destroys the Borg cube in "The Best of Both World"
“Just as we want our people to collaborate, we also need our software to collaborate.”
Well, the same concept of individuality hold true of the technology we employ. Just as we want our people to collaborate, we also need our software to collaborate. The days of companies locking all their data and digitized versions of manual processes into only one large system are over. Even the traditional monoliths themselves understand they need to re-imagine their software into smaller pieces. Microsoft is just one of the older tech companies that has realized a need to deconstruct its monolith so their tools can work in conjunction with other independent software. Rather than trying to assimilate technological distinctiveness, they are trying to connect with technological distinctiveness.
As a result, it’s becoming more and more necessary for professionals to understand how different software services can connect, and why. Small, purpose-built applications can focus on what they do best. Whether it’s sending emails, creating documents or doctoring photos. Applications that have grown too big, ultimately trying to do things that they weren’t intended for, leaving them with bolted on features that not only don’t fit, usually don’t fulfill the goals they were intended for after a while, if they ever did. This is the stuff of legacy nightmare, as companies realize they are using out-of-date technology for tasks. For example, I don’t need a CRM to send my marketing emails as it’s unlikely a CRM tool will ever stay up-to-date with my ever changing email sending needs but I do need a way for my CRM to work cohesively with my email marketing tool.
It’s not just about relying on one tool to do everything either, it’s also about not storing all you data in one place, locking your business into a big contract as a result. Smaller services are easy to use and easy to let go of if they outlive their usefulness. Interchanging small applications is a lot less painful in the long run than trying to migrate your entire digital world from one do-everything-monolith to another.
The great news is that there are so many apps in the webiverse that not only do one thing well, they are also ready to communicate and collaborate with other tools through integration options and APIs. Some apps are even built just to be collaboration experts, which help different tools communicate, for example, IFTTT (If This Than That) which allows you to action events on one application based on triggers from another. For more business orientated workflows, tools like Zapier allow you to create infinite cross-platform workflows.
At Elastic Grid, we have an eco-system of many different services working cohesively, including our own, which we are constantly deconstructing as well. We have a few more passwords to remember but that’s not a problem when we consider the flexibility we have. We can also turn services on and off if we find a better alternative, which is a lot more cost effective and user friendly than leveraging expensive enterprise tools and being stuck with their offering.
Isn’t it better to have all the data you report on in one place? Yes, but you don’t need a monolith for that either. Dashboard aggregators are ready to help pull your data from multiple sources and help you monitor whatever you want too. But more on that topic in, Stop Reporting and Start Monitoring…
The digital world is an impossibly fast place and shipping small, iterative products is critical to business success and innovation. A frighting barrier to both of these things is that caused by the very tools which should enable them. Choose the software you use carefully, especially about the larger IT components in you software eco-system (email, calendars, project management, meetings, etc) and make sure they won’t impede teams trying to connect with new technologies.
This article first appeared on LinkedIn Pulse on December 14, 2016.
Lead UX designer and Design Team Lead at Elastic Grid, responsible for the user experience of the platform and the products visual brand. Lorenzo has extensive experience designing simple digital solutions for large, complex commercial projects, including e-Commerce, marketing campaigns and content management platforms.