#begin

I ‘m really on a Udemy roll here if I have to say myself. I’ve been listening to Udemy courses a lot lately and I recently finished another one by my friend Mark Farragher. This time it’s a less technical kind of course and more towards abstract matters and practices on how to become an outstanding solution architect. It’s this one: How To Become An Outstanding Solution Architect.

My motivation to view this course was driven by the fact that I’ve only watched rather technical courses up till now and software architecture is something I find really interesting. Also, the material you learn in courses like this are applicable by everyone, and in most if not all projects. So I thought lets give it a go and view this course.

This review is going to be a bit different from the other ones since it is, less technical. So I prefer to document this a bit more abstract as well. I wont be discussing each video per section individually but rather talk about each section as a whole.

Let’s take a look.

Course Structure

This course has 8 sections, 67 lectures and 7 hours and 49 minutes of content. There are some assignments and further reading at the end of each section which you can do if you are interested. The course has the well known (by me) introduction and final words sections which are the same for all of Mark’s courses. The interesting bits are in the rest of the course. So let’s dive into the remaining 6 sections!

The Architect and the Team.

This section is about the structure of a software development team; which important roles are there and where does the solution architect fit in. Mark talks about the different roles like developers, functional analysts, QA, the Lead Developer, Deployment Manager, Project Manager and of course the solution architect. He explains about the interactions between these members of the team and other stakeholders and why the solution architect is such an important role. What I found interesting and really want to give some applaud for (/clap) is the emphasis Mark puts on the fact that the roles of the Solution Architect and Lead Developer and NOT the same. For example: he talks about how the solution architect needs to design the overall structure and specification of the system, but is not responsible for setting coding standards a the like. The solution architect might have some input here, but the lead developer is the one who has the final word here.

What makes a great Architect?

This third section is all about how you can be a great solution architect. It touches on the architect job description, responsibilities, personality traits and common pitfall for architects. I think adding this section made a lot of sense since it dives deeper into the separation of the architect role and all the other roles of the software development team. In this section Mark breaks down a Solution Architect vacancy he found on the web which I though was nice. I remember doing the same thing when I was writing a blog about ScrumMasters, which you can read here. When you break down some vacancies you really get a good understanding what the marked expects of a certain role.

Mark also talks about the responsibilities an architect has for the project and the development team. He boils this down to four major categories;

Insight which involves being able to take “The birds eye view” over a project, abstracting out complexities to see the system as a whole and understanding all important trade-offs.

The second category is Leadership, which means exactly what you think it means. You as a solution architect must constantly monitor if the implementation of the system matches the architecture you have designed and if not you must guide the team into aligning the system with the architecture again to stay on course with the long term vision.

As a solution architect, you need to be able to communicate well. In a leadership position communication is a really, really important responsibility and skill to have. You need to be able to clearly explain why you have made certain decisions in the software design and you need to be able to defend them properly or your ideas and design will suffer.

The last core responsibility of the solution architect is to be able to have vision and focus on the big picture. You need to have a holistic view of the entire system to be build over the course of let’s say the coming year. In order to achieve this you might need to change some of the software processes, used frameworks and known architectures used by the developers. So you need to act as a change agent if needed to inspire the development team to invest time and effort in changing these things if needed.

Mark gives a nice tip here as well; he says you need to educate the company about the responsibilities of a solution architect. Some companies do not understand what the architect is supposed to do and thus bother him with many other tasks and responsibilities.

He also touches on some of the soft skills you should have as an architect and again boils this down into four categories; You need to be steadfast by which Mark means you need to be patient with the other stakeholders when you promote a lot of change in the company, processes and the way they write software. You also need to be trustworthy, so follow up on your things and lead by example. Another skill you need to have is persuasion since you must be able to convince people that you know what the heck you are doing and make sure people believe it too. The last trait Mark says an architect must have is confidence since you are a leader and thus you must be confident that you get the job done or the project will fail.

The last thing Mark talks about is some common pitfalls for solution architects. He starts by explaining that sometimes the lead developer can loose trust, and thus the software development team, in the architect. This can happen the project starts to go off track and you as an architect are doing nothing about it. Maybe the developer are unhappy with the architecture, they pointed problems out to you, but you are ignoring them.

Another common pitfall is; invalid functional requirements. I think this has happened to every single software developer or architect on the face of this planet. As an architect you must always be on top of the requirements and make sure they are always correct. Your contact with the functional analyst must be well maintained and always make sure both of you align the requirements.

The third pitfall is the problem of the planning being too optimistic. Again, this is something everyone in the software industry must have experienced multiple times in his career. You as the architect must be able to spot this right away and do something about it. You can greatly reduce the stress on the development team and they will very thankful for it.

The fourth, and last, pitfall an architect can run into is having absolutely no power. I think this is probably very common as well. You should educate everyone about your role, even C-level employees, if this does not work Mark tells you sadly that you should leave the company since you cannot do your job this way.

Designing a Software Architecture.

This next section is one I found rather boring. I think this is the first section in any of the courses I enrolled I actually think is not interesting enough and I think, it’s not you Mark it’s me… This section gives some very high level information on what software architecture is, the key principles and guidelines for software architecture, an introduction to UML and 7 popular diagrams used in software design, how you would design a software architecture and what the process could be.

I’ve read many books on software architecture, I’ve had courses about this in both my bachelor’s and my Master’s studies, which were much more in depth. So this section does not really ‘scratch my itch’. I think If you are new to software architecture there is a lot of interesting information here but for me there wasn’t really any new knowledge presented.

However, I think it is good this is included in the course so you as a student get some high level information where you can study further if you want to. Mark gives you some starting points from where you can continue your study about software architecture.

Architecture Design patterns

This next section falls in the same category as the previous section. No real new knowledge for me here. What I do think is interesting about this section is the categorization of the video’s Mark made here. He categorized the video’s to the type of architecture patterns so for example; layered architectures, presentation architectures, service architectures.

So for example in the video about layered architecture he talks about the client-server pattern, layered architecture and  N-Tier architecture. He explains about the pro’s and cons of all types and why/ when you should choose to use them. He does the same for the other architecture pattern video’s, giving some examples and telling you what advantages and disadvantages they have.

Designing Layers, Components and Services

This section is one I found more interesting again, yet there wasn’t really much new knowledge. Just the fact that Mark talks about component/plugin architecture resonates with me. I like plugin architectures (clean/hexagonal/vertical slice, etc.) very much. What Mark basically tells you in this section is that what ever architecture you create; layered, component or service oriented, it is best to always make sure you create a plugin architecture since you can easily swap things out, test them and make it modular. There is a lot of useful information about the different architectures in this section. I think it was a very good call of Mark to add these video’s to the course as well. Mainly because he gives just enough information to get you started, yet not too much to overload people who aren’t familiar with software architecture. He scratches the surface of each pattern and gives you enough information to set you off on a study adventure.

Architecture considerations.

This section touches upon the software quality attributes. The first video’s are about design and runtime quality attributes. I found this section quite interesting, however the information given is far too high level, and in some cases too optimistic. Let me explain this; an example he gives that promotes maintainability is to write unit tests. But as we as developers all know, writing a good testing suite is pretty difficult. Mark simply tells you to write them and why they are important but there is no information on how to properly do this. I think this is acceptable since this course is high level and if you want to know more about testing practices you should check out courses specifically related to that subject. A very optimistic comment he makes in regard to testing as well is that you must reach 100% test coverage, which is of course unreachable. 100% test coverage is an asymptotic goal, you will never reach it.

This section also includes individual video’s that you should always consider to design an architecture that allows for proper caching logic, exception handling and deployment. I think these video are very nice since these subjects are often not the first things that come to mind when designing a system. Having a system that is deployable is rather important since if you can’t deploy it, it’s worthless. For example; I remember having a system that involved many manual steps where developers would most likely forget 1 step and the deployment would not be complete. We fixed all this by setting up CI/CD pipelines and monitoring.

Conclusion

So again a nice course by Mark Farragher. This time on a more high level subject. I think it was a nice course although the information is a bit too high level at some points. I think the purpose of this course is just to tell you about all the things you as a solution architect should consider. And because you are a good solution architect you will be intrinsically motivated to do further research upon everything Mark explains in this course; your responsibilities, how to be a leader, software architecture, patterns, quality attributes and so forth.

I will give Mark a 4/5 star review since I would have liked to see some more in depth information about all the subjects involved. At this point, the course is 8 hours of video content. There are many courses on Udemy that span over 50 hours of content. I know it is probably a lot of work to make all this content, but adding many more video’s that dive deeper into all the subjects he now just scratches the surface would make this course complete. I think Mark is very good at explaining things clearly, even at 1.5* speed. 🙂

So yeah, let’s see what course is next.

#end

01010010 01110101 01100010 01100101 01101110