Contribution 5

From WikiContent

Revision as of 03:31, 20 June 2008 by Rstafford (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Architecting is About Balancing...

When we think of architecting software, we tend to think first of classical technical activities, like modularizing systems, defining interfaces, allocating responsibility, applying patterns, and optimizing performance.

Experienced architects understand that there exists a realm beyond these classical activities, as finally elaborated by Luke Hohmann in his groundbreaking book Beyond Software Architecture [Hohmann BSA], consisting of additional issues that must be resolved in order to create a winning business solution.

These additional issues, which can also be considered architectural in nature, include security, usability, supportability, release management, and deployment options, among others, and reveal certain interests of the stakeholders in the software being developed.

Taking such a “stakeholders and interests” approach in requirements analysis (as described by Alistair Cockburn in his brilliant book Writing Effective Use Cases [Cockburn WEUC]) is an excellent way to ensure completeness of requirements specifications for the software being developed.

But, more broadly, analyzing the stakeholders, and their interests, in the process by which an organization develops software, and in the organization itself, reveals the ultimate set of priorities bearing on a software architect. Software architecting is about balancing this set of priorities, over the short and long term, in a way that is appropriate to the context at hand.

Consider, for example, the engineering department of a software-as-a-service business. The business likely has certain priorities, such as meeting contractual obligations, generating revenue, ensuring customer referenceability, containing costs, and creating valuable technology assets. These business priorities may translate to departmental priorities like ensuring the functionality and correctness, and “quality attributes” (i.e. “-ilities”) of the software being developed, as well as ensuring the productivity of the development team, ensuring the sustainability and auditability of development operations, and ensuring the adaptability and longevity of the software products.

It is the architect’s job to not only create functional, quality software for users, but also to do so while balancing the other departmental priorities, with the cost containment interests of the business’s CEO, with the ease-of-administration interests of the operations staff, with the ease-of-learning and ease-of-maintenance interests of future programming staff, and with best practices of the software architect’s profession.

The architect may choose to consciously tilt the balance in favor of one priority in the short term, but had better maintain a proper balance over the long term in order to truly do the job well. And the balance that is struck needs to be appropriate to the context at hand, considering factors such as the expected lifespan of the software, the criticality of the software to the business, and the technological and financial culture of the organization.

In summary, software architecting is about more than just the classical technical activities; it is about balancing a broad set of potentially conflicting priorities, sometimes trading off desired advances in one direction for necessary achievements in another direction.

By Randy Stafford

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Software Architect Should Know home page

Personal tools