Part I [1] of this article described the various types of software architect. In this article we’ll describe the work they do, or should do, in a bit more detail.
There are many differing opinions on this topic, and before we move on I’d like to briefly mention one of the more prominent ones. The World-Wide Institute of Software Architects, WWISA [2], defines the software architect’s role [3] over 8 phases of software construction. They extrapolate these definitions conceptually from the definitions established for building architects. The analogy seems pretty good, but they seem to disregard the other roles and positions in a software development organization. Their definitions merge the roles of architect, project manager, analyst, software engineer, consultant, technical writer, and even trainer. If the architect is to perform all of these tasks, then what is the analyst to do? Or the systems engineer? Or the software engineer? They appear to leave room only for clients, architects, and programmers. Of course, if we presume the software architect to be the technical lead over all aspects of the project, then suddenly it becomes the architect’s team performing these tasks, the team may consist of all of the omitted roles; but that does not seem to be the intent of their description. Their definitions read more like the description of an independent software consultant with full design responsibility. I suspect many software consultants with little knowledge of software architecture would claim to perform most, or all, of the tasks described by WWISA [2].
The position of the WWISA [2] must be taken in context. It fits with their stated goal of defining Software Architecture as an independent profession. Indeed their descriptions might be quite effective if one assumes a smallish project, a consulting software architect who is also the project technical manager, and an outsourced development team. That may work in some business-models, but solid software architecture is also needed for in-house software development, where there is an in-place project manager, and an established team of analysts, programmers, and others to perform the development work. Software architecture does not include things such as GUI design, project staffing, user training, or style guides. These tasks do not require an architect’s skill set or system knowledge. A software architect must be a multi-talented individual, capable of many of these tasks; and they may well be within the scope of his duties; but the true purpose of an architect is to create a high-quality software architecture. For this reason, this article will define the software architect’s scope more narrowly.
In my opinion, the role of software architect exists in order to maximize the probability and degree of success in meeting all criteria in a software development endeavor. The criteria referred to are, most commonly, quality, performance, cost, and schedule, but why “probability and degree”? Well, if a project is given a $10,000,000 budget, and 1 year schedule, and it winds up finishing two-months late and $2,000,000 over-budget, it will probably be judged as being successful, albeit, perhaps as a limited success depending on the mission and the organization. If it were finished on-time and on-budget, it would certainly be judged as a complete success; and if it were 10% under budget and 1 month ahead of schedule, management would be absolutely thrilled; unless serious defects started to surface after the release. So there are degrees of success for each criterion.
Like building architecture, software architecture exists irrespective of an architect’s involvement; but an architecture can be good, bad, or anywhere in between and this is where the expertise of the software architect comes into play.
So what do we mean by “software architecture”? Without getting into intricate definitions, we will say these things about architecture:
- Architecture is design.
- Architecture defines top-level components, interactions, and constraints of a software system. Note that
- “top-level” is relative to the architectural domain.
- Architectural rules may constrain the use of certain structures, software devices, libraries, or communication styles for all contained components.
- All architectural features are representable via some combination of rules, descriptions, API specifications, and diagrams. There may be multiple views or aspects required to completely capture the architecture.
- The quality of the software architecture is always directly related to the maintainability, flexibility, and run-time robustness of the system. It may (and generally does) also affect the run-time performance, and usability of the system though, often, less directly.
At the outset of a project, the software architect applies what is known from requirements, as well as his own knowledge of the domain to form a concept of what top-level components, interactions, and constraints will be involved. At this time, it is quite possible that software requirements are very incomplete, and that the preliminary architecture will represent the architect’s best guess, based on experience or research in the knowledge-domain. In some projects, software architecture may be started on this basis before the hardware is even defined. I expect this practice to become more common in coming years. It is made less risky by analysis-based techniques such as “Model-Driven Architecture [4]”.
Developing software requirements is not part of the architecture development, though the architect will have some involvement here. As the requirements are created, the architect will allocate their fulfillment to the top level architectural elements, thus helping to ensure that the architecture is complete. This also involves a degree requirements validation, as the architect should evaluate the consistency, completeness, and robustness of the requirements in the course of their allocation.
Once the high-level software requirements have stabilized, the software architecture should also begin to stabilize. The software architect should analyze the fully developed architecture in the context of all that is known about the system. Gaps and weaknesses that would allow system instability or failure should be ferreted out and fixed, or rules applied that would prevent issues during development. In high-integrity production environments, there may be some sort of formal verification of the architecture. This effort may use formal methods with proofs, or other rigorous analysis techniques.
Once the architecture has been verified, the architecture documentation is made ready for release. While there may be small refinements during the course of development, the architecture should change little from this time forward. Issues may arise from time-to-time that demand changes, but architectural changes can become very expensive once programming has commenced. Furthermore, any changes will require a re-verification of the relevant parts of the architecture.
Following the release of the software architecture documentation, role of the architect changes. He no longer functions as the lead designer; he is now the lead-enforcer, but he must also be a mentor and a facilitator.
During the bulk of the software development process, the chief role of the software architect is to guide the development and verification teams in working with and within the architectural framework that has been established, and enforce compliance where they deviate. He becomes the “architecture police”. He should keep apprised of sub-system design, and monitor development. He may be asked to perform or aid in sub-system designs. He should be informed of issues arising during test that may point to defects in the architecture or violations of it. The sooner such things are caught, the less expensive they are to correct. In this respect, his role may appear closer to SQA than it does to design. If some element of the architecture is found to create issues for the lower-level designs or the implementation, the architect may need to re-assess that feature or constraint in order to determine the best course of action; refactoring the architecture, or a single-instance work-around. In some cases a single-instance work-around will not harm the architecture provided it does not interfere with the workings of other components, in other cases, relaxing the architecture as it pertains to this element may be deemed acceptable. In any case, no work-around should occur without the architect’s knowledge and consent, at the risk of weakening the architecture, and therefore the robustness of the system.
Perhaps the most prominent aspect of the software architect position is that it is one of leadership. The flavor of leadership may vary a bit from organization to organization, but ordinarily the software architect has, at least, technical authority over the construction of the software within his or her architectural domain. Some organizations push this a bit further, making the architect the project manager, or delegate to him much of that authority. Other organizations relax this, making it more of an advisory or mentorship role. For complex project, the former practice can overwhelm the architect, leaving too little time for development and maintenance of the architecture. Except in the simplest projects, the latter practice will eventually result in a breakdown of the architecture.
While the development standards may require conformity to the established software architecture, without one or more individuals specifically tasked with enforcement, architectural violations will occur. Architectures can be complex, and variations in interpretation lead to missteps. When these missteps occur and repair would incur a cost, a project manager without the benefit of architectural understanding, may permit a weakening of the architecture for the perception of a short-term cost savings.
The software architect need not be a project manager, but must have final authority on all technical issues that related to the architecture. This can be a difficult position for the uninitiated project manager to support, particularly when the budget or schedule slippages appear imminent. For that reason, it may be best to keep the architecture function independent of project management in some cases. The largest single benefit of strong architecture is full lifecycle cost savings; but in the heat of the moment, paying later can look pretty good.
One more face of the software architect that is often overlooked, is that of the educator. Too often, a strong architecture is developed and documented, then just dumped on the development team. Documentation for an architecture can be quite daunting, often exceeding several hundred pages. Very few of the development team will be given time to read and completely absorb all of the material, yet all will be impacted by it. All designers, programmers and analysts should be familiar with the key aspects of the architecture. This is probably best accomplished through classroom training; and should be supplemented with an abbreviated on-line, multi-media walkthrough that can be reviewed later, or used as an introduction for those developers that invariably come in later in the project.
A high level overview presentation should also be developed for management and other stakeholders. This presentation should be designed to illustrate how specific architectural elements improve the quality of the software product, as well as the productivity of the overall effort. Long-term benefits should be mentioned here, but nearer term benefits should be emphasized. The goal of this presentation is to provide management with the impetus to support the integrity of the architecture even when doing so seems to conflict with more immediate concerns.
Throughout this article, we have referred to the software architect as a single person. In reality, there may be an architecture group performing the bulk of the work. They may be full-time in that function, or they may be regular developers assigned tasks in support of the architecture function. No matter how the assignment of tasks may be delegated, there should always be a single supervising software architect who holds ultimate authority and responsibility for ensuring that the integrity of the software architecture is upheld.
|
Max is a father, a husband, and a man of many interests. He is also a consulting software architect with over 3 decades experience in the design and implementation of complex software. View his Linked-In profile at http://www.linkedin.com/pro/swarchitect |