BA372 — Architecture
- System architecture is the 'computational model' of your application (the structure of your software system).
- Why does architecture matter?
- Hohmann's goal: "Create winning (sustainable) solutions":
- "Move beyond software
architecture and move toward understanding and embracing the business issues..." (xxv).
- Recall the epistemological vs. information theoretical view of 'information.'
- Recall the frequent misconception between CIOs and CEOs?
- Problem: What is the job of a business's IT function?
Cummings in 'Jack of Two Trades' (Computerworld, Apr. 2013): "We need IT to be the kind of organization that,
if you're on the business side, we know the problem before you know it.... These people...can show me that they understand what the
business problem is and produce a bunch of creative ways to solve it."
- "Managing the interrelationships between technology and business will be a recurring theme
throughout this book." (p. xxvii)
- Directed toward enterprise applications:
- Serve the needs of a business or business community; e.g., a department or
- Typically expensive to develop and maintain. (RR: cost are coming down rapidly).
- Complex deployment and operational requirements (RR: these have improved immensely in recent years).
- Integrated with other applications.
- Practical approach: collaboration and mutual (technical and business) understanding.
- Build operational infrastructure into your systems; e.g.,
log files, error/bug reporting, user tracking, user meetings/forums/conferences, follow security protocols, constant testing, etc.
- p. 1. "The foundation of a winning solution lies in the architecture that creates and sustains it."Three (very) classic components of information systems:
- Data logic.
- Business logic.
- Presentation logic.
- System architecture: distribution of IS functions over system components.
- Hohmann adopts an explicitly system theoretical view: "basic structure of
the system..." (p.1).
- Elements, relationships, black boxes, subsystems, feedback, states, open/closed, etc.
- Reserves a very special place for
- Practical example: 'Linkrot': "As I reviewed projects featured in the book,
I was astounded by how many bad links and error messages I encountered. Some of these projects
became completely untraceable, possibly gone forever.
...The reasons for this vanishing are never the same. In most instances, pieces are simply neglected over time,
with authors not bothering to update the code, rendering it obsolete. In other cases, the plug-in version might
become incapable of reading older formats or the application programming interface (API) from an early
data-set source might change, making it extremely difficult to reuse the code that generated the original visualization.
Lastly, projects are occasionally moved into different folders or domains or just taken down from the servers,
simply because they highlight an outdated model that does not fit the current
ambitions of their respective author or company.
...Overall, this digital laissez-faire contributes to the ephemeral lifespan of most online visualizations,
and consequently the whole field suffers from memory loss)."
(© permission by the publisher: Lima, M. (2011)
Visual Complexity. Mapping Patterns of Information. Princeton Architectural Press.)
- Problem: does entropy apply to information
explain Hohmann's concepts of technical debt and entropy reduction (ER) (p. 14-15)?
- Hohmann (p. 14): "Entropy Reduction: Paying off Technical Debt after Every Release."
- Hohmann (p. 14): "Entropy reduction is not about making substantial changes to the architecture..."
- Problem: What do you think about this notion of entropy?
- Problem: is 'our' interpretation of the concept of
entropy different from Hohmann's?
- TeachEngineering link rot
- Problem: Which HTTP request method do we use to see if links are live or not?
- Hohmann: ER should be a normal part of the design—release—maintain cycle:
- kluge /klooj/ [from the German `klug', clever; poss. related to Polish
`klucz' (a key, a hint, a main point)] 1. n. A Rube Goldberg (or Heath
Robinson) device, whether in hardware or software. 2. n. A clever
programming trick intended to solve a particular nasty case in an
expedient, if not clear, manner. Often used to repair bugs. Often
involves ad-hockery and verges on being a crock. 3. n. Something
that works for the wrong reason. 4. vt. To insert a kluge into a
program. "I've kluged this routine to get around that weird bug, but
there's probably a better way." 5. [WPI] n. A feature that is
implemented in a rude manner (courtesy of gnome-dictionary)
- Kluges aka 'hacks' are a bit like paying off one credit card with another. A good kluge may solve a lot of immediate problems,
but it will not lower technical debt.
- Some good ER practices (p. 15):
- Tag/comment code (and kluges!!) for later fixes (RR: does not only apply to coding; applies to any and all forms of modeling, computation, etc.).
- ER rhythm —> schedule regular/periodic ER activities (time boxing).
- Don't ship (after ER) without a full regression test!!
- Use ER as a tool for fostering quality mindedness.
- Remember from above: profitable architecture: "can sustain it with an acceptable cost
structure." —> can sustain technical debt with entropy reduction.
- Important human and business considerations in specifying and evaluating system architectures:
- Regarding system structure:
strive for "the
simplest possible dependencies among development organizations."
- Modularity; independent development,
testing and maintenance of components.
- "Designing (sub)systems to create a sense of wholeness" (p. 3).
- Allow developers to participate in multiple aspects/parts of the system.
- 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.
- "Give in to great architectures... let the problem domain guide you" (p. 3).
- "Beauty is in the eye of the beholder" (p. 4) (RR: which does NOT imply that we can do whatever we want):
- Equally valid but conflicting approaches:
- When to replace? (p. 6)
- Tough(!!) question to answer; expensive either way:
- Maintenance, modifications and extensions are becoming too expensive (too big a resource draw).
- Building a system from scratch is expensive and risky.
- Needed when:
- Extensions and new capabilities are needed, yet do not 'fit' the existing architecture (Recall Dally's 'fit!').
- Irony: Success breeding failure (p. 13)!
- Working in the old architecture implies building up additional technical debt:
- principal: cost of creating the required but lacking
capabilities; i.e., 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
- Entropy reduction costs are (becoming) too high.
- Newer technology makes the extensions easy/(less)inexpensive to implement.
- The business process gets reengineered —> we need new tools anyway.
- Or... new technology or services make us reengineer our business process.
- The first/second/third time round was/were only so-so; e.g.:
- RiverWare: RSS (Lisp/Unix) —> RSS (C++/UNIX) —> PRSIM
(C++/Solaris) —> RiverWare (C++/Solaris (discontinued in 2012)/Windows).
- Hohmann's advise:
- Replace only when needed or when it creates a business opportunity.
- Replace if it can be done by half the team within one year (RR: this period is getting shorter).
- Some of the people on the current team must be replaced (too much
buy-in/interest associated with the old architecture).
- Recall the former (above) advise: Architecture and team structure reinforce each other.
- 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 in practice:
- Lack of time.
- Most application domains only one or a few reasonable alternatives
- What makes for a good architecture?
- Encapsulation and modularity:
separation and enclosure of system elements as black boxes.
rather than have element A talk to B, have them talk to a generic
intermediate C (API); e.g., streams, ODBC, Web-service, etc.
- Parameterization: core functionality is
fixed; all the rest is data; open black box.
- 1 - 3 imply loose
coupling and modularity: system parts
can easily be replaced without affecting other parts.
- Shared understanding (Rational 4+1):
- Logical view (system structure).
- Process view (system dynamics).
- Development view.
- Physical view.
- Scenarios (use cases).
- Leadership by a few, capable architects.