In an effort to compare what architecture means to a software development project against a real life analogy, we're going to use an example of construction of an apartment complex. ArkusNexus senior software developers and tech leads, often will recommend to design and plan application architecture smartly as it allows future innovation and ultimately ends up saving valuable resources like time and money. See it this way: Would you let an engineer start working on an apartment building without anybody else doing any architectural design work? Of course not, and just like that, you shouldn't do the same with software development. Whenever you are outsourcing software or working with in-house teams, here's what you may want to consider as you kick off your next project.
Construction: First step is to work on your blueprints. There are some questions that you need to answer here: who will be occupying the new apartment building? Is it located inside a college town? Or far away in a rural area? Is it surrounded by bars downtown? Answering questions like these will help you determine your building materials and also help you understand the needs of your tenants, like do they need a big kitchen for a large family or a small one for a couple of friends.
Software: You need to ask these same questions here, What type of user are you targeting? Are they tech savvy or not? Do you believe your platform will need to scale up and bring more users in the future? This will allow your team to have a “blueprint” of the requirements and to always be aware of certain things during the development cycle.
Construction: Having a blueprint allows you to have everything planned beforehand, this way you won’t end up building a wall in a place and then having to demolish it later because it wasn’t supposed to be there in the first place, or because you simply changed your mind mid-construction. It’s pretty easy to understand how inconvenient this is as you waste not only building materials but also valuable time from your construction crew.
Software: When you have a “blueprint” or a roadmap that shows exactly what you need to build, you avoid working on code that in the end it’s not going to be used because it isn’t compatible with the requirements of the application or software system. This way you avoid “demolishing walls” and you end up saving resources, as the developers won’t spend precious time working on something that, in the end, will be discarded or completely ignored because it doesn’t align with the project.
Construction: Let’s say that the main apartment entrance doors are a certain size, when you have blueprints you know exactly the size needed and you can benefit from this in a lot of ways. Maybe you find a great deal on doors that are a little bit bigger than needed, thanks to your planning you can benefit from this deal because you know for a fact that the doors can be adapted to be smaller and fit the entrances. But imagine you don’t have the size on your blueprints, you can either miss the hot deal and lose the great benefit that comes with it or you simply buy all of the doors only for your team to tell you that those doors are unusable because the entrances can’t be that certain size for whatever reason, the entrances can only be bigger than the doors and you are now stuck with a lot of doors that are smaller, sure they can be adapted to fit the entrances but you are going to spend a lot more time and money in adapting them to be bigger than reducing their size a little bit. This is one of the many reasons architecture ends up saving time and money in construction.
Software: When you have your software architecture defined from start, you can pinpoint exactly the kind of tech stack you are going to need for your entire project, this way you can get all your licenses in order and not only that, but also define the people that are going to work on your team. It is now easier to select the personnel and work on your team dynamics from the start, compared to not having architecture. Let’s say you manage to assemble a team of experts in Ruby technology, because that’s the tech you are building today, but when time to escalate your software comes, you get the news that now you are going to need experts on .net, and now you are stuck with a bunch of senior Ruby experts and you can’t afford .net experts to work in the project. You probably are going to have to remove a couple of Ruby devs in order to add .net experts, you’ll need to work on team dynamics all over again as well as have to dedicate your time in recruitment, paperwork, on-boarding, etc. When you have your tech stack defined from start, you can work on having a high performance team from the start, and the chances of the team dynamic being interrupted are slim to none.
Construction: Last but not least, when you have blueprints and architecture work you can always think of the possibilities, maybe you don’t have enough resources today to have a 10 story building, but it can be designed to be expanded so you can finish construction while all the pipe work will be accommodated for it to grow vertically and when the time comes you can start building more floors without having to demolish anything that was already built.
Software: Every successful business will eventually need to scale up, maybe you are covering different areas that your system didn’t cover before, maybe your user base is getting bigger and now you’ll need more servers, maybe you decided to widen your audience, for whatever reason it is when you have an architect in your team he or she most definitely thought about that and is more than ready to start making upgrades instead of making changes. Here’s when not having a software architecture phase is coming back to haunt you. Every business should be designed to be successful and when the time comes you are going to love all the benefits of architecture, this is when you are most vulnerable and you need to be fast and efficient. If you don’t have a solid ground base you risk a lot here, remember all that time and money you “saved” by skipping your software architecture phase? well there’s a reason I put that with quotation marks, you are going to spend a lot of those valuable resources reworking your base project, some of it may now be completely unusable and you may even have to start the whole project from scratch, that’s not something you want to have in your most vulnerable phase as a business.
