• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (1)

1 localhost commented Permalink

For me "architectural thinking" means considering all aspects of the application solution domain. The one aspect that most think about is the functional domain: functional requirements (intent), engineering process (delivery), and structure (components/patterns/design). I believe other equally important aspects are often overlooked. These include the non-functional domain, operational domain, and business constraints domain. The non-functional domain, or the 'ilities, are aspects such as reliability, availability, performance, usability, etc. The operational domain are aspects set by production environment; for example the number of servers, support staff, system monitoring equipment, geographical distribution, etc. Finally, the business constraints domain are aspects that set boundaries on the development and implementation; for example, delivery schedules, developer resources, rollout issues, etc.When taking these other aspects into consideration, the quality of an application is no longer how well it satisfies the functional requirements. Instead, the quality of an application is how well is does what a user wants, when the user wants, with expected value (cost vs benefit).As a result, with this view of quality, it is possible to have beautifully written code using the best-of-breed practices with patterns and components and still fail from a user's point-of-view because it didn't address the quality aspects (runs too slow, down too often, poor user interface, costs too much to maintain or operate, etc).

Add a Comment Add a Comment