The document discusses the process of architecture and what it takes to be an architect. It involves identifying business goals, gathering requirements from stakeholders, making design decisions, documenting the architecture, and communicating design decisions. Key aspects of architecture include styles/patterns, reference architectures, and creating views like context, component, and deployment diagrams. The architect must understand business goals, requirements, and make design choices to achieve them while documenting decisions in an architecture log.

1. What does it take to be an architect
Konstantin Slisenko
Solution Architect at EPAM
twitter: @kslisenko
facebook.com/konstantin.slisenko.1

2. 2

3. My own
experience
● Big company
(not a startup)
● Teams in different
cities and time zones
● Enough time and
money
3

4. What is
architecture?
4

5. 5
https://dzone.com/articles/spring-cloud-microservices-at-pivotal-platform

6. Architecture is process of
6

7. Architecture is process of
7
1. Identifying business goals

8. Architecture is process of
8
1. Identifying business goals
2. Gathering requirements from stakeholders

9. Architecture is process of
9
1. Identifying business goals
2. Gathering requirements from stakeholders
3. Making design decisions

10. Architecture is process of
10
1. Identifying business goals
2. Gathering requirements from stakeholders
3. Making design decisions
4. Documenting

11. Architecture is process of
11
1. Identifying business goals
2. Gathering requirements from stakeholders
3. Making design decisions
4. Documenting
5. Communicating

12. 12

13. 13

14. 14

15. Sure!
- I can rewrite it
- Using cool latest technology
- Enhance API
- Improve performance
- Refactor
- And do much more!
15

16. Trust me,
I’m an architect!
16

17. “Poor understanding of business
goals is the path to the dark
side.
It leads to wrong design
decisions.
Wrong design decisions lead to
wrong software.
Wrong software leads to
business failure.” 17

18. Business goals
18

19. Possible business goals of any company
19

20. Business goals
1. Reduce costs by moving to cheaper data vendor
2. Avoid expenses for database maintenance
3. Attract more users at a less cost (outsource
strategy tools)
20

21. 21

22. 22

23. 23

24. - I made design decisions!
- May I start coding now?
24

25. “Patience you must
have my young
padawan.
You haven’t met
stakeholders.”
25

26. Stakeholders
26

27. 27

28. 28

29. 29

30. Stakeholders
1. Responsible for different requirement
areas
2. Sometimes non-technical people
3. Impact on design decisions
30

31. We need to communicate with
different stakeholders differently!
31

32. We need to communicate with
different stakeholders differently!
32

33. Requirements
Constraints
Assumptions
33

34. Gathering requirements
34

35. Example requirements
35
1. Time to show up on UI < 3 seconds
2. Uptime should be 99.9%
3. API must stay backward-compatible
4. We are not ready for cloud
deployment yet

36. Example requirements
36
1. Time to show up on UI < 3 seconds
2. Uptime should be 99.9%
3. API must stay backward-compatible
4. We are not ready for cloud
deployment yet

37. Example requirements
37
1. Time to show up on UI < 3 seconds
2. Uptime should be 99.9%
3. API must stay backward-compatible
4. We are not ready for cloud
deployment yet

38. Gathering requirements
38
1. Time to show up on UI < 3 seconds
2. Uptime should be 99.9%
(we assume that automatic connection
failover will be provided by vendor)

39. Do all requirements
impact architecture?
39

40. Which requirements impact architecture?
40
1. Time to show up on UI < 3 seconds
2. Uptime should be 99.9%
3. API must stay backward-compatible
4. We are not ready for cloud
deployment yet

41. Which requirements impact architecture?
41
1. Time to show up on UI < 3 seconds
2. Uptime should be 99.9%
3. API must stay backward-compatible
4. We are not ready for cloud
deployment yet

42. Architecture
design
42

43. 43

44. “A Jedi makes design
decisions for achieving
business goals and
requirements
Never chooses
technology just because
it is cool or popular.”
44

45. Architecture
styles and patterns
45

46. 46
https://martinfowler.com/articles/microservices.html
https://pradeeploganathan.com/architecture/hexagonal-architecture/
https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/
https://berb.github.io/diploma-thesis/original/054_actors.html
Architecture styles
● Monolith
● Microservices
● Event-driven
● Actor based
● SOA
● Hexagonical
● Serverless
● ...

47. 47
https://docs.microsoft.com/bs-latn-ba/azure/architecture/guide/architecture-styles/cqrs?view=azuremgmtcompute-14.1.0-prerelease
https://dzone.com/articles/layered-architecture-is-good
https://oldworldbaking.co/amp/enterprise-integration-patterns/enterprise-integration-patterns-awesome-integration-patterns-and-practices-for-cloud-and-mobile/
https://martinfowler.com/bliki/CircuitBreaker.html
Architecture patterns
● Layered
● Module-based
● CQRS
● Integration
patterns
● Fault-tolerance
patterns
● ...

48. Reference
architectures
48

49. 49

50. Communicating
design decisions
50

51. “Always pass
on what you
have learned”
51

52. 52

53. “Understanding
your diagram is
pain.
Terrible pain”
53

54. 54

55. We need to communicate with
different stakeholders differently!
55

56. Context view
Architecture views

57. Component viewContext view
Architecture views

58. Deployment view
Component viewContext view
Architecture views

59. Other viewsDeployment view
Component viewContext view
Architecture views
59

60. Context view
60

61. Component view
61

62. Component view
62

63. Deployment view
63

64. Architecture
documentation
64

65. 65

66. What architecture document should have
1. Business goals and stakeholders
2. Requirements, constraints, assumptions (if any)
3. Views (context, component, deployment, other)
4. Architecture decision log
66

67. Your
architecture
is shitty!
67

68. Architecture decision log
Jul 10, 2019 Migrating from Expensive Corp to Cheap & Dale as data vendor (cost
savings). We don’t have to use database anymore, as Cheap & Dail provides
API. Data layer have to be rewritten to call it.. Connection failover will be done
on vendor side.
Jul 10, 2019 Cache will be used in data layer to meet response time requirement (< 3s)
Jul 10, 2019 Data layer API must stay backward-compatible (Anakin Skywalker)
Jul 11, 2019 Feature control mechanism will be used for switching users to new services.
(confirmed to front-end teams)
Jul 15, 2019 Decommission strategy tools for recusing maintenance costs. Cool tools, Inc
provides same functionality as API and we will use it instead. We will write
simple request translator service to remain API backward-compatible.
68

69. Architecture is process of
69
1. Identifying business goals
2. Gathering requirements from stakeholders
3. Making design decisions
4. Documenting
5. Communicating

70. “Always in
motion is
the future...”
70

71. 71

72. 72

73. 73
Diagrams Documents
Draw.io
MS Visio
Sketchboard.io
Google Docs
Confluence
Bitbucket

74. Questions?
Konstantin Slisenko
Solution Architect at EPAM
twitter: @kslisenko
facebook.com/konstantin.slisenko.1
74