Technology•Apr 18, 2019
So, You Want to Be a Software Architect: Steps to Start & Ensure a Successful Career
My own journey as an architect started 14 years ago, four years into my career as a junior software developer. I was fortunate enough to have landed a job right out of school actually writing code instead of just testing code, which was at the time the more common starting point for new college grads. A potential career path as an architect beckoned from the very first time I became aware that it was even a possibility. It promised an opportunity to earn more, stay technical, and avoid the doldrums of being a career project manager. If this resonates with you and you have similar intentions, keep reading. You might be wondering if you have what it takes, how you should initiate your journey and what you should expect along the way. What follows is advice for anyone wanting to become a software architect.
Unlike other more mature engineering disciplines, making your way toward a career path in technology architecture doesn’t have a prescriptive plan associated with it. Mine began with a seed planted in a regular one-on-one session with my boss. I confidently announced my career intentions. I wanted to be an architect and was willing to do whatever it took to become one. About two weeks later, I found myself thrust into the position of representing our group’s technology strategy in an important meeting that typically involved people several job levels above mine. I was the most junior person at the table and had an audience with the division’s chief enterprise architect and the vice president of the organization. My boss had understood my ambitions and worked to create a win-win situation out of my request. I never imagined that events would unfold this way, and while your mileage may vary, communicating intentionally about your goals may propel you further than you think.
It’s probably a good idea before making any kind of career investment to thoroughly understand why the world needs the thing you want to become. So what is the raison d’être for a software architect?
Software architects are relevant in the setting of a software construction team. They need to master three things:
Creating software designs.
Bringing others into an understanding of those designs.
Helping the construction team navigate their implementation of the design.
These are critical roles and a team that does not find a way to fill these roles explicitly will compensate creatively and likely struggle. On the rare occasion, I have seen some teams perform beautifully without a named architect, but only rarely and at least not without an upfront struggle. These tasks need singular ownership and aren’t easy to divide among a group without creating disjointed results.
the three roles of a software architect
As a designer, the software architect identifies appropriate building blocks for the system, defines how they relate to one another, and assigns responsibilities for all of the things a system is required to do across each of those building blocks. To make sure we’re speaking the same language, a “building block” could be anything from a technology platform or software library to a custom class, function, programming language, or tool. Their identification, selection, and responsibility assignment is informed completely by the requirements and context in which the system is being constructed. The granularity that the building blocks should be defined with will change over the lifecycle of the project. Initially, when things are most ambiguous, they will be very coarsely assigned. As the analysis work progresses and uncertainty is replaced with facts, the design will define and depict more detailed building blocks and interactions.
As a communicator, the software architect faces arguably their most important duty; clearly articulating both the high-level concepts as well as the specifics involved in a design. As an architect you will be required to adjust your communication tactics depending on the audience you are engaging. For instance, the ability to relate complex concepts in succinct, non-technical ways to the people who are paying for the product being built is critical. Ultimately, there are two vocabularies you will need to fluidly switch between—the language of business and the vocabulary of software design that the team will use to build the system. The effort to create a design, no matter how extraordinary or elegant, is thwarted entirely if the output cannot be articulated in an understandable way to each audience.
Finally, as a leader, the architect bears the responsibility of helping teams realize the vision of the design. As a team’s architect you will guide daily decision-making as issues come up during construction and blaze new trails where the team needs examples of how things should be done within the design. The architect is often the single thread of continuity between the vision of the product and its final realization. The architect as leader also sets the pace and enforces adherence to everyday disciplines such as unit testing, consistency of implementation patterns, attention to factors that affect performance and scalability, and security concerns.
Every software team needs architecture to build software effectively whether implicitly attained or explicitly manifested in a person playing the role of an architect. There are often multiple levels of architects in place in an organization to ensure consistency and support across teams. This is not uncommon in both companies that follow a matrix organizational model as well as traditional hierarchical organizations. The great news for all of us is that good architects are needed and continue to be in high demand throughout the software development industry.
so how do i become a good architect?
1. forego certification and look for hands-on training
Although multiple certification programs exist and have been driven with great efforts by well-known organizations like Microsoft or The Open Group, certification is not necessary. Unlike more mature engineering disciplines such as electrical, mechanical, or construction architecture, software architecture is still largely a field where certificates are neither universally recognized nor sought after by employers.
While this can be frustrating for someone looking for a structured pathway to becoming a credentialed software architect, the demand-driven state of the industry represents a great open-ended opportunity for those willing to creatively find and fill the roles required. The opportunities may exist right where you are. As evidenced by my experience, your opportunity may be found in the act of simply sharing your interest and intentions. If that doesn’t work, your most reliable pathway should be focused on skill-building, seeking numerous and diverse software development experiences, and overtly seeking design, communication, and leadership ‘at-bat’ opportunities in your current job role. Volunteering to help a busy architect and taking on the job responsibilities they are willing to delegate is a great way to both get experience, mentorship, and pass along the message that you are serious about the task.
2. develop software design skills
What are the most important skills to practice and master? The core of a software architect’s job is design work. At its heart, architectural design is mostly about arranging things based on constraints and priorities. If you enjoyed organizing your toys as a kid, cleaning your room, or arranging your pantry, then it is likely you have the beginnings of what it takes. Systems of any size are stitched together from smaller parts, and an architect’s primary job is to define the parts of the system, how they relate, and the responsibilities assigned to each. The ability to organize things, both real and imaginary is critical.
I know of no better way to do this than to use models that represent the system, and although a model can take many forms, knowing commonly understood visual languages like UML is the key to good communication. Although I would encourage a thorough command of UML as a basic starting point, I have learned how to take liberties to prioritize being understood over being technically correct in my use of the modeling language. I once heard an architect say that the ultimate measure of success for a model or system diagram is when you see someone else has adopted it as their own. I agree. It feels great to see someone else choosing to use your models or diagrams to express concepts to others in their own presentations or discussions.
3. learn to think big picture & don’t be afraid to innovate
Design as an activity, however, doesn’t stand on its own and certainly can’t be accomplished in a vacuum. I’ve seen many would-be architects get caught up in the trap of thinking too much in absolute terms about architecture, as though there were a singularly ‘right’ answer for how all systems should be formed. Usually this comes from reading popular texts about a particular architectural style, pattern, or platform and then developing a belief that it is categorically the best or only way to build a system. While exposure to these ideas is desirable, you must understand they don’t represent universally correct answers. We have all gazed in wonder at physical machines that bucked traditional design conventions in favor of what was fit for purpose. In these cases, the newly adopted form better accomplished the function needed and more beauty and elegance was produced in the result. Don’t exercise it often, but reserve the courage to buck the norms in favor of best fit for the situation.
4. master the art of analysis
Analysis is a skill all software architects employ to reason through the ‘why’ of a system. As an activity, it connects design choices to the context in which the system is needed, constructed, and maintained. Analysis centers on gathering and considering things like constraints, preferences, requirements, and guiding principles. These things each exert pressures, sometimes conflicting ones, on the shape of a solution.
Practice coupling every design choice with a supporting reason for why and documenting it, and you will be well on your way to building your analysis muscle. In modern software architecture, it is not enough to simply arrive at a design. Like in your grade school math class, showing your work and recording a rational justification for your design is, in many cases, equally as important.
5. hone your communication skills
Outside of design and analysis, the ability to communicate complex ideas in a simple and compelling way to a wide variety of audiences sits at the top of the list of skills you need in order to succeed as an architect. The most elegant designs must still be expressed in a way that can be understood and related to other audiences whether they are technologists or executives. The ability to draw, write, speak, and reason about a system’s design is on par in importance with the actual design itself.
Effectively bringing others along in an understanding of the plan for how something will be built can set the stage for project success. Left uncommunicated or ineffectively expressed, the entire project may be put into peril because the implementation team is not aligned. Written and spoken words are vitally important in this endeavor. As an example, I have often marveled at the uncommon, almost literary precision that is often used in selecting type names within the source code of some high-quality open source products. Study a popular open source library and you will be almost guaranteed to add new words to your repertoire. Building a robust vocabulary focused on expressing ideas with economy and precision is essential both in and out of software.
6. learn to think in abstractions
While software is often based on real-world concepts that mirror the world around us, it is also chock full of abstract ideas that have no real-world counterpart; conceptual fabrications that serve a purpose in problem solving or fitting building blocks together. I know of no other field besides physics or mathematics where this notion is so prevalent.
Design patterns are excellent examples of this. Starting with the classical Gang of Four book and expanding to Martin Fowler’s Patterns of Enterprise Application Architecture will go far toward stretching your mind to the point where abstraction becomes a normal mode of thinking. All systems can be conceptualized with an appropriate model. Architecture requires adopting a new set of rules for mental modeling.
start working toward a career as a software architect
With some intentionality and focus, developing a career in architecture can be done as soon as you are ready to start. Begin by expressing architecture as a desired career goal to your supervisor and do this early in your career. Look for explicit or indirect opportunities to fill the three critical functions of an architect (design, communication, and leadership) and develop your personal brand as someone who does these things. Find an architect and volunteer to help them out. Finally, look for and create personal opportunities to develop the core skills of an architect (design and organization, analysis, communication and modeling, and thinking in abstractions). In my experience these things, done with the right amount of energy and intentionality, will broadcast your abilities and set you on the right path. The market demand for good architects is strong enough to ensure that you will find a home in your new role when you are ready.
Are you seeking a career at a great workplace in Dallas, Houston or Denver? Consider taking the next step on your professional journey with Credera! Check out our open opportunities and follow us on Facebook, LinkedIn or Twitter to find out more about Credera’s family-like culture.