The journey to build enterprise systems
Two hard-won principles for large-scale systems: keep the architecture small enough to hold in your head, and fix developer efficacy before business alignment.
The journey to build enterprise systems
Stefan Zepeda
Published Nov 27, 2018
Building enterprise systems is one of the biggest challenges in the IT professional life. From leaders in small start ups to the largest corporations, every day is full of challenges around how to build a new product, enhance an infrastructure or build it from the ground up. Along this journey we all encounter similar roadblocks and will face a similar set of difficult design decisions. Not to forget that at the same time we need to be able to balance needs and deliver products with efficacy and agility.
I have been building and enhancing systems for the most part of my adult professional life. I started my career as a support engineer trying to solve dozens of different enterprise problems every day on the phone in real time. Today I build enterprise systems on the Salesforce platform, however, this is no different than any other SAAS platform or building your own product from scratch. This article will cover two of the biggest problems with building systems at scale and it will aim to serve as a guide to make better decisions in the long run.
Less is more, reduce complexity to make systems more understandable
There is a simple rule to follow about system complexity: If you cannot hold your system’s architecture in your mind then it is too complex. Make no mistake, the overall system operations do not have to be simple they just have to be easy to digest and explain. This is the key to make a system maintainable and successful at the enterprise scale.
There are a few things that will help keep your level of complexity in check. First, document a simple system diagram that you will be in charge of keeping up to date. This diagram will simplify making design decisions as it will keep the most up to date architecture details fresh in your mind. Additionally, if the diagram is getting out of control there is a good chance your system is getting out of control too!. At this time, it is a good idea to make a small refactoring exercise to reduce complexity before its too late.
Second, do not reinvent the wheel. Use prepackaged features as much as possible. The framework or language that you use has spent valuable time developing some common features for you. Do research on your current platform and use those features before you embark in creating your own.
Finally, always build your system for the future. It is very common to start building your system with a prototype mindset, this forces even the best leaders to make rushed decisions that they plan to change in the future in an effort to deliver a product faster. Most of the times, when the mistake is rediscovered it will be too late in the timeline or many things would have been built around it making it hard to change. Keep in mind that this doesn’t mean you need to overthink every decision, just always think at scale.
The constant war between business alignment and IT efficacy
A product or system will always be created to serve a business purpose, however, never forget that there will be a struggle between a business perfect product and what is technically feasible in the amount of time provided. No project will ever have an unlimited timeline and with the boom of agile methodologies we will always find ourselves making a balancing act between the developer’s ability to deliver results and the stakeholders’ interests. Kevlin Henney puts this into perspective in some of his software developer talks and explains it in a very concrete graph result of a survey to 500 participants:
In this graph, we can see that most surveyed organizations fall into the “Maintenance Zone”. In this zone the developer teams are not aligned properly with business needs and are less effective overall. If you are in the Maintenance Zone, it is hard or nearly impossible to move to the top right corner immediately. So a choice needs to be made, do we focus on increasing efficacy or do we enhance the alignment to the business? The choice is simple, always focus in increasing your developer’s efficacy first.
To illustrate the point Mr. Henney also quotes Richard F Connell:
“ Aligning a poorly performing IT organization to the right business objectives still won’t get the objectives accomplished” (Read more on Avoiding the Alignment trap in IT here).
Focus first on fixing your processes and organization before you embark to build systems with a poorly performing team.
The combination of these two topics will help you stay closer to success in the IT and development world of systems at scale. Always keep your mind focused in reducing complexity to keep your system as maintainable and understandable as possible. Finally, focus your time and energy increasing IT efficacy as they will be the building blocks of your developer organization.
