Architecture

What is it?

Every Application has an Architecture

Whether or not a project team has a software architect, every application has an architecture - and somebody needs to establish and nurture it. Otherwise it is a slippery slope to entangled code and non-maintainable and brittle systems.

Every Team has guiding architects (regardless of designation)

Many of us working in software delivery teams do the work that can be labeled as software and enterprise architecture, without having the labels (designation).

Most software projects will have a small set of senior developers who create a workable architecture - whether they document it or not. So architecture is as much a skill, as it is a role.

Good software architectures focus on business requirements

…rather than frameworks, languages, diagrams, or programming paradigms (procedural, functional, etc). All these are used in creating applications, but the underlying principles that guide the architecture are informed by business requirements.

When software architecture decisions are based on technology rather than business requirements,

it is primarily due to two reasons [@Enríquez2018] :

1. Familiarity: Comfort Zone

You’re at home with what you know best!

2. Skills Reboot: Tech Bandwagon

You want to be seen as hip!

What is EA (Enterprise Architecture)?

a framework for managing the structure and strategy of an organization

execution is Key (more so than the idea itself)
An excellent framework for organizational effectiveness will have no impact unless people know how to apply it in practice.

• structure: helps design the organization
• The business strategy provides the intent.

The EA framework provides the processes for translating the strategy (intent) into organizational effectiveness in achieving the strategy (aligning to strategy). [@Jager2023]

Drivers of organizational strategy

Business Values

…agility, or the need to quickly respond to change via responsive IT systems and digital service delivery models

Environment changes

the imperatives of navigating complex regulations and the economic environment

What is Software Architecture

• the fundamental structures of a software system – making structural choices from among a realm of possibilities.

  software elements, and the relations among them properties of the elements and the relations

• the discipline of creating such structures and systems
• a blueprint for the system: helps identify tasks to be executed by design teams
• captures early decisions about high-level design
• facilitates communication between stakeholders

At a conceptual level, architecture is simple: you apply patterns, create perspectives, etc. However, reality is complex: you release a product and entropy takes over.

• a Building architecture metaphor is frequently applied in the literature

  conjures picture of a master builder creating beautiful designs. In reality, even with great buildings an architect’s work involves balancing opposing forces of site, budget, taste, function and physics.

Similarly, dev teams face day-to-day struggles from opposing pulls of speed, quality, cost, etc.

Discipline Vs. Craft

• Discipline: ask a building architect to communicate its architecture, you’ll be presented with site plans, floor plans, elevation views, cross-section views, detail drawings. A clear reflection of what is being, and has been built.
• Craft: ask a software developer to communicate the architecture of a system through diagrams, you’ll get a confused mess of boxes and lines. No reflection of what is being built. A conceptual abstraction that is out of sync with reality (the structure of the code).

To be useful, visual models need to reflect reality. And architects need to develop the skill of effective visual communication of software architecture.

Architecture:

• not just a conceptual domain of experts disconnected from reality
• a rough-and-tumble of daily give-and-take: daily tussles of team members who have to balance trade-offs and competing forces to deliver high-performing applications.

The goal of architecture is to enable early and continuous delivery of business value from the software being developed.

Why create a Software Architecture?

• Identify & Fulfill Software Quality attributes security, scalability, performance, resiliency - different quality attributes will assume primacy in different domains / business need scenarios

• Create Blueprints at a varying levels of abstraction Allowing business and technology decisions to be made. E.g., comparing options and analysing properties.
  Software architecture aka blueprint: contains descriptive models of the system.

• Build re-usable services by focusing on system interfaces

• As roadmaps to a future state: transition planning for successful implementation of a blueprint

Evolution in Architectural Paradigms: IS to EA…

1980s: the age of the monolith & vendor lock-in

• software was locked into vendor ecosystems (proprietary platforms & operating systems optimized for their environment), such as:
  • Mainframes: IBM System/370 and BUNCH (Burroughs, Univac -> Unisys, NCR, CDC & Honeywell
  • Minicomputers: DEC VAX, Data General & HP
  • Workstations: Sun Microsystems (running Unix)

Monolithic architectures, with all application components in a single executable running on a single machine were standard.

• Distributed computing was still nascent (The Internet was still a research tool, and local area networks (LANs) were only just emerging).

• Enterprise system software was commercially licensed and costly:
  • Transaction Manager: IBM CICS used in banking on mainframes
  • DBMS’: Oracle, DB2, Sybase
  • OS: Unix variants - IBM AIX, SCO UNIX
• Key driver: business need to automate manual processes

1990s: the age of the distributed monolith

• client-server model developed. The application split into 2-3 physical tiers:
  • a client,
  • an application server, and,
  • a database server … as opposed to the single (mainframe or minicomputer) tier of the monolith era that ran all the components on one powerful machine.

• Processing was distributed over the network with client and server communicating over protocols like TCP/IP.

• Networking protocols and middleware started to lean toward open systems

  Driver: growth of networks of personal computers, started the pivot away from mainframes.

2000s: the age of Internet-enabled, connected architecture and distributed computing.

• monolithic, single-machine software of the 1980s gave way to client-server and multi-tiered architectures connected by the internet.

• XML & JSON based web services like SOAP and REST established platform-independent communication between applications on the web.

• A decentralized user culture (forums), peer-to-peer networks (resource-sharing among small groups of machines), the growth of broadband over dial-up, introduction of Wi-Fi, made the Internet a household feature.

• 2007: shift to mobile connectivity started with the iPhone

• Social media platforms began to flourish.

• 2000s -> Agile caught on (from the Agile Manifesto)
  the way teams build software changed.
  • up-front design was discarded, and with it the practice of diagramming was deemed irrelevant

Cut to present day, “creating software architecture diagrams seems to be a lost art”

Visual learners (understand through diagrams or the written word), might prefer to visualize a problem or business process as a high-level domain model.

Today, if you ask someone to draw an architectural diagram, you get an ad-hoc collection of “boxes and lines” – diagrams with no clear notation or semantics.
e.g.

Activity
Draw an architecture diagram to describe your software system

Demo examples some show very high level abstractions, some show low-level design details some diagrams show static structure, some show runtime and behavioural aspects.
some show technology aspects, most don’t.

The problem is the need to represent varying levels of abstraction, structural vs dynamic aspects, technology choices, etc.

Architectural Styles

APIs

• APIs are forever: design with care Once an API is released to production any significant change may potentially break existing integrations. Hasty design decisions can cause confusion, support issues and lost opportunities far into the future.

Visualizing

• C4 methodology & viewpoints
• issues with existing Blueprints
  • Conceptual does not depict key roles, flows, component clarity
  • quality attributes are muddled up
  • divergence from published EA artifacts (template repository)

Glossary

Artifacts: architecture deliverables such as models, templates

References