1 files changed, 131 insertions, 0 deletions
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt
new file mode 100644
index 0000000..9cd15c3
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt
@@ -0,0 +1,131 @@
+1
+00:00:00,100 --> 00:00:02,620
+And I want to conclude this lesson with three takeaway
+
+2
+00:00:02,620 --> 00:00:06,190
+messages. The first one is that having an effective architecture is
+
+3
+00:00:06,190 --> 00:00:09,450
+fundamental in a software project. Or as I say here,
+
+4
+00:00:09,450 --> 00:00:13,050
+a great architecture is a ticket to a successful project. To
+
+5
+00:00:13,050 --> 00:00:15,290
+put it in a different way, although a great architecture
+
+6
+00:00:15,290 --> 00:00:17,940
+does not guarantee that your project will be successful, having a
+
+7
+00:00:17,940 --> 00:00:21,930
+poor architecture will make it much more difficult for your project
+
+8
+00:00:21,930 --> 00:00:25,280
+to be successful. The second message is that an architecture cannot
+
+9
+00:00:25,280 --> 00:00:28,120
+come about in a vacuum. You need to understand
+
+10
+00:00:28,120 --> 00:00:30,550
+the domain of the problem that you're trying to solve
+
+11
+00:00:30,550 --> 00:00:33,480
+in order to define an architectural solution that fits the
+
+12
+00:00:33,480 --> 00:00:37,220
+characteristics of the problem. So a great architecture reflects a
+
+13
+00:00:37,220 --> 00:00:40,500
+deep understanding of the problem domain. And finally, a great
+
+14
+00:00:40,500 --> 00:00:44,630
+architecture is likely to combine aspects of several simpler architectures.
+
+15
+00:00:44,630 --> 00:00:47,880
+It is typical for engineers to see problems that are
+
+16
+00:00:47,880 --> 00:00:50,590
+new, but such that parts of the problems have already
+
+17
+00:00:50,590 --> 00:00:53,540
+been solved by someone else. An effective engineer should
+
+18
+00:00:53,540 --> 00:00:56,270
+therefore, first of all, know what is out there,
+
+19
+00:00:56,270 --> 00:00:59,760
+know the solution space. Second, an engineer should understand
+
+20
+00:00:59,760 --> 00:01:02,420
+what has worked well and what has failed miserably in
+
+21
+00:01:02,420 --> 00:01:05,870
+similar occasions in the past. And finally, an effective
+
+22
+00:01:05,870 --> 00:01:10,100
+engineer should be able to suitably combine existing solutions appropriately
+
+23
+00:01:10,100 --> 00:01:12,870
+to come up with an effective overall solution for
+
+24
+00:01:12,870 --> 00:01:15,750
+the specific problem at hand. And this is just as
+
+25
+00:01:15,750 --> 00:01:18,960
+true in the context of software architectures. When defining a software
+
+26
+00:01:18,960 --> 00:01:22,330
+architecture, you should innovate only as much as you need to and
+
+27
+00:01:22,330 --> 00:01:24,850
+reuse as much as you can. As we said early in the
+
+28
+00:01:24,850 --> 00:01:27,770
+lesson, by doing so, that is, by innovating only as much as
+
+29
+00:01:27,770 --> 00:01:30,100
+you need to and reusing as much as you can, you will
+
+30
+00:01:30,100 --> 00:01:32,960
+be able to avoid reinventing the wheel. You will be able to
+
+31
+00:01:32,960 --> 00:01:37,320
+choose the right solution to known problems. And identify suitable solutions for
+
+32
+00:01:37,320 --> 00:01:40,925
+new problems. So ultimately, you will be able to realize an effective
+
+33
+00:01:40,925 --> 00:01:44,080
+software architecture that will help the success of your project.