Saturday, June 20, 2015

What is a Software Architect?

While there is not yet a universally accepted definition, there are a range of definitions and skills that are beginning converge on a definition. Here's how I define it, and where I think the industry is going with the definition.
Software Architect: A person who does the overall design work for a piece of software, including what core features and functionality it needs to have, and creating the overall design that can accomplish that in a manner that meets the business requirements, including cost, performance, capacity, and time-frame.
This typically includes specifying the modular design, the application programming interface, and may sometimes include specifying the tools, technologies, and and systems to be used to build it. It's analogous to what an architect does for buildings, creates the overall design, appearance, feel, function, materials, etc., but does not actually build it.

However, the architect's work does not end there. As it's being built, the developers and engineers are likely to have questions and/or suggestions for ways to improve it, and the architect must work with them to approve and incorporate such changes, or decide to omit them. There are likely to be changes in the requirements, features, and functionality from the managers/users that the architect must incorporate into the design as it's being built. The architect is also to verify that the implementation fits with the design and work with the implementers to ensure the modules all work together and that the overall system works as intended.

The Software Architect role may include the role of a Business Analyst, that is, gathering and documenting the requirements from users/management, or it may be more of a technical design role that works in conjunction with a Business Analyst, depending upon the qualifications of the Software Architect and the scale/scope of the project. On very large projects, there may be one or more Business Analysts, and potentially multiple Software Architects, with one being the lead architect.

How Does One Become A Software Architect?
In some environments, the person who is the Software Architect may also build/implement parts of the system. That's particularly true in smaller projects where the architect role isn't full-time, however, building the software is not actually the role of the Software Architect, that is the role of the developers/programmers. That one person may perform multiple roles does not alter the roles as I have defined them. In these instances, it's usually a senior programmer/developer that has demonstrated a level of proficiency with designing software over the years, not someone who is primarily a software architect. Indeed, this hybrid role is usually how someone eventually transitions into a role of primarily being a Software Architect.

The Ultimate Realization Of Software Architect.
As the architect becomes less involved in programming, and more involved with the design and business requirements, the specific technologies used to implement the designs become less important to the design. The computer systems, technologies, and languages used for the implementation become matters of cost, performance, reliability, convenience, and timeliness that, while important to the success of the project, aren't critical to the design, and can be interchanged or replaced as technologies and/or needs change. This is the ultimate realization of what constitutes a Software Architect.

What About Other Architect Roles?
This same concept can be applied to other areas of IT, notably, the roles of Database Architect, and Network Architect. As with Software Architect, these roles require extensive technical knowledge, as well as excellent understanding of the business needs the systems will fulfill, however, in most cases, the specific technologies used in the implementation won't be critical to the architecture. The Architect's job is to design a system that can be implemented using any of the available technologies, leaving the technology decisions as business decisions that may change, or be replaced, as the needs and the technologies change, without significantly altering the overall design. However, in the case of these roles, the architect is likely to have more of a hands-on role in choosing the technologies and may be more involved in the implementation than the "ultimate" Software Architect mentioned above.

Related Links: