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