I just completed the SEI training course on documenting software architectures and I have some thoughts about how architecture is sold. I use the term "sold" very specifically since I believe that architecture always happens within the context of an organization which is largely it's management context. Since a recurring theme in these seminars, and in the pragmatic side of software architectures, is the conflict between management and software architects, I cannot help but ponder how this tension might be resolved.
Management of any large project is largely shaped by that organization's management organization, culture, policies, practices and procedures. The architect can change this within the context of a project in only the most constrained ways. Since what is suggested by the architect may conflict with the path of least resistance for project management, the architect must be prepared to justify the proposal with a logical argument but also sell the idea by the use of extra-logical methods. I think SEI does as good a job as can be done in making the logical arguments in favor of an architecture-centric approach. But the extra-logical methods are outside their scope. Selling is the term I use to encompass these extra-logical methods, and tactics.
Managers, particularly senior managers, respond favorably to the idea of strategy. By rebranding the effort of software architecture as project strategic design I think it more nearly hits the mark in what motivates the effort in the mind of the manager. To fail strategically suggests that some war or wars may have been won but in the end the mission was not accomplished. This is precisely what an architecture aims to achieve. There are a set of quality and functional requirements that define risk points for this project. The architecture and its creation seeks to specifically identify these concerns, capture them in a way that can be shared and certified and then used to methodically drive a design that demonstrably addresses those risks with a design (planned design). I want to believe that this message will resonate more effectively in the mind of the decision maker and motivate at least an open mind, if not an open wallet.
I see that this recast of the architecture as a strategic document also helps to define a clearer scope. Once the strategic risks have been dealt with to the satisfaction of the most senior members of the project team, it is time to activate the implied (or explicit?) plan that is the architecture document. If parallelism in the development is a concern at the outset, the major modules will have been designated and designed in such a way as to provide the input to the initiation of those phases of the project. If security is a concern, there must be sufficient design as to ensure that the concern can be reasonably argued as to have been mitigated.
It is interesting to note that this is how the boundary between what used to be called high-level and low-level design breaks down. If the original concept of operations will use hardware or external components that are believed to represent some risk to this project's mission, the project architect will need to continue the decomposition of those aspects of the design until there is persuasive evidence that this quality can be achieved (but not necessarily achieved) by use of the design so far elaborated. But once the decision has been made that the risk of not achieving that quality has been answered, the further elaboration of the architecture must stop.
Again, one aspect of the architect's job is to help project management with this decision and provide the leadership they will look for. If project management continues to doubt the achievability of some quality, they may continue to ask for further elaboration of the design. At some point, this design can over specify the system to be constructed. This in itself creates a new risk to the project. Over-specification reduces the solution space for the developer charged with the design and construction. If the architect has expertise equal to or greater than the development organization to which it is delegated, this may be good. But the nature of architecture, and the inherent role of the architect, is to be somewhat removed from all the various technologies that will be brought to bear with in the consolidated solution space. Therefore it is just as likely that the delegated organization will possess technical skills in the technology that the architect does not possess and therefore can create a design that is superior to any from the architecture. Again the architect is forced to possess some skills in leader a management group through a decision making process. The parallel between strategic and tactical decisions should be familiar language to this group and hopefully persuade them to belabor the point beyond its management purpose.
There are some ways in which a re-branding of the effort as strategic design can be challenging. This would be an unfamiliar term to the team members and some time will need to be spent explaining it. A natural confusion will arise in differentiating what I am calling strategic design from strategic planning. I am not aware of any use of strategic planning as an activity within the context of the project and of course its purpose is very different in the context of organizational planning. However the connotation of risks, opportunities and constraints used in strategic planning provides the architect with some handy cognitive landmarks to broach the themes of the software architecture.
Another issue with the branding as strategic design is the loss of distinction between software architecture and system architecture. SEI's work is always identified as software architecture. However there have been some reports that have begun to talk about software intensive systems architecture rather than software architectures. Even within this course there was an acknowledgement of the necessity of considering hardware as well as software. Perhaps it would be a good thing to let the term shift to suggest that both are considered when making the strategic decisions that could make or break the project.
I hope I have provided the outline for what I believe is a shift in labeling that could empower the architect to more effectively negotiate with project management and increase the use of architecture centric techniques in industry.
No comments:
Post a Comment