This talk is useful for engineers who are strong enough in technology and coding and want to become architects. There is plenty of information about particular technologies and lots of talks about that in conferences. But good engineers sometimes have gap in mapping business to technology, and also in communicating and presenting their design decisions. The goal of my talk is showing these gaps and provide possible areas to further growth.

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

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

3. What is
architecture?
3

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

5. Architecture is process of
5

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

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

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

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

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

11. 11

12. 12

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

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

15. “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.” 15

16. Business goals
16

17. Possible business goals of any company
17

18. Business goals
1. Reduce costs by moving to cheaper data vendor
2. Avoid expenses for database maintenance (find
vendor which doesn’t require database)
3. Attract more users at a less cost (instead of building
own strategy tools outsource them and get many
features out of the box) 18

19. 19

20. 20

21. 21

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

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

24. Stakeholders
24

25. 25

26. 26

27. 27

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

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

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

31. Requirements
Constraints
Assumptions
31

32. Gathering requirements
32

33. Example requirements
33
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

34. Example requirements
34
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

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. Gathering requirements
36
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)

37. Do all requirements
impact architecture?
37

38. Which requirements impact architecture?
38
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

39. Which requirements impact architecture?
39
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

40. Architecture
design
40

41. 41

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

43. Architecture
styles and patterns
43

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

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

46. Reference
architectures
46

47. 47

48. Communicating
design decisions
48

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

50. 50

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

52. 52

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

54. Context view
Architecture views

55. Component viewContext view
Architecture views

56. Deployment view
Component viewContext view
Architecture views

57. Other viewsDeployment view
Component viewContext view
Architecture views
57

58. Context view
58

59. Component view
59

60. Component view
60

61. Deployment view
61

62. Architecture
documentation
62

63. 63

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

65. Your
architecture
is shitty!
65

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

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

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

69. 69

70. 70

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

72. Questions?
Konstantin Slisenko
Solution Architect at EPAM
twitter: @kslisenko
facebook.com/konstantin.slisenko.1
72
Credits to Pavel Veinik
CEO at Hard & Soft Skills, CTO at Split Metrics
facebook.com/pavel.veinik