Architecting is about balancing

?

Architecting is about balancing

Randy Stafford

Balance stakeholders ' interests with Technical Requirements
When we THinK of architecting software, we tend to THinK first of classical technical activities, like modularizing system s, defining interfaces, allocating responsibility, applying patterns, and optimizing performance. Architects also need to consider security, usability, supportability, Release management, and deployment options, among OT Her things. But these techni-cal and procedural issues must is balanced with the needs of stakeholders and their interests. Taking a "stakeholders and interests" approach in requirements analysis are an excellent-to ensure completeness of requ Irements specifica-tions for the software being developed.
Analyzing the stakeholders and their interests in the process by which a orga-nization develops software, and in the Org Anization itself, reveals the ultimate set of priorities bearing on a software architect. Software architecting is on balancing this set of priorities, over the short and long term, in a to E to the context at hand.
Consider, for example, the engineering department of a Software-as-a-service business. The business likely have certain priorities, such as meeting contractual obligations, generating revenue, ensuring customer Referenceability, containing costs, and creating valuable technology assets. These business priorities could translate to departmental priorities like ensuring the functionality, correctness,
??? Things every software Architect should Know
?
?? and "Quality attributes" (i.e, "-ilities") of the software being developed, as well as ensuring the productivity of the D Evelopment team, the sustainability and auditability of development operations, and 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's CEO, with the ease-of-administration Interests of the operations staff, with the ease-of-learning and ease-of-maintenance interests of the future programming Staf F, and with the best practices of the software architect ' s profession.
The architect choose to consciously tilt the balance in favor of one prior-ity in the short term, but had better main Tain a proper balance over the long term in order to truly does the job well. And the balance that's struck needs to being appropriate to the context at hand, in consideration of factors such as the EXP ected lifespan of the software, the criticality of the software to the business, and the technological and financial CULTU Re of the organization.
In summary, software architecting are about more than just the classical techni-cal activities; It is about balancing technical requirements and the business requirements of stakeholders in the project.

Architecting is about balancing