0 Replies Latest reply on Sep 7, 2017 11:20 PM by nerzovugno

    An architecture balances stakeholder needs

      An architecture is created to ultimately address a set of stakeholder needs. However, it is often not possible to meet all of the needs expressed. For example, a stakeholder may ask for some functionality within a specified timeframe, but these two needs (functionality and timeframe) are mutually exclusive. Either the scope can be reduced in order to meet the schedule or all of the functionality can be provided within an extended timeframe. Similarly, different stakeholders may express conflicting needs and, again, an appropriate balance must be achieved. Making tradeoffs is therefore an essential aspect of the architecting process, and negotiation, an essential characteristic of the architect.

      Just to give you an idea of the task at hand, consider the following needs of a set of stakeholders:

      • The end user is concerned with intuitive and correct behavior, performance, reliability, usability, availability, and security.
      • The system administrator is concerned with intuitive behavior, administration, and tools to aid monitoring.
      • The marketer is concerned with competitive features, time to market, positioning with other products, and cost.
      • The customer is concerned with cost, stability, and schedule.
      • The developer is concerned with clear requirements, and a simple and consistent design approach.
      • The project manager is concerned with predictability in the tracking of the project, schedule, productive use of resources, and budget.
      • The maintainer is concerned with a comprehensible, consistent, and documented design approach, and the ease with which modifications can be made.

      As we can see from this list, another challenge for the architect is that the stakeholders are not only concerned that the system provides the required functionality. Many of the concerns listed are nonfunctional in nature in that they do not contribute to the functionality of the system (e.g., the concerns regarding costs and scheduling). Such concerns nevertheless represent system qualities or constraints. Nonfunctional requirements are quite often the most significant requirements as far as an architect is concerned.