BA372 — Architecture
- System architecture is the 'computational model' of your application (the structure of your software system).
- Why does architecture matter?
- Longevity: architectural SDLC = 12-30 years for core business systems; e.g., COBOL—Y2K examples (p. 5).
- Returning BIS MECOP students often remark on to how 'old' the systems at the companies are.
- PacBase, Unix,
X Window System and
- "...architectures outlast their teams" (p. 5).
- Good longevity: architecture supports a long run and extension of the application(s).
- Bad longevity: sunk cost prevent (needed) major overhaul.
- Stability/constancy: architecture is the 'constant' component of a system —>
foundation and functional framework/skeleton —> developmental predictability.
- Architecture determines the boundary between what's in and what's out —> architecture and system capabilities reflect each other.
- Good architecture makes for easy extension and scaling; e.g.; plug-in architectures:
- Particularly important in collaborative software development situation; e.g., open source products; e.g.,
Linux, GIMP, R or Mozilla Firefox.
- Profitability/Affordability: "...can sustain it with an acceptable cost structure" (p. 5).
- Architecture and team structure reinforce each other:
- Technical expertise.
- Shared mental model.
- Shared normative model.
- This is a mixed bag... very much needed early on and during main production, but can become (very) problematic once the architecture has run its course.
- Hohmann's goal: "Create winning (sustainable) solutions":
- "Move beyond software
architecture and move toward understanding and embracing the business issues..." (xxv).
- 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: 'Link rot':
- TeachEngineering.org link rot.
- "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: explain Hohmann's concepts of technical debt and entropy reduction (ER) (p. 14-15)?
- Quote from CASS/ODOT project review: "The original design of the database did not factor in archiving, resulting in overcomplicated key constraints
that caused problems with archiving the data later. Redesigning
the production database and refactoring the application code would have significantly increased the project's scope,
cost and schedule.
The lesson learned is that when a new application is developed that will have a large database,
the initial project scope should include an archiving component. Designing the archive method as the database is being
designed should reduce the problems being encountered years later when an archive process is implemented. At a very minimum,
if archiving data is not in scope for the initial project, the review of the database design needs to consider factors that
could make archiving data complicated.
This is an example of how technical debt can build up over time resulting in the work becoming more complicated due to past
project design and technical decisions."
- Companies can help solving technical debt problems.
- Hohmann (p. 14): "Entropy Reduction: Paying off Technical Debt after Every Release."
- Problem: What do you think about this notion of entropy?
- Problem: is 'our (the traditional)' interpretation of the concept of
entropy different from Hohmann's?
- Hohmann (p. 14): "Entropy reduction is not about making substantial changes to the architecture..."
- 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 (or getting an extension on a loan). 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.).
- Remember Paul Ford's comment on code documentation: "A program is a letter from current you to future you or to the person
who inherits your code; a generous humanistic document." (Paul Ford, 2015).
- 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 manage 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?
- "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):
- Be aware of so-called 'patterns.'
- Equally valid but conflicting approaches: e.g.; Business logic in stored procedures (SQL*Server T-SQL, Oracle PL-SQL, MySQL SPL)
vs. in a separate business logic/application layer (see also p. 160).
- Despite longevity; when to replace a system architecture? (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:
- Needed extensions and new capabilities 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++/Unix) —> RiverWare (C++/Unix (discontinued in 2012)/Windows).
- Hohmann's advise:
- Replace only when needed or when it supports 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:
- Insufficient time and resources.
- Most application domains have 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.