The document provides insights into the role and skills of software architects, emphasizing the importance of continuous design and application architecture principles. It discusses key architectural concepts, models, and frameworks, including the C4 model and UML, while highlighting the evolution of software architecture and design patterns. Additionally, it addresses challenges in the architecture field, such as the balance between agile development and design discipline.

1. How to Speak the Language
of Application Architecture
Brad Beiermann

2. 2
1. Intro
2. The Software Architect Role
3. Continuous Design & Application
Architecture Design Principles
4. Generic Models
5. Modeling Your Software
6. Software Design Patterns
7. Architecture Review Board
8. Enterprise Architecture &
Frameworks
AGENDA

3. Brad Beiermann
LinkedIn: https://www.linkedin.com/in/bradbeiermann
Contact email: bradb@cimstrat.com
GitHub: Bassmint123
Company: KAPOW Events (https://www.kapow.com)
Current Role: Director of Technology
Presenter

4. Kapow is the world’s leading corporate events platform,
offering unique experiences that are easy to book, drive
bottom-line results and don’t break the bank.
Get an unfair amount of face time with your customers, partners and teams
10k+
Experiences
1k+
Customers
5k+
Events

5. Global events company
Cvent acquires Chicago
startup Kapow
For corporate events these days, steak
dinners are out. To keep up with
changing demands, event technology
company Cvent is acquiring Chicago
startup Kapow. With its 50 employees,

6. THE SOFTWARE ARCHITECT ROLE

7. 7
1. Software Application - Designs the structure of applications
Titles: Software Architect, Application Architect, Framework
Architect
2. Sales & Support - Involved in the implementation of products
Titles: Solution Architect, Field Architect
3. Systems - Skilled in infrastructure design
Titles: System Architect, Cloud Architect, Infrastructure Architect
4. Operations - Skilled in business enterprise functions and design
Titles: Enterprise Architect, Integration Architect
POPULAR IT ARCHITECTURE ROLES

8. 8
● Familiarity with an architectural modeling language
● Fluent in creating diagrams or visual feature representations
● Architecture frameworks (ie. TOGAF, Zachman, ITIL,...etc.)
● Comfort around a codebase...but development is not a focus
● Present a vision of how something is built end-to-end holistically
● Derive costs effective designs and options
CLASSIC SOFTWARE ARCHITECT DISCIPLINES
What are the essential skills?...

9. 9
● Growing and mentoring Architects -- not really happening today.
● It is hard to measure design as an investment
● Selling design is not much different than selling vitamins
● Design “slows development” mentality
● “The code is our documentation” mentality
● Agile development
○ Envisioning step not done correctly
○ No design discipline guidelines (Manifesto principle #11?)
○ Code delivery prioritized over design
● Complete abandonment of architecture skills used in waterfall
It is an industry sacrilege to say anything bad about the Agile
manifesto, but it has some gaps...
“DEBATES & SYMPTOMS”

10. 10
As a Developer...
- Nature of the work in more instant gratification.
Example: Write -> Run -> Results
- An application’s success is measurable
- Your product is a codebase
- The code is viewable, you can actually see it.
- Low abstraction
As an Architect...
- Nature of the work is more delayed gratification.
- The success of architecture is hard to measure.
- Your product is a vision
- EA governance is invisible, yet omnipresent.
- High abstraction
GOING FROM DEVELOPER TO APPLICATION ARCHITECT

11. 11
Step 1: Be design driven.
Where do you start?...
Step 2: Refer back to Step 1.

12. 12
GETTING INTO THE ARCHITECT ROLE
● Ease into it. Don’t rush. This is a discipline.
● Think about how something (ie. business,
customer,...etc.) works and the strategy
behind it.
● Resist the urge to just hurry up and draw
something, or rush into patterns.
● Architecture involves articulation. It’s easy to
overwhelm an audience.
● Think BIG, but start small.

13. 13
Our code tells us what is being done.
The code is merely a set of instructions.
Architecture tells us why something is being
done, and how it is being done.
The architecture is a vision and strategy.
CODE VS. STRATEGY

14. CONTINUOUS DESIGN &
APPLICATION ARCHITECTURE
DESIGN PRINCIPLES

15. 15
CONTINUOUS DESIGN
● Continuous Design (Incremental Design) - The practice of creating and
modifying the design of a system as it is developed (Agile), rather than
purporting to specify the system completely before development starts
(Waterfall)
● Continuous Design was popularized by
eXtreme Programming (XP).
● Continuous Design also uses test driven
development (TDD) and refactoring
practices.
What is it?...

16. 16
Waterfall for:
1. Requirements
2. Analysis
3. Design
Agile for:
1. Iterative Coding
2. Iterative Testing
3. Operations
(Deployment)
HYBRID DELIVERY FRAMEWORK

17. 17
Architecture
Design
Session(s)
Team
creates
arch/design
(Kruchten
4+1, UML,
Modelling)
Business
Stakeholders &
Clients
Sprint
Planning
Meeting &
Grooming
Release Planning
Design Driven Software Development Lifecycle (SDLC)
Our Implementation of
Continuous Design step within
the Agile SDLC doing
incremental design.

18. 18
CONTINUOUS DESIGN PRINCIPLES
● Incremental design: Design just enough to build the sprint
release, but build upon the application’s holistic view.
● Build to change, instead of building to last.
● Model to analyze and reduce risk.
● Use design to identify key engineering decisions.
● Recognize delayed gratifications in a design.
● Use models and visualizations as a communication and
collaboration tool.

19. 19
ENGINEERING DIAGRAMS
A picture is worth a
thousand words
vs
A diagram should be
of few words

20. 20
“Far too many teams allow their codebases to grow without having an
insight into the structure of the code. The result is often the proverbial "big
ball of mud"; a codebase that is tangled, hard to understand, hard to work
with and hard to change. Visualising the structure of your code is the
first step towards improving it.”
-- Simon Brown
Big Ball of Mud (BBM)

21. 21

22. 22
“In our quest to become Agile, we have lost the ability
to visually communicate our code.”
-- Simon Brown

23. GENERIC MODELS

24. 24
THE EVOLUTION OF SOFTWARE ARCHITECTURE & MODELING
Modelling
Fragmentation
mid-1960s to
mid-1990s
1st Generation
Methods &
Modeling
Languages
2nd Generation
Methods &
Modeling
Languages
Booch ‘91
Booch ‘93
OMT1 OMT2
Shlaer-Mellor
1980s
SASD
1960s &
1970s
Smalltalk
(v1 1972)
OOA-
OOD
1981
Smalltalk-80
(v2 1980)
Martin/Odell
OOM 1973
UML 2.0
2005
UML 2.5
2015
UML 2.6
Exp 2019
MOF
Meta-Object
Family
2006
UML 2.x
OCL 2005
OOSE
1992
Rational
Software
1994
Rational
Rose
1994
IBM
Acquires
Rational
2003
Kruchten 4+1
Model
1995
RUP
1996
UML 1.0
1997
OMG
Adopts
UML 1.1
Fall 1997
UML 1.5
2003
XP
1999
Agile
Manifesto
2001
Arrival of
Modern
Modern Web
Frameworks
BPMN
2008
SOA
Arrival of
Microservices
2014
IaS
2016C4
Model
2011

25. 25
THE EVOLUTION OF SOFTWARE ARCHITECTURE & MODELING
Modelling
Fragmentation
mid-1960s to
mid-1990s
1st Generation
Methods &
Modeling
Languages
2nd Generation
Methods &
Modeling
Languages
Booch ‘91
Booch ‘93
OMT1 OMT2
Shlaer-Mellor
1980s
SASD
1960s &
1970s
Smalltalk
(v1 1972)
OOA-
OOD
1981
Smalltalk-80
(v2 1980)
Martin/Odell
OOM 1973
UML 2.0
2005
UML 2.5
2015
UML 2.6
Exp 2019
MOF
Meta-Object
Family
2006
UML 2.x
OCL 2005
OOSE
1992
Rational
Software
1994
Rational
Rose
1994
IBM
Acquires
Rational
2003
Kruchten 4+1
Model
1995
RUP
1996
UML 1.0
1997
OMG
Adopts
UML 1.1
Fall 1997
UML 1.5
2003
XP
1999
Agile
Manifesto
2001
Arrival of
Modern
Modern Web
Frameworks
BPMN
2008
SOA
Arrival of
Microservices
2014
IaS
2016C4
Model
2011

26. 26
KRUCHTEN 4+1
Logical View
(Structural View)
Process View
(Behavioral View)
Development View
(Implementation View)
Physical View
(Environment View)
Scenario
(User View)
● Developed by Philippe Kruchten
● The “4+1” view model is rather
“generic”
● Used for describing the
architecture of software-intensive
systems, based on the use of
multiple, concurrent views.

27. 27
Scenario is to help capture the requirements so that all the stakeholders
understand how the system is intended to be used.
Artifacts: Use Case, User Story, Epic
Logical view is designed to address the end user's concerns about ensuring
that all of their desired functionality is captured by the system. In an
object-oriented system, this is often at the class level.
Artifacts: UML Class Diagram
Process view is designed for people designing the whole system and then
integrating the subsystems or the system into a system of systems.
Artifacts: UML Sequence Diagram
4 + 1 VIEWS

28. 28
Development view is primarily for developers who will be building the modules
and the subsystems. It should show dependencies and relationships between
modules, how modules are organized, reuse, and portability.
Artifacts: UML Component/Artifact Diagram
Physical view is primarily for system designers and administrators who need
to understand the physical locations of the software, physical connections
between nodes, deployment and installation, and scalability.
Artifacts: Network Diagram, UML Deployment Diagram, Infrastructure Diagram
4 + 1 VIEWS

29. 29
● Developed by Simon Brown
○ Conceptually started around 2006
○ Published in 2011
● Inspired from Kruchten 4+1 and UML
● Model Type: Generic, Visual, & Non-Notational
● The C4 Model consists of a hierarchical set of software
architecture diagrams, based on four common abstractions:
○ Context
○ Containers
○ Components
○ Code
C4 Model
Simon Brown
C4 Model Creator

30. 30
Think of the C4 Model as Google Maps for your code...
Inspiration of C4 Model

31. 31
C4 Abstraction Model
1. Context
2. Container
4. Code
Bidirectional
3. Component

32. MODELING YOUR SOFTWARE

33. 33
1. Ad Hoc (i.e. no method)
2. Industry Standard Modeling
3. Roll Your Own (RYO)
DOIN’ IT!
Three ways architecture design often happens...
Architecture is omnipresent, but not always visible.

34. 34
THE EVOLUTION OF SOFTWARE ARCHITECTURE & MODELING
Modelling
Fragmentation
mid-1960s to
mid-1990s
1st Generation
Methods &
Modeling
Languages
2nd Generation
Methods &
Modeling
Languages
Booch ‘91
Booch ‘93
OMT1 OMT2
Shlaer-Mellor
1980s
SASD
1960s &
1970s
Smalltalk
(v1 1972)
OOA-
OOD
1981
Smalltalk-80
(v2 1980)
Martin/Odell
OOM 1973
UML 2.0
2005
UML 2.5
2015
UML 2.6
Exp 2019
MOF
Meta-Object
Family
2006
UML 2.x
OCL 2005
OOSE
1992
Rational
Software
1994
Rational
Rose
1994
IBM
Acquires
Rational
2003
Kruchten 4+1
Model
1995
RUP
1996
UML 1.0
1997
OMG
Adopts
UML 1.1
Fall 1997
UML 1.5
2003
XP
1999
Agile
Manifesto
2001
Arrival of
Modern
Modern Web
Frameworks
BPMN
2008
SOA
Arrival of
Microservices
2014
IaS
2016C4
Model
2011

35. 35
THE EVOLUTION OF UML

36. 36
THE UNIFIED MODELLING LANGUAGE
● Developed by the Three Amigos:
○ Grady Booch - Booch 91 & 93 for abstraction techniques
○ James Rumbaugh - Object Modeling Technique OMT1 & OMT2
○ Ivar Jacobson - Often known as the “father of Use Cases”,
developed Object Oriented Software Engineering (OOSE)
● Is a visual modeling language
● Applies to modeling and systems
● Is used for expressing the artifacts of a
system-intensive process.
● Is based on the object-oriented paradigm

37. 37
WHAT UML IS AND IS NOT
Not a visual programming language
A visual modeling language
Not a tool or repository specification
Modeling language specification
Not a process
Enables processes

38. 38
“A good 70 percent of UML was a useless farce to sell overpriced clunky tools
(looking at you, Rational Rose). Don’t learn UML to go around annoying
people with useless class diagrams. Do learn the basics so you can read a
sequence diagram and learn to think this way.”
Andrew Oliver
InfoWorld
7 Books You Must Read to be a Real Software Developer
April 19, 2018
Today’s UML...

39. 39
USE CASE
Actor
Use Case
Use Case
Boundary
● A use case is an end-to-end process
description.
● Ivar Jacobson -- Father of the Use Case
● It includes many steps or transactions
● It is not normally an individual step activity or
process.
● Identify by: “The actor can…”
● It has:
○ Pre-Condition
○ Action
○ Post-Condition

40. 40
ABSTRACTION LEVEL
Essential
Very Abstract
Less Detail
Real
Very Concrete
More Detail
Essential vs Real Use Cases
Degree of Design Commitment

41. 41
USE CASE DIAGRAM

42. 42
DECOMPOSITION (INTO CONCEPTUAL MODEL)
● The quintessential object-oriented step in analysis or investigation is the
decomposition of the problem into individual concepts -- the things we are
aware of.
● Conceptual Model - A representation of concepts in a problem domain.
● The focus of a conceptual model may show:
○ Concepts
○ Associations between concepts
○ Attributes of concepts
Flight
date
time
Real-world concept
not a software class
or artifact. A container.
FlightDatabase
date[ ]
time[ ]
Software artifact. NOT
a real-world concept
AVOID
YES!

43. 43
DECOMPOSITION (INTO CLASSES)
Flight
date
number
time
In UML definition...
Class - A description for a set of things that share the same attributes, methods,
relationships, and semantics.
Operation - A service that can be requested from an object to different behavior.
Airport
name
Flies-to
Flight
date
time
FlightDescription
number
Described-by
* 1
Airport
name
Describes-flights-to
1
*
WORSE BETTER!
Conceptual Model
(ie. containers of real world concepts)
More software oriented
(ie. classes, operations)

44. 44
WHY DECOMPOSITION INTO CONCEPTUAL MODEL?
● Decomposition into a conceptual model is an intermediary
step.
● Going straight to classes can be more challenging to
decompose into proper abstraction without a conceptual
model.
TIP: If you are struggling to find your class abstractions, go
back to your conceptual model.

45. 45
● Shows a particular course of events
within a use case.
● Shows the external actors that
interact directly with the system.
● Shows the system events that the
actors generate
● The ordering of events should
follow their order in the use case
SYSTEM SEQUENCE DIAGRAM
message()
message()
Id 1:
Class
Id 2:
Class

46. 46
Cashier
:System
Use Case: Buy Items
enterItem(UPC, quantity)
endSale()
makePayment(amount)
CREATING A SEQUENCE DIAGRAM

47. 47
FRONT-END SEQUENCE DIAGRAM
Office Employee
:Backend
Application
Use Case: Manage Users
enterLogin(id, pwd)
returnUI()
promptUserInfo()
:Employee
Database
checkLogin()
validateLogin()
addUser(info)
enterUserInfo()
submit()
saveUser()
Add
User

48. 48
CLASS DIAGRAM
● Illustrates the specifications for
software classes and interfaces.
● Shows definitions for software
entities rather than real-world
concepts.
● Identifies the classes
participating in the software
solution.
● Shows class relationships.
association-name
ClassName 1
attribute
...
+method()
...
1 1
run()
<<interface>>
Runnable 1
Multiplicity

49. 49
Use Case: Buy Items
CREATING A CLASS DIAGRAM

50. 50
COMPONENT/ARTIFACT DIAGRAM
● Useful because it provides us a
high-level, architectural view of the
system that we will will be building.
● Allow an architect to verify that a
system's required functionality is
being implemented
● As of UML 2.x components are now
strictly logical, design-time
constructs.
● Show run time dependencies
● An artifact can be a physical unit, a
file (ie. csv, gem, modules,...etc.),
executable (apps), script, database,
etc.
i18n (gem) home.erb
Senario: Internationalization

51. 51
Scenario: VPA On-boarding
CREATING COMPONENT/ARTIFACT DIAGRAM

52. 52
PHYSICAL/DEPLOYMENT DIAGRAM
● Shows the hardware for the system
and any cloud instances
● Shows any software that is installed
on the hardware.
● Displays the connectivity of the
disparate machines to one another.

53. SOFTWARE DESIGN
PATTERNS

54. 54
● In software engineering, a design pattern is a general reusable
solution to a commonly occurring problem in software design.
● A design pattern is not a finished design that can be transformed
directly into code. Rather, it is a description or template for how to solve a
problem that can be used in many different situations.
● Patterns originated as an architectural concept by Christopher Alexander
around the late 70s.
DEFINING SOFTWARE ARCHITECTURE PATTERNS

55. 55
● Design patterns gained popularity in computer
science after the book Design Patterns: Elements of
Reusable Object-Oriented Software was published in
1994 by the so-called "Gang of Four"
● The book's authors are Erich Gamma, Richard Helm,
Ralph Johnson and John Vlissides -- known as GoF
● Introduced patterns by “Type”
○ Creational
○ Structural
○ Behavioral
○ Data Access (later)
GoF

56. 56
Supporters
Q. Why DO patterns?
A. Design patterns can speed up the development process and productivity
by providing tested, proven development paradigms.
Critics
Q. Why NOT DO patterns?
A. They are viewed a work arounds for core features missing in a language
framework, or sometimes viewed as a lack of good abstractioning and
barrier to creativity.
THE ARGUMENTS

57. 57
Creational patterns are ones that create objects for you, rather than
having you instantiate objects directly. This gives your program more
flexibility in deciding which objects need to be created for a given case.
Structural patterns concern class and object composition. They use
inheritance to compose interfaces and define ways to compose objects to
obtain new functionality.
Behavioral patterns are specifically concerned with communication
between objects.
THREE PATTERN TYPES

58. ARCHITECTURE REVIEW BOARD (ARB)

59. 59
● ARB (Architecture Review Board)
● Ultimately align design with the company
business goals, strategies, and objectives.
● Improve the quality of our products.
● Define technical design standards, policies,
and principles for the company overall.
WHY DO AN ARB?

60. 60
MIT Knowledge Base
http://kb.mit.edu/confluence/display/home/The+Knowledge+Base
MIT ARB Guidelines:
http://kb.mit.edu/confluence/pages/viewpage.action?pageId=155261497
KAPOW ARB STANDARD & FORMAT
The MIT standard for an ARB is the most commonly used.

61. 61
Short Term Goals:
● Establish architecture baseline and promote architecture best practices
● Establish an architectural framework that can be used for design
● Create architecture roadmaps that supports your business
● Support an “Agile Mindset”
Long Term Goals:
● Prevent framework bloat and achieve a platform that can easily be maintenanced
● Reduce long term technical debt
● Help keep our technology costs inline
● Reduce onboarding time for new resources
ARB GOALS

62. 62
- Start with the end in mind
- Design the EA program for maximum scale and flexibility upfront
- Create a maturity roadmap and follow it
- Don’t try to boil the ocean
- Focus on quick wins
- Show results early and often
Start Small
Plan Big
KEYS TO SUCCESS FOR THE ARB

63. ENTERPRISE ARCHITECTURE &
FRAMEWORKS

64. 64
ARCHITECTURE CONTINUUM
Thinking of enterprise architecture like cities...

65. 65
ENTERPRISE ARCHITECTURE
● Enterprise Architecture is a strategy to
minimize IT and business mistakes
● Many competing perspectives and
approaches to Enterprise Architecture exist
● There is no single, agreed upon Enterprise
Architecture standard.

66. 66
ENTERPRISE ARCHITECTURE FRAMEWORKS
● Just like software frameworks, there are EA frameworks.
● EA frameworks help us be productive in creating and managing our designs.
● There are many frameworks to choose from:
❏ FEAF
❏ Gartner Model
❏ TOGAF
❏ Poldat
❏ DoDAF-TAFIN
❏ C4ISR AE
❏ DOE AE
❏ TOGAF-ADM
❏ Zachman
❏ ITIL
❏ IT4IT
❏ COBIT

67. 67
TOGAF
● Current version is 9.1
● http://pubs.opengroup.org/architecture/togaf9
-doc/arch/
● Often the go-to framework for enterprise
architecture and system architecture
● Maintained by:
● TOGAF - The Open Group Architectural Framework
TOGAF
ADM

68. 68