Categories
Software Architect

Architecting is about balancing

Book: 97 Things Every Software Architect Should Know
Publisher: O’Reilly Media
Author: Richard Monson-Haefel

'Coz sharing is caring

97 Things Every Software Architect Should Know – 5/97

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 others 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 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 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 technical requirements with the business requirements of stakeholders in the project.

'Coz sharing is caring

By Swatantra Kumar

Swatantra is an Open Source evangelist, a technologist and researcher. Professionally, he does software development, software architecture, server administration and project management. When he's not writing software, he enjoys building web entities and servers, reading about and working with new technologies, and trying to get his friends to make the move to open source software. He's written, co-written and published many articles in international journals, on various domains/topics including Open Source, Networks, Computer Organization, Mobile Technologies, and Business Intelligence. He made a proposal for an information management system at University level during graduation days.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.