Sunday, December 20, 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®

Thursday, December 03, 2009

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:

  1. 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.
  2. handling quality attributes
    • 0—There is no consensus on quality attributes.
    • 10—Quality attributes are linked to business and engineering needs and are quantitatively specified.
  3. architectural automation
    • 0—There is no support for architectural automation; description consists of human language on paper.
    • 10—Language for architecture is the base language for automation.
  1. architectural specificity
    • 0—Reasoning is limited to specific elements (hardware, network, software, etc.) and the relationships known by the architect.
    • 10—Architects employ reasoning about guidelines, constraints, quality attributes—self-adaptive systems.
  1. architectural responsibility—degree to which an architect is responsible
    • 0—There is no explicit recognition of responsibility. The worst case is having responsibility and no authority.
    • 10—A clear definition of responsibility and authority exists for the architect’s role. Responsibility is sufficient to deliver the function and quality attributes of the system to its stakeholders over time.
  1. accidental versus intentional architects
    • 0—Architects have no explicit training, no career path, no formal explicit recognition, no experience threshold (relating problems to domain, development, implementation, failed, organization, etc.).
    • 10—Architects are chosen intentionally for their ability.
  1. domain versatility and adaptability
    • 0—The architect has a one-track mind.
    • 10—The architect is pragmatic and inquiring—able to organize information.
  1. architecting process—maturity of architectural choices
    • 0—Diverse solutions and techniques exist, but the choice is arbitrary.
    • 10—There is a clear linkage between architecture goals and the choice of process and techniques.
  1. technology dependency—Technology is a tool.
    • 0—Architecture is constrained by the existing technology.
    • 10—Architecture is fearless, specifying the abstract solution without necessarily any bindings to existing technology. Architecture is not constrained by existing technology. A fearless architecture is one that might influence future technology.
  1. creating versus choosing an architecture
    • 0—No previous solutions are reused.
    • 10—The solution already exists (not accounting for the details)—looking at previous solutions and reusing them.
  1. complexity
    • 0—Complexity is low.
    • 10—Architecture is produced for complicated and complex systems with emergent behavior.
  1. interdisciplinary architecture
    • 0—A single discipline is fully understood (e.g., information architecture, enterprise architecture).
    • 10—Multiple disciplines are fully integrated. Stakeholders’ perspectives are met.
See source here.

Constantin Kostenko
Firebrand Architect®

Wednesday, December 02, 2009

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:

Constantin Kostenko
Firebrand Architect®

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...