97 Things Every Software Architect Should Know

Chapter 14. Architecting Is About Balancing

Randy Stafford is a practicing software professional with 20 years' experience as a developer, analyst, architect, manager, consultant, and author/presenter.

Currently for Oracle's middleware development A-Team, he engages globally for proof-of-concept projects, architecture reviews, and production crises with diverse customer organizations, specializing in grid, SOA, performance, HA, and JEE/ORM work.

—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 systems, defining interfaces, allocating responsibility, applying patterns, and optimizing performance. Architects also need to consider security, usability, supportability, release management, and deployment options, among other things. But these technical and procedural issues must be balanced with the needs of stakeholders and their interests. Taking a "stakeholders and interests" approach in requirements analysis is an excellent way to ensure completeness of requirements specifications for the software being developed.

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 ...