When I started my career in IT, the Software Architect position drew my attention. The name Software Architect sounded beautiful and elegant to me, and the salary didn't seem too bad either. Then, after doing research, I decided to become one. To do that, I had to go deep through topics including software designer and coding. To me, being a software architect meant being an excellent software developer and knowing as much as I could about software design. Topics like Design Patterns, MVC, Integrations, etc., are enough to be a part of this restricted group of professionals. The fact is many people in IT still think this way. We commonly see Senior Developers or an excellent coder saying that they are an architect. After becoming a Master in Software Architecture and working primarily on architecture for many years, I can guarantee that Software Architecture goes beyond that.
In this article, I will present you one re-reading of Software Architecture Roles, by Simon Brown. The focus here is not to give a comprehensive look at this large topic, but rather a quick overview of this complex, yet fascinating, position. To Simon (and myself), becoming a software architect is not a simple task. It’s a role. It’s a result of an evolutionary process where you’ll gradually gain the experience and confidence that you need to undertake the role. To him, as we consider architecture to be a “role,” it can be performed by a single person or shared amongst a team.
Architectural Drivers: One of the interesting things I read in this book was this Role. In all my career as an SA, I had to be a part of business goals, understand that and provide solutions, managing the architectural drives, considering functional and nonfunctional requirements (or quality attributes), and the constraints of the environment. As a Software Architect, you must be aware that non-functional requirements and constraints often have a huge influence on the software architecture, and they should be taken into account during development.
Designing Software: It should not be a surprise. Designing software is a really important software architecture role. As Simon says, this is about how you’re going to solve the problems posed by the architectural drivers, creating the overall structure of the software system and a vision for the delivery. In fact, you can’t run away from that. Although you have to be skilled in design patterns and all the best approaches of designing, to Simon, a key part of designing software is technology selection, which is typically a fun exercise, but it does have its fair set of challenges.
Technical Risks: As a Software Architect, you have to choose which technology to use in your project. According to Simon, this is all about managing risk; reducing risk where there is high complexity or uncertainty and introducing risk where there are benefits to be had. At this point, I would like to present another great idea, this time from Martin L. Abbott (The Art of Scalability). In this book, Martin cites architectural principles and one of them is the importance of using mature technologies. In many cases, says Martin, you may be tempted by the competitive edge promised by a new technology. Be cautious with that. As an early adopter, you will also be on the leading edge of finding bugs with your software or system. He finished by saying that if availability and reliability are important to you and your customers, try to be an early majority or late majority adopter of systems that are critical to the operation of your service, product, or platform. Implement newer technology for new features that are less critical to the availability of your solution, and port that technology to mission-critical areas once you’ve proven it can reliably handle the daily traffic volume.
Architecture Evolution: This is fairly self-explanatory. The result of software architecture must be a software that is easy to maintain and extend. As a software architect, your software must be designed to grow. So, think about paradigms of design, like DDD. There a good materials about that by Vaughn Vernon, like his book, Implementing Domain-Driven Design.
Coding: This is it! You are also a software developer, never forget that. I don’t know why, but many people think that, once you become a Software Architect, you don’t have to code anymore. This is a big mistake. To Simon, and I agree, being a “hands-on software architect” doesn’t necessarily mean that you need to get involved in the day-to-day coding tasks, but it does mean that you’re continuously engaged in the delivery, actively helping to lead and shape it.
Quality Assurance: None of the roles above make sense if you release a poor product. Quality assurance must be considered as a part of architecture role. You need a baseline to assure the quality of your project and as well as standards and practices, such as coding standards, design principles, and tools. To Simon, quality assurance also includes ensuring that the architecture is being implemented consistently across the team. Whether you call this architectural compliance or conformance is up to you, but the technical vision needs to be followed.
In order to became a software architect, you should be aware that you will work a lot. You have be to prepared to make hard decisions and take on responsibility. You must garantee that you'll deliver a product that can't fail. Study standards of qualities. Conctrate on what you are doing. Be up to date. Go further!