Home | Login | Recent Changes | Search | All Pages | Help

SoftwareArchitectureSessionNotes

What the Heck is "Software Architecture" (Session 13): Notes from the Session

The purpose of the session was to identify and discuss the components of a working definition of what software architecture is.

To start, we went around the room and each of us briefly described themselves and their current thoughts and feelings about software architecture. This process showed that we had a very experienced and knowledgeable group surrounding the ideas of what software architecture is.

Then, we took an hour in small groups to discuss the question and to present to the full group the components of our working definition. Based on the flip chart pages from the session, those components are:

Group 1 (because its flip charts pages were first in my stack�)

  • Topness, Wholeness, Big Picture
  • Responsibility/Accountability
    • Validate analysis/requirements
    • Communication/translation
  • Chooses the decisions that are important at this level
  • Which decisions can pushed down
  • Risk
    • Analysis
    • Control
    • Mitigation
  • Knows when to stop

Group 2

  • Study of software and how it is built
    • History
    • Varieties
      • Client server
    • apprenticeship
    • architectural styles
      • multi-tiered
  • What are the responsibilities of a software architect?
    • Responsible to ensure that the system doesn't fail
    • Responsible for the long term success or value
    • Responsible for knowledge transfer
    • Responsible for communication
    • Responsible for who is the customer
    • Responsible to the customer
    • Responsible for providing advice to the client
    • Responsible for customer's long term satisfaction and widening the customer's field of vision
    • Responsible for articulating relevant trade-offs to the customer
  • Requirements - functional + nonfunctional
    • Responsible for considering how the work can be divided
    • Responsible for making the system understandable for those who need to understand
    • Responsible for seeing what is important happens
    • Responsible for making sure that the system is reviewed before it is built
    • Responsible for testability
    • Responsible to review the performance and expertise of the builders.

Group 3

  • Two main parts
    • Human interaction
      • Chief arbiter
      • Customer educator
      • Prime intermediary
      • Understanding use - present and future
      • Synthesis
      • Visionary
      • Stewardship
      • Bridge
    • Technical Component
      • Awareness of what is in/out
      • Multiple languages
        • Architecture (?)
        • Engineering
        • Customer
        • Process
      • Architectural policies
      • Design discipline

Group 4 (from which I do not have flip chart pages)

  • Structure for time component of architecture based on "How Buildings Learn" by Stewart Brand and a potential metaphor for software architecture
    • Site is eternal
    • Structure is good for 30 to 300 years
    • Skin now changes every 15 to 20 years
    • Services (wiring, plumbing, kitchen appliances, heating and cooling) change every seven to 15 years
    • Spaces change two or three years
    • Stuff change continually
  • Then, consider that an application development project can start at any of these levels
    • Constraints (or givens) come from the layers above
    • Requirements come from the layers below
  • An architect must be able to:
    • understand the impacts or risks of satisfying the constraints and meeting the requirements in the given layer
    • communicate those impacts and risks to those people who need to know

We just had time for each group to present.

Miscellaneous questions and comments (that were written down�)

  1. Is it (software architect) a role name for chief arbiter/synthesizer?
  2. Is it a group of principles/guidelines for design?
  3. Is it a threshold beyond which it becomes too abstract to be called design?
  4. Aren't we asking the architect to be a superman? How can the architect gain help in understanding from the other people?
  5. Standard gauge rails 4 ft 8.5 in - from carriage wheel spacing from roman war chariots (since ruts break wheels with different spacing) - from space needed for two horses asses.
  6. Proposed answer: Architecture is where the lifetime users of artifact are served by the designs and choices made. (including neighbors)
  7. Proposed answer: Architecture is the material which permits other people to put the specific design choices into context with each other and the purposes.

Thank you all for participating

The next step was (and continues to be) to begin to synthesize this information into something shared among the group. I am not sure how to proceed with that. Getting these notes out and into the ether is sure to help with that process.

by Jack Ring -- Not sure I am posting this in the right place but it seems to me that the bulk of the above simply remarks on various aspects of the activity called systems engineering in another tribe and knowledge management in yet another tribe. Accordingly, a way of organizing all these ideas may be to use the SE Process descriptions as published by the Electronics Industries Association standard #632. Also, the ISO 15288 is attempting to harmonize the systems design views of software and systems tribes. I am not a great fan of standards but suggest this only as a possible framework for organzing the AYE ideas.
Thank you. I will check them out. BobKing
So, I did check them out - a little. They feel to me like someone is trying to create a process model of what architecture is. I am not sure that this medium is sufficient to fully describe my conception of what the practice architecture is. Did anybody else check these things out?

Something that I found which might be related and with which I have the same reservations can be found at: http://www.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/Tutorial_Slides/Soft_Arch/quick_index.html

Thanks, BobKing

Updated: Monday, December 4, 2000