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.