Showing posts from December, 2009

Anyone can takeoff, can anyone land?

Oh prototypes. We love them, clients love them, users love them. They help with requirements and sometimes help us answer architecturally significant questions.
But early success creates a false sense of security. A successful prototype that a senior manager or a customer loves cannot always be operationalized in a matter of days or weeks. If fundamental quality attributes of software have not been thought through (e.g. security, scalability, performance, etc.) it's impossible to add that on later.
Solution? Manage the expectations of your audience. Explain the limitations before they see a demo - and discuss next steps right after prototype presentation.
Developing software intensive solutions without thinking through architecture is like taking an airplane into the air. Anyone can take off, but only pilots can land.
Constantin Kostenko
Firebrand Architect®

12 dimensions of the space of architecture

On what dimensions may the discipline of software architecture change over time?
Here is what the thought leaders in the field put together during the IFIP Working Group 2.10.
12 dimensions of the space of architecture:codification and socialization—processes by which an architect communicates architectural ideas to stakeholders. Codification refers to specification of the architecture, while socialization refers to the less formal processes by which the architecture is internalized. Socialization can happen through conversation, training, and so forth. Codification and socialization are complementary processes; they should enforce each other.0—Codification and socialization do not occur.10— Codification and socialization are in balance with each other; socialization becomes a process for codification; socialization and codification enforce each other and work in a global environment.handling quality attributes0—There is no consensus on quality attributes.10—Quality attributes are linke…

Wiki for Architecture Documentation & Managing Your Project

The idea of using a Wiki to manage coordination and artifact development as part of your software development is not new. The concept and tools have matured to a point where even the most monolithic organizations involved in development of large software intensive solutions are using this.
The goal of using a Wiki is simple: keep artifacts current through collaborative ownership.

The multitude of successful open source projects using a Wiki based approach is the best justification why a community based approach works. Additionally, a perspective from academia centric sources, with associated analysis, will help you build a business case.
If you're considering pursuing a Wiki based approach consider the following resources: Experience Using the Web-Based Tool Wiki for Architecture Documentation (thorough and free report based on actual project experiences - SEI). Blurb.On-line collaborative software development via wiki (from Proceedings of the 2007 international symposium on Wikis -…