Tuesday, March 20, 2007

What is a software architect?

This was a definition I found somewhere.... I was trying to figure out what it meant when people called me an architect. ;-D (I guess I am a wannabe architect)

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. This article describes the myriad responsibilities of a software architect, and attempts to identify human personality traits that naturally aid a person in such position.

An architect abstracts the complexity of a system into a manageable model that describes the essence of a system by exposing important details and significant constraints.

An architect maintains control over the architecture lifecycle parallel to the project’s software development lifecycle. Although an architect may be most visible during the requirements and design stages of a project lifecycle, he or she must proactively monitor the adherence of the implementation to the chosen architecture during all iterations. Architecture on paper is fruitless unless implemented proficiently.

An architect stays on course in line with the long term vision when projects’ scope creep attempts to manipulate software architecture in a certain way in order to satisfy the desires of myriad stakeholders. An architect must focus on actions that produce results early while staying on course for the long term. When project variables outside of one’s control change the architect must adjust the strategy given the resource available while maintaining the long term goal.

An architect progressively makes critical decisions that define a specific direction for a system in terms of implementation, operations, and maintenance. The critical decisions must be faithfully made and backed up by understanding and evaluation of alternative options. These decisions usually result in tradeoffs that principally define characteristics of a system. Additionally these decisions must be well documented in a manner understood by others.

An architect sets quantifiable objectives that encapsulate quality attributes of a system. The fitness of the architecture is measured against set marks.

An architect works closely with executives to explain the benefits and justify the investment in software architectures. This may be done by participating in business process re-engineering activities, by using Cost Benefit Analysis Method, or by measuring the level of component / architecture re-use between projects with the help from the software process improvement team. Software architect must be effective in order to deliver results that are meaningful to the projects that have an impact on the bottom line that result in greater profits.

An architect inspires, mentors, and encourages colleagues to apply intelligently customized industry’s best practices. Educating the recipients and participants of system architecture is essential to successfully selling the chosen architectural path. Specifically the stakeholders must be able to understand, evaluate, and reason about software architecture. If an architect is the only one who can read and understand documented system architecture, then he has failed to integrate his best practices into the organizational culture.

An architect fights entropy that threatens architect’s structural approach to problem solving. It’s an architect’s job to keep the inertia going once the project is in progress. He or she must convince all relevant stakeholders that the chosen approach is sound – moreover the chosen architectural solution must be well explained and justified. The benefits of implementing a system in a particular way must be explained not only in terms of “that’s the right pattern for this problem,” but also to demonstrate the measurable benefits - such as easier integration. For example, in a product line approach an architect must be able to demonstrate how the subsequent projects will be easier to implement due to the presence of a common base from which subsequent work can be done.

An architect creates and distributes tailored views of software architectures to appropriate stakeholders at appropriate intervals. For example, a customer may demand to become more involved with a project and they may need to know an abstract view of a system on the level understood by them. A government customer may require an architect to demonstrate early in the project how a given system meets High Level Architecture requirements for a specific framework. It’s the architect’s responsibility to identify and present a sufficient level of information that a customer needs.

An architect acts as an agent of change in organizations where process maturity is not sufficient for creating and maintaining architecture centric development. If the concept of software architecture is not well recognized in an organization it may be a “tough” sell to formally recognize the role of software architecture in a SDLC. Without senior management commitment and without mature software development process, architecture of the system on paper may not reflect the actual architecture of a system.

No comments: