200 OK SwatantrAI

97 Things Every Software Architect Should Know – 6/97

Often customers and end-users state what they think is a viable solution to a problem as a requirement. The classical story on this was told by Harry Hillaker, the lead designer of the F-16 Falcon. His team was requested to design a Mach 2 – 2.5 aircraft, which was then, and probably still is, a non-trivial task – especially when the objective is to create “cheap” lightweight aircraft. Remember that the force required to overcome drag quadruples when doubling the speed, and what impact that have on aircraft weight.

When the design team asked the air force why they needed Mach 2 – 2.5, the answer was to be able to escape from combat. With the real need on the table the design team was able to address the root problem and provide a working solution. Their solution was an agile aircraft with a high thrust-to-weight ratio, providing acceleration and maneuverability, not maximum speed.

This lesson should be brought into software development as well. By asking for the value to be provided by a requested feature or requirement architects are able address the real problem, and hopefully provide a better and cheaper solution compared to addressing the solution suggested by the client. The focus on value also simplifies prioritization. The most valuable requirements become the driving requirements.

So, how to proceed then? In many ways the required approach is found in the agile manifesto: “Collaboration over contract”. Practically speaking this implies arranging workshops and meetings where the architects focus are on customer needs, helping the customers to answer the “why” question. Be aware that answering the “why” question can be difficult because we very often talk about tacit knowledge. Discussions on how to provide a technical solution should be avoided in these workshops, because they move the discussions away from the customer‘s domain and into the domain of software development.

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.