BA372 - Architecture

Hohmann, L. (2005) Beyond Software Architecture. Addison-Wesley.

• Goal: Create winning (sustainable) solutions:
•  "Move beyond software architecture and move toward understanding and embracing the business issues..." (xxv).
• Directed toward enterprise applications:
• Serves the needs of a business or business community; e.g., a department or whole organizations.
• Expensive to develop and maintain.
• Complex deployment and operational requirements.
• Integrated with other applications.

• Practical approach: collaboration and mutual (technical and business) understanding.

• Strategic role of technical breakthroughs is diminishing (Carr: Utility computing).

• Good business model trumps a good technical model.

• Business issues cannot and should not be separated from technical issues.

• Build operational business issues into your systems; e.g., log files, error reporting,  user tracking, etc.
  

• Software architecture:
• p. 1. "The foundation of a winning solution lies in the architecture that creates and sustains it."
  
• Problem: what's a software architecture?
• System theoretical view: "basic "structure" of the system... (p.1).
  • Elements.
  • Relationships.
  • Structure.
  • Information systems are dynamic; i.e., they have behavior.
  • State & state transitions: S_t+1 = S_t + ΔS ==> state space.
  • Environment and boundary.
  • Inputs transfer messages (data/information) from the environment or from elements to other elements.
  • Outputs transfer messages from the elements to other elements or to the environment.
  • Open systems accept input from the environment; closed systems do not.
  • Problem: are information systems closed or open?
    
  • Systems which change their behavior patterns as a consequence of their openness are adaptive systems.
  • Problem: are information systems adaptive?
  • An element can be a system by itself (subsystem).
  • An element modeled as if it has no structure is a black box.
  • Problem: What would the term black box testing mean?

• Second Law of Thermodynamics {S=kLnW}: tendency of a (closed) system to transfer into a state of lower energy (the entropy page).
• Careful; the interpretation of entropy as 'disorder' is entirely a human interpretation.
• To maintain or decrease entropy, a system must absorb energy; i.e., increase entropy elsewhere.
• Problem: does entropy apply to information systems?
• Problem: what's the relationship between the system theoretical notion of entropy and the information theoretical notion of entropy (recall Shannon's equation)?
  
• Problem: explain Hohmann's concepts of technical debt and entropy reduction (ER) (p. 14-15)?

• What is ER not?

• What are regression tests? (p. 14)
• Hohmann  (p.1.) recommends inclusion of two additional (prescriptive) characteristics into the definition of architecture:

• technology constraints.
• capability constraints.

• Important human and business considerations in specifying and evaluating system architectures:
• Regarding system structure:  strive for "the simplest possible dependencies among development organizations." (p 2).

• Problem: do you see any relationships between this position and Kock's notion of hypercommunication?
  
• "Design (sub)systems to create a sense of wholeness " (p. 3).
  
• Problem: do you see a relationship between this recommendation and the various schools of management theory discussed by Kock?
• Problem: can you see disadvantages of following this advise (staffing ≠ consulting).

• Give in to great architectures.

• Problem: do we know what this means?
• Beauty is in the eye of the beholder:
• Equally valid but conflicting theories or approaches:
• Stored procedures vs. application layer (see also p. 160).
• Good analysis now vs. rapid prototyping.
• Does the sun orbit the earth or is the earth rotating away from the sun? (N.R. Hanson (1965) about Tycho Brahe and Johannes Kepler).

• Why does architecture matter?
• Longevity: architectural SDLC = 12-30 years.
• Stability: architecture is the most stable (as in 'static' rather than 'reliable') component of a system ==> foundation => predictability.
• Good architecture makes for easy extension and scaling; e.g., plug-in architectures:

• Particularly important in open source products; e.g., the gimp.
  
• Profitable: "can sustain it with an acceptable cost structure."


• Architecture and team structure reinforce each other.
• Technical expertise.
• Shared mental model.
• Shared normative model.

• Architecture determines the boundary between what's in and what's out ==> architecture & capabilities correspond.
  

• When to replace? (p. 6)
  
• Tough(!!) question to answer; expensive either way.
  
• Needed when:
• Extensions and new capabilities are needed, yet do not fit. Recall Dally's 'fit!'
• Irony: Success breeding failure (p. 13)!
• Working in the old architecture implies building up technical debt:
• principal: cost of creating the required underlying capabilities.
• capability: capacity to support specific features.

• interest: sustaining a new feature in an architecture not designed to support it.
• interest compounds with new releases and increasing complexity.
• system entropy increases with new releases.

• entropy reduction: paying off technical debt.
• Example: XML document template versioning in TE.
  
• ER is good, but it is not a replacement for architecture renewal.

• Entropy reduction costs are (becoming) too high.
• Newer technology makes the extensions easy to implement.
• The first/second/third time round was/were only so-so; e.g., RSS (Lisp/Unix)-->RSS' (C++/Unix)-->PRSYM (C++/Unix)-->RiverWare(C++, UNIX/Windows).
  

• Hohmann's advise:
  
• Replace if it can be done by half the team within one year.
• Some of the people on the team must be replaced (too much buy-in/interest associated with the old architecture).
• Replacing all people on the team is not a good idea.
  
• Cost of architectural overhaul is ≈ 20% of cost of SDLC of old system... at best!! (40-60% is more common).

• Creating an architecture:
• Textbooks (and our class project!): explore different architectures.
• Hohmann: reasonable but not realistic:
• Lack of time.
• Most application domains only offer one or two reasonable alternatives or patterns.
• Must try to find out.

• What makes for a good architecture?
• Technical:

1. Encapsulation: enclosure of system elements inside larger, more abstract entities; black box model.
2. Interfaces: rather than have element A talk to B, have them talk to a generic intermediate C; e.g. streams or ODBC.
3. Parameterization: core functionality is fixed; all the rest is data; open black box.

• 1 - 3 imply loose coupling & modularity: system parts can easily be replaced without affecting other parts.
• Team:
• Shared understanding (Rational 4+1):
• Logical or structural view.
• Process view.
• Development view.
• Physical view.
• Scenarios.

• Leadership by a few, capable architects.