This presentation touches on the classic skills and disciplines of being a Software Architect or Application Architect. Topics include Kruchten 4+1, UML, TOGAF ADM, Agile Architecture, Enterprise Architecture, Architecture Review Boards, and many others.

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. Kruchten 4+1 Model
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)
Presenter

4. 10k+1k+ 5k+

5. THE SOFTWARE ARCHITECT ROLE

6. 6
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, Network Architect
POPULAR IT ARCHITECTURE ROLES

7. 7
● 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?...

8. 8
● 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
○ 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”

9. 9
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

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

11. 11
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.

12. 12
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

13. CONTINUOUS DESIGN &
APPLICATION ARCHITECTURE
DESIGN PRINCIPLES

14. 14
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?...

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

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

17. 17
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.

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

19. KRUCHTEN 4+1

20. 20
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.

21. 21
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

22. 22
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

23. MODELING YOUR SOFTWARE

24. 24
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.

25. 25
THE EVOLUTION OF SOFTWARE ARCHITECTURE & MODELLING
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
Framework
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
Microservices
2014
IaS
2016

26. 26
THE EVOLUTION OF UML

27. 27
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

28. 28
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

29. 29
“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...

30. 30
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

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

32. 32
USE CASE DIAGRAM

33. 33
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!

34. 34
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)

35. 35
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.

36. 36
● 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

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

38. 38
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

39. 39
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

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

41. 41
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

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

43. 43
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.

44. SOFTWARE DESIGN
PATTERNS

45. 45
● 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

46. 46
● 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

47. 47
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

48. 48
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

49. ARCHITECTURE REVIEW BOARD (ARB)

50. 50
● 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?

51. 51
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.

52. 52
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

53. 53
- 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

54. ENTERPRISE ARCHITECTURE &
FRAMEWORKS

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

56. 56
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.

57. 57
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

58. 58
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

59. 59