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®

No comments:

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...