Software Architect's Career Roadmap
How does one become a software architect? This depends on your definition of architecting. For the purpose of this article let’s use the following statement: A software architect is responsible for creating or selecting the most appropriate architecture for a system (or systems), such that it suits the business needs, satisfies user requirements, and achieves the desired results under given constraints. http://msdn.microsoft.com/en-us/architecture//bb266336.aspx
Before we discuss the career path of a software architect it’s important to note that a number of other architect flavors exist: Business Architect, Solution Architect, Infrastructure Architect, Enterprise Architect, Technical Architect, Systems Architect, and Business Strategy Architect. There are other flavors as well, but this MSDN article describes abovementioned flavors in sufficient detail. The Solution Architect role appears to be most closely aligned with the classical definition of a Software Architect.
Software architect’s career starts with a rigorous study of computer science. Ultimately an architect is responsible for making the toughest decisions on system design. Hence he or she must have core understanding of the theory independent of specific programming languages or latest patterns and paradigms.
Theory must be realized through practice – through programming. The essential skill is the ability to write code. This does not mean an architect needs to be writing code on consistent basis or even have an IDE installed. But he or she should be capable, at any time, to learn the syntax of the chosen language to create a prototype / proof of concept for an architecturally challenging problem. To be credible in the eyes of the peers and developers an architect must be able to code.
Next important experience is developing software in a disciplined team based environment: working as a professional software engineer. Take a note that being a programmer is not the same as being a software engineer. Programming is one of the roles a software engineer performs, but software engineering is about a disciplined way of developing software. Experience working on a project that requires multiple developers to succeed is the only way to understand the dynamics of working as a team.
Being a software engineer also means developing software using some software development lifecycle (SDLC) or better yet experiencing the full Application Life-cycle Management (ALM). Note that the type the SDLC (e.g. RUP, SCRUM, XP, Waterfall) is less important than experience of going through the different phases (requirements gathering and analysis, architecture, design, development, testing, deployment, and change management) while predominantly playing the role of a software engineer.
An effective software architect must also have experience playing the core roles in a SDLC. This includes requirements management, business problem analysis, build master and deployment, testing, and operations and maintenance.
Up to this point this article described essential non-architectural experiences and skills. Now let’s shift attention to the software architecture learned skills.
Software architecture as a discipline has matured significantly since inception. The practice of architecting is no longer reserved for the experience few. The core pillars of the software architecture discipline can now be learned in college and graduate courses, training programs, and books. The discipline is turning from a craft into a practice accessible to the general body of engineers with some training, patience, and experience. A great number of paradigms, analysis tools, and methodologies, have developed to support different perspectives of the software architecture practice.
The core need for an apprentice software architect is to learn the architectural styles, also known as patterns, applicable to his or her domain of expertise. The domain of expertise can split into business domain expertise (e.g. automotive industry) or solution type expertise (e.g. web based enterprise grade systems). The patterns are learned effectively when they are applied through practice.
At this stage of time it’s assumed that an architect has some requirements gathering and analysis experience. However it’s imperative to learn how to gather and analyze requirements from an architectural point of view: specifically how to identify, analyze, and document quality attributes (non-functional requirements). The Software Engineering Institute (SEI) developed a Quality Attributes Workshop (QAW) to methodically gather such requirements. Other analysis techniques may be used as well.
Learning different ways to analyze and reason about software architecture at different intervals of development is essential. A number of techniques exist to help an architect understand the degree of goodness of a given architecture. Some of the popular methods include Attribute-Driven Design (ADD), Architecture Tradeoff Analysis Method (ATAM), and many others.
The analysis, reasoning, and design of the architecture needs to be documented so that others (or the original author) can understand the solution. There are different approaches to documenting software architecture, but one thing is clear: software architecture is a composition of multiple views that together represent the static (e.g. code, components, and classes) and dynamic (e.g. processes) views of a system.
Finally, an architect must never stop learning. Continuous involvement in community of practice, learning about new technologies, methodologies, and techniques is essential to maintaining one’s lofty status of a software architect.
To manage technical and business complexity every architect needs an effective support group. Rapid changes to business models, ubiquity of computing platforms, and the flood of new technologies make it impossible for an individual to gather and process all the necessary decision making information. Responsible software architects understand that their past experience may not be the best solution for the next problem. Every software architect needs an effective support group to manage change and complexity; every architect needs a Firebrand Architect® Cohort for support.
