Welcome to the second episode of the This Dot Labs podcast. This episode features conversations around Software Architecture and Systems Architecture.

Architecture is a vast topic, but here, we will address what architecture is as it pertains to software. What are architects? What distinguishes an architect from a senior developer?

Architecture is an interesting concept. There are all of these different frameworks and languages that we have to write in, and the higher you go in terms of architectural concepts, the more abstract things become. A senior dev can focus on writing a component or structuring out some complex code, but the architect will answer questions like, what's the long-term vision?

It's often very difficult to define what distinguishes an architect from a senior dev across all companies and technologies. In smaller companies, you have to wear a lot of hats depending on the task at hand. But as companies grow, and roles need to have more solid definitions, the architect role and the developer role become more distinguishable.

One of the important things that architects do is pay attention to some of the non-functional requirements. It's really typical for a client or company to have expectations or specifications that may not be best suited for the project. Making these determinations is one of the things that an architect might do.

They are also responsible for setting a good standard across a given project. Everyone has their own unique coding style, and values. It is ultimately the architect's job to mediate differences and get everybody on the same page.

One of the clearest examples of an architect is somebody who takes extra care and consideration for the protocols of communication across different parts of the system. It could be something as simple as the API that is driving a web form, or the protocols between micro services. One of the critical roles of an architect is having the foresight to make the necessary decisions to get to a finished product faster, and enable more rapid iteration in the future.

For many, there’s a point in their career, whether they know it or not, when they become architects. One may realize that they have not coded in a little while. Instead, they've been doing these different diagrams, talking a lot to the client, and coordinating with developers. A person like this may start to think of themselves as an architect.

This not to say architects don't code, but they do tend to work at a level of abstraction that better serves their team by enabling devs to implement individual features under their direction. An architect is part leader and part technician who will coordinate operations at least as much as they contribute code.

There is often a question about how to plan out a system. Unfortunately, there is no simple answer. Much of this process depends on an end client. What is their budget? How fast do they want it? Certain patterns cost a lot more money to implement, are a lot more extensive, and may have lower ROI.

The choice to go serverless, for example, will give you a platform to spin up ideas quickly, with less overhead, fewer people, and maybe even fewer technologies, allowing you to get to market a lot quicker. However, it might not be as extensible or as upgradable. Software architects are often tasked with evaluating these difficult questions of cost-benefit.

There are a lot of architectures that are coming out that look very promising, but it's hard to analyse them with current technology because we don't yet know their true long-term maintenance and scaling costs. For example, if you're looking to get to market in three to six months, you're probably going to be best accommodated by existing technology that you can roll out quickly. If you're delivering something in two to four years, you have the time to make educated decisions about the direction of your architectural program in order to best position a product for long-term success. You can learn a lot about where technology is going from following Twitter, reading blogs, and watching what major companies are doing.

We all ultimately want to avoid that scenario where we invest a lot of time and money into something only to have it become obsolete. As an architect, one encounters a lot of new strategies and concepts. But when architects are making decisions about their own systems, they should stick to something that they know, and that their team knows. Even using a slightly antiquated system can be better than jumping into one of the newer patterns or tech stacks just because it is popular. Often times, failing to do something new and innovative can be much costlier than correctly executing a more out of date system.

There's not one technology that ever solves all the problems. Everything comes with its own overhead, and I think that's where one of the important parts of being an architect comes in. As an architect, you need to be able to decide when it is not strategic to explore the hottest new technology. There's a very strong case to be made for letting the bigger companies play around with them first because they have the resources to navigate multiple digital paths, and commit to the one that works best. Smaller companies, however, usually pursue one development path, which can be catastrophic for teams if they discover that their technologies do not best suit their needs.

Part of the architect's job is empowering their team. This includes writing directions and code with which the whole team can actually work. Picking libraries, tools or frameworks that have great documentation enables a whole team to get up to speed with an architect's code and concepts. This benefits the architect even more because great documentations means you have a product that's a little bit more mature and stable.

Documentation is very much a communication protocol that needs to be designed like any other protocol. This is another aspect architecture that is often overlooked. A project that has fantastic documentation increases the strength and independence of everyone who jumps into it. Documentation is the antithesis to micromanagement, and allows one to communicate many goals and aspects of the project without involving developers in administrative conversations that would not likely be helpful for their roles. It really is important to involve the team in drawing out architectures ahead of time as opposed to just jumping in. This way,teams know that they are all operating on the same level.

Good learning resources for how to think about setting up an app's architecture include Jason Miller's piece on Application Holotypes and Lee Byron's series of talks on Immutable Data Structures. It is also very important to find videos in which people explain how they structured their system, and what benefits it gave them. Finding a great mentor, or even just asking people and having a conversation about it on Twitter can be helpful as well. Sometimes, a project's leader doesn't have all the right answers, and could benefit from collective input. If you feel comfortable doing so, you should question certain decisions, and propose new solutions, because it might be that you are not the only person who has thought of a concept, and you could start a productive conversation.

And who knows? Doing so could be the first step in your journey to becoming the next great architect!

This Dot Inc. is a consulting company which contains two branches : the media stream and labs stream. This Dot Media is the portion responsible for keeping developers up to date with advancements in the web platform. In order to inform authors of new releases or changes made to frameworks/libraries, events are hosted, and videos, articles, & podcasts are published. Meanwhile, This Dot Labs provides teams with web platform expertise using methods such as mentoring and training.