Some sort of Indirection

There is a quotation from a British Computer Scientist, David John Wheeler, I do really like: “Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem." I know, it is not new and we all know about the meaning behind it but it is still relevant today and tomorrow, and it describes the dilemma of many
“genericcontainerwrappingadaptergatewayframeworkolalasolutions” perfectly.

Handling of Non-Functional Requirements

Non-Functional Requirements (aka Quality Attributes) are the „bread and butter business" for software architects. Unfortunately, non-functional requirements are often abstract and hard to grasp. A good approach to tackle this are so-called “utility trees”. Utility trees list important non-functional requirements (say security, usability and performance) in a tree structure; beginning with “utility as root”. It’s a good approach to use the list for a first prioritization. Each level in the utility tree represents a refinement of the non-functional requirement and ends with leaves. Leaves are scenarios. And this is a good approach from my point of view. A scenario is easier to comprehend for all stakeholders. It is based on the - Context Stimulus Response Pattern – and should lead to a decent understanding what, for instance, security really means for a software product. I will present an example in one of my upcoming posts.

Dresden: River Elbe View, January 2008

River Elbe Valley, January 2008
No bridge is cutting up the landscape, not yet.

Software Architecture and Feasibility

The following situation is well known. (Too) many requirements are compiled by the stakeholders of a software project. Everybody wants everything in terms of features and functionalities performed by the software product that should be called “monkey wrench”. It’s not possible to say simply yes or no about feasibility just from reading the requirements. Beside the fact that we all adhere to the KISS-rule, a well documented architecture can help to understand the intended solution and to identify contradictions in the requirements. Just one example: some requirements might ask for client implementations based on key features like high availability and a rich feature set in terms of user interaction. On the other hand, requirements coming from another group of stakeholders may request communication technologies and strong perimeter protection that will never support the features requested for the clients. A well-documented software architecture that encompasses different views of the software product can help to detect such contradictions early enough. Experts from different domains - say network, application server, and security, can use the architecture to assess the outlined approach. And even for the folks requesting all the important functions, it might be helpful to see their product in a very early state (with the chance to reconsider some decisions).