Роль архитектора решений в проекте по Разработке ПО

Владимир Иванов
Ведущий разработчик, EPAM Systems

Мы все знаем, чем занимаются проектные менеджеры, разработчики и инженеры по тестированию. Но чем конкретно занят архитектор?

Transcript

1. EPAM Systems 1/42
2. Disclaimer Everything presented here is a product of production experience and research findings and provided as is. However, you can use it as we did. EPAM Systems 2/42
3. About me EPAM Systems 3/42
4. About me —Vladimir Ivanov - Lead Software Engineer EPAM Systems 3/42
5. About me —Vladimir Ivanov - Lead Software Engineer —Primary Skill: Android EPAM Systems 3/42
6. About me —Vladimir Ivanov - Lead Software Engineer —Primary Skill: Android —React Native Experience > 2 year EPAM Systems 3/42
7. About me —Vladimir Ivanov - Lead Software Engineer —Primary Skill: Android —React Native Experience > 2 year —Doing some Solution Architecture from time to time EPAM Systems 3/42
8. About me —Vladimir Ivanov - Lead Software Engineer —Primary Skill: Android —React Native Experience > 2 year —Doing some Solution Architecture from time to time —Certified Google Cloud Architect EPAM Systems 3/42
9. About me —Vladimir Ivanov - Lead Software Engineer —Primary Skill: Android —React Native Experience > 2 year —Doing some Solution Architecture from time to time —Certified Google Cloud Architect EPAM Systems 4/42
10. Let's get to know each other! EPAM Systems 5/42
11. EPAM Systems 6/42
12. RFI Request for information EPAM Systems 7/42
13. RFI EPAM Systems 8/42
14. RFI —Answer the questions EPAM Systems 8/42
15. RFI —Answer the questions —Contact the architects of related fields EPAM Systems 8/42
16. RFI —Answer the questions —Contact the architects of related fields —Perform the required research EPAM Systems 8/42
17. RFP Request for proposal EPAM Systems 9/42
18. RFP EPAM Systems 10/42
19. RFP —Understand the business value EPAM Systems 10/42
20. RFP —Understand the business value —Create a solution architecture EPAM Systems 10/42
21. RFP —Understand the business value —Create a solution architecture —Understand which teams are necessary to implement that solution EPAM Systems 10/42
22. RFP —Understand the business value —Create a solution architecture —Understand which teams are necessary to implement that solution —Come up with the resource plan EPAM Systems 10/42
23. EPAM Systems 11/42
24. Discovery EPAM Systems 12/42
25. Requirements gathering EPAM Systems 13/42
26. Requirements gathering —Functional EPAM Systems 13/42
27. Requirements gathering —Functional —Non-functional EPAM Systems 13/42
28. Requirements gathering —Functional —Non-functional —Constraints EPAM Systems 13/42
29. Functional requirements! EPAM Systems 14/42
30. Functional requirements! —The system should allow an administrator to login EPAM Systems 14/42
31. Functional requirements! —The system should allow an administrator to login —The system should show the list of users EPAM Systems 14/42
32. Non-functional requirements EPAM Systems 15/42
33. Non-functional requirements —The application should use TLS 1.2 for all connections involving user-data EPAM Systems 15/42
34. Non-functional requirements —The application should use TLS 1.2 for all connections involving user-data —The application should open the page under 0.5 second EPAM Systems 15/42
35. Non-functional requirements —The application should use TLS 1.2 for all connections involving user-data —The application should open the page under 0.5 second —The application should be available 23 hours per day EPAM Systems 15/42
36. Constraints EPAM Systems 16/42
37. Constraints —The app should be deployed to customers' Azure cloud EPAM Systems 16/42
38. Constraints —The app should be deployed to customers' Azure cloud —The app should implement 152 federal law EPAM Systems 16/42
39. Some of them will change the architecture of the solution. EPAM Systems 17/42
40. Every additional 9 of availability doubles the complexity of a target system. EPAM Systems 18/42
41. EPAM Systems 19/42
42. Source of requirements EPAM Systems 20/42
43. Source of requirements —Stakeholders EPAM Systems 20/42
44. Stakeholders are the people who have an interest in the project EPAM Systems 21/42
45. Stakeholders are the people who have an interest in the project —Customer business representatives EPAM Systems 21/42
46. Stakeholders are the people who have an interest in the project —Customer business representatives —Delivery organization business representatives EPAM Systems 21/42
47. Stakeholders are the people who have an interest in the project —Customer business representatives —Delivery organization business representatives —Technical folks from both sides EPAM Systems 21/42
48. Stakeholders are the people who have an interest in the project —Customer business representatives —Delivery organization business representatives —Technical folks from both sides —End-users EPAM Systems 21/42
49. Stakeholders are the people who have an interest in the project —Customer business representatives —Delivery organization business representatives —Technical folks from both sides —End-users —Competitors EPAM Systems 21/42
50. In order to gather requirements you need to talk to stakeholders. The stakeholders identification is one of the main responsibilities of a Solution Architect. EPAM Systems 22/42
51. What’s an architecture? The set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both. 2 2 Software Architecture in Practice, 3rd Edition, Bass, Clements, Kazman, Addison-Wesley EPAM Systems 23/42
52. What the hell it means? EPAM Systems 24/42
53. What the hell it means? —Architecture is a key to the system properties, an end user is concerned about EPAM Systems 24/42
54. What the hell it means? —Architecture is a key to the system properties, an end user is concerned about —Or product owner thinks so EPAM Systems 24/42
55. What the hell it means? —Architecture is a key to the system properties, an end user is concerned about —Or product owner thinks so —There are no bad or good architectures; there are ones that fit the target system properties EPAM Systems 24/42
56. ASRs Target system properties which affects architecture are unsurprisingly called architecturally significant requirements. EPAM Systems 25/42
57. How to identify ASR? EPAM Systems 26/42
58. How to identify ASR? —From requirements documents EPAM Systems 26/42
59. How to identify ASR? —From requirements documents —By interviewing stakeholders EPAM Systems 26/42
60. How to identify ASR? —From requirements documents —By interviewing stakeholders —By understanding the business goals EPAM Systems 26/42
61. How to identify ASR? —From requirements documents —By interviewing stakeholders —By understanding the business goals —Utility tree! EPAM Systems 26/42
62. Utility tree EPAM Systems 27/42
63. EPAM Systems 28/42
64. EPAM Systems 29/42
65. EPAM Systems 30/42
66. How to document architecture? EPAM Systems 31/42
67. How to document architecture? —Non-formal notations with general purpose diagramming EPAM Systems 31/42
68. How to document architecture? —Non-formal notations with general purpose diagramming —Semi-formal notations with standardized notation EPAM Systems 31/42
69. How to document architecture? —Non-formal notations with general purpose diagramming —Semi-formal notations with standardized notation —Formal notations with precise semantics EPAM Systems 31/42
70. EPAM Systems 32/42
71. EPAM Systems 33/42
72. Documenting the architecture is the third most important activity for an SA. EPAM Systems 34/42
73. EPAM Systems 35/42
74. Construction EPAM Systems 36/42
75. Construction —Bootstrap the development EPAM Systems 36/42
76. Construction —Bootstrap the development —Define and setup quality gates EPAM Systems 36/42
77. Construction —Bootstrap the development —Define and setup quality gates —Create PoCs EPAM Systems 36/42
78. Construction —Bootstrap the development —Define and setup quality gates —Create PoCs —Share knowledge EPAM Systems 36/42
79. EPAM Systems 37/42
80. Transition EPAM Systems 38/42
81. Transition —To production EPAM Systems 38/42
82. Transition —To production —To other team EPAM Systems 38/42
83. So... The person who identifies stakeholders, gathers ASRs, builds the architecture, shares it and bootstraps some of the systems components is usually called Solution Architect. EPAM Systems 39/42
84. In EPAM Solution Architect: EPAM Systems 40/42
85. In EPAM Solution Architect: —Practical experience with 10+ projects in relevant engineering domain. EPAM Systems 40/42
86. In EPAM Solution Architect: —Practical experience with 10+ projects in relevant engineering domain. —Good knowledge of architectural theory out of primary technology domain context bounds. EPAM Systems 40/42
87. In EPAM Solution Architect: —Practical experience with 10+ projects in relevant engineering domain. —Good knowledge of architectural theory out of primary technology domain context bounds. —Ability to identify stakeholders and adopt communication style to particular role (effectively communicate with peer client architects and management). EPAM Systems 40/42
88. Links EPAM Systems 41/42
89. Links —Books is Software Architecture: https://medium.com/@nvashanin/books-in-software- architecture-6ad974e524ce EPAM Systems 41/42
90. Links —Books is Software Architecture: https://medium.com/@nvashanin/books-in-software- architecture-6ad974e524ce —Amazon Cloud Architect Associate: https://www.udemy.com/aws-certified-solutions- architect-associate/ EPAM Systems 41/42
91. Links —Books is Software Architecture: https://medium.com/@nvashanin/books-in-software- architecture-6ad974e524ce —Amazon Cloud Architect Associate: https://www.udemy.com/aws-certified-solutions- architect-associate/ —Google Cloud Architect Professional: https://www.coursera.org/specializations/gcp-architecture EPAM Systems 41/42
92. EPAM Systems 42/42