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.
- Returning BIS MECOP students often remark on to how 'old' the systems at the companies are.
- Unix/Linux, X11 / X Window System —>
- "...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, Python, 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..." (p. xxv).
- Recall the tension/conflict between 'the manager' and TMitTB in The Code Issue.
- 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.
- "The foundation of a winning solution lies in the architecture that creates and sustains it." (p. 1)
- Classic structure/components of information systems:
- Data logic.
- Business logic.
- Presentation logic.
- Another perspective on this:' Model-View-Controller (MVC):
- Model: business logic.
- View: any perspective / view on the model; e.g.user interface, presentation, data, etc.
- Controller: controls and manages the view and the model.
- 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 entropy:
- Practical example: link rot:
- TeachEngineering.org link rot
- Lima, M. (2011)
Visual Complexity. Mapping Patterns of Information. Princeton Architectural Press. (© permission from the publisher):
"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)."
- Hohmann's concepts of technical debt and entropy reduction (ER) (p. 14-15):
- Quote from CASS/ODOT project review: "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."
- Announcement of Jan. 2018 Portland SIM presentation: "With digital transformation and technology disruption at the top of the agenda in the board room,
IT is uniquely positioned to step of out of the back office and take the lead in driving value creation.
However, IT teams are often buried in technical debt. In this talk, ... will discuss strategies to transform the people, processes and technology of IT to drive growth, create value,
gain market share, and delight customers."
- Some companies specialize in helping solve technical debt problems.
- Technical debt has built-in entropy —> double wammy; 'natural' entropy is bad enough; technical debt entropy makes it worse.
- Hohmann (p. 14): "Entropy reduction (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).
- Hohmann: establish an ER rhythm —> schedule regular/periodic ER activities (time boxing).
- Never 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 technical as well as human considerations in specifying and evaluating system architectures:
- "Illities:" e.g.; scalability, extensibility, portability, accessibility, etc.
- Modularity; independent development, testing and maintenance of components.
- "Designing systems to create a sense of wholeness" (p. 3).
- Allow developers to participate in multiple aspects/parts of the system.
- "Give in to great architectures... let the problem domain guide you" (p. 3).
- Be aware of so-called 'patterns.'
- Be aware of 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:
- Hohmann (p. 160): "One of the most generally accepted principles of enterprise application architecture
is to put business logic within the services layer and/or the domain model layer of the architecture.
However, while this is a good principle, it isn't an absolute rule that should be dogmatically followed.
Many times, a well-defined stored procedure or database trigger is a far simpler and substantially more
efficient solution. Moreover, you may find that the only way to safely offer integration solutions to
your customer is to put certain kinds of logic in the database."
- Recall 3NF and denormalization.
- 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 complexity.
- Entropy reduction costs are (becoming) too high.
- Newer technology makes the extensions easy/(less)inexpensive to implement.
- The business process is reengineered —> we need new tools anyway.
- Or... new technology or services make us reengineer our business process.
- 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.
- Use cases.
- Leadership by a few, capable architects.