recording of the webinar.  I think it won't last longer than five minutes. So the name of the webinar is RCDA, risk and cost driven architecture agile architecture making big engineering decisions with agile teams. The presenter of today's webinar, Dr. L. T. Port from CGI will introduce himself as well. Here's a slide about himself. First thing I would like to say is thanks to Lockheed Martin, the sponsor of Incosy 2021 webinar series. Another one thing I would like to let you know that in case you are a certified systems engineer, you can use or you can receive credits for certification renewal because you attend to a webinar. That is relevant as well for both Incosy certifications and German chapter We have pretty much different but aligned programs and these joined webinars are relevant for both cases. So if you like to use that, use that. There are links with more information about how to get these credits for certification renewal. Another one thing what we do in the German chapter that might be pretty much obvious to any one of you, but we have to from the legislative point of view to point out that during our meetings we do not have or are not allowed to discuss prices or pricing elements, exchange sensitive company data, or competition behavior coordination and stuff like that. That's a European law but sounds pretty much obvious to all of you from all around the world. Just have to note that. If you didn't see the video teaser on the on the YouTube channel of the German chapter of Incosy I think I'm not going to introduce L2 again in detail because he has a slide about himself as well. The interesting thing is about this webinar that it was organized by the German chapter by the Incosy central and the L2 is from the Netherlands. So that's a truly international cooperation for this webinar and I really like the fact that it is happening right now. Before we start I would like to let you know how we are going to do that. We're not going to interrupt our presenter because we have a lot of information to give you. If you have questions please ask them in the questions and answers section. I will gladly if that really fits and it is a short question I will let the presenter know that there is such a question but normally we will answer them at the end of the presentation. I think we will have like 10-15 minutes at the end of the presentation for that. So that's pretty much it. L2 I'm done. You can take the stage. Excellent. Thank you very much, Alexander. And I will share the screen. Let's see. How does this work? Yep, we can see your screen. Yeah, excellent. Great. So thanks for inviting me to get this webinar. We met at an RCDA training course about six months ago and we got to talking about the links to systems engineering. And I have to admit that I am not an expert at systems engineering. I have sort of run into some systems engineering concepts during various more technical engagements as an architect but I'm not really an expert or even I'm sort of certified engineer in that sense. So what I'm going to do is I'm just going to explain to you what we have been doing in terms of what I call architecture in the digital world and how to get a better alignment with agile working. And then I think maybe in the questions and answers or after which we will have a little bit of time to see how that all of that relates to the systems engineering. All right. So this is the announced slide about myself. You can see some of my clients, some of my hobbies here. And I spent the last 20 years working as an architect but lately I'm mostly doing three things. I give an opinion about other people's architectures. So I do second opinions, help trouble projects, do assessments, etc. And I lead the architecture practice in CGI in the Netherlands. For those of you who do not know CGI, CGI is one of the bigger global IT service providers. We have about 75,000 people worldwide and about 30 countries, I think. And the third thing I do is help organizations modernize the way of working when it comes to doing architecture. And the basis for that is the RCDA approach, which you saw in the title as well. So this is RCDA. Depending on who you talk to it, it either means risk and cost rate architecture, that was its original name 10 years ago, or responsive and collaborative digital architecture, which is a more modern name. It comes down to exactly the same four letters. So that is a fortunate coincidence. And we have been, well, not silently, but we have been developing this for our internal use to get better at doing architecture in agile projects. And we have been publishing about it and also helping clients to modernize their architecture function using this approach. And so of what I know about the systems engineering processes, architecture is seen as a phase in the engineering process, right? It is something that you do after you understand what needs to be done. And during the architecture phase in systems engineering, what you do is you make a high level decomposition and you assign responsibilities to the various subsystems or components that you decompose your system into. And this is actually very much also how we used to look at architecture in the software world 20 years ago. However, then something happened. The thing that happened was called the agile manifesto. And the agile manifesto basically is a, you can call it the revolution, that happens once people realize that the type of engineering that you do with hard stuff, with buildings, with airplanes, et cetera, is not the constraints that you have there do not really apply to the software world. Actually, in the software world, there is a much longer period after you have started to take the system into operation where you can change stuff. And to embrace that change, that is the basic tenet of the agile of the agile manifesto. And once you look at that, they have to rethink what architecture is, because if you can change things, and you have to design things throughout the whole life cycle, then the evolution, sorry, the architecture of that system is not something that you have to sort of mostly design a prompt with maybe a few changes or modifications afterwards. No, it becomes something that evolves, where you have to be very smart about how much you sort of lay down and design upfront, and how much of that you will have to change later on, or you will evolve later on. And that means that architecture is not a phase or a particular activity, but it then becomes a set of responsibilities. And that is what this slide tries to say, architecture in the digital world is a set of five responsibilities. And these responsibilities are, first of all, understanding context, because architecture is context. It's all about understanding what needs to be done, what the constraints are, what is realistic, et cetera, et cetera. And then making models, blueprints, designs, actually that decomposition of the system, that you can also consider to be a first model of the system that you're designing. And that is the more traditional way of looking at architecture. You can see some references here, architecture is a set of structures as an abstraction. And these come from books from the late 90s. But then also there is a responsibility of making decisions, because once you decide, or once you design a system and you decompose it, you basically decide how to decompose it. And then there's other decisions to make, like which responsibilities to assign to specific subsystems or components. So this is a slightly later realization that happens in the zeros, or the noughties, as an architect colleague of mine, you like to call it, that architecture can also be seen as a set of design decisions. So that's the third responsibility. And then there is a responsibility to validate that design. If it's an upfront design or the upfront part of the design, then that has to be validated based on the models, of course, or maybe on some product typing. But if it's evolutionary design, then there are other possibilities of validating that architecture. And then finally, there is the responsibility of supporting the realization of that design. And we have called that responsibility delivery here. Of course, architects are not responsible, not fully responsible in the end for the delivery of their solutions that they have designed. But they are certainly responsible for supporting that realization, that delivery. And that is a responsibility that may not have been so obvious or a little bit understated in the classic view of architecture. But in the view of architecture as something that evolves, then that means that there is a much longer interaction between the people doing the architecture and the people doing the delivery. It's not a hand over moment, but it's a continuous back and forth between those two responsibilities. So this is why delivery in an agile context is a much more important responsibility of the architecture function. So what we did basically was we based a maturity model on these responsibilities. As I said, one of the things I do is I help organizations get better at doing architecture, improve or modernize their way of working. And one of the things that one of the tools that you need for that is some way to assess how good they already are and where they need to improve. And you traditionally do that with a maturity model. And our maturity model is based on these five responsibilities. And what we realized after a while was that actually there are many organizations in the digital world, software companies, but also banks who don't even have architects anymore. And they have found a different way of fulfilling these five responsibilities. And at first, of course, that is a bit scary if you are an architect. But after a while, you start to realize that actually, you know, you have that freedom. So the maturity model doesn't say that you have to have architects. And this is what they have to do. No, they have that. But basically, what the maturity model says is that you have to look at how well the organization as a whole fulfills these five responsibilities. They have to be balanced. And they have to also be in touch with each other, of course. So once we had that maturity model, of course, what we started to do was we started to look at organizations and we started to pilot the model and refine it. And this is definitely not the first version. But up till now, we have had quite a number of assessment workshops in about 10 organizations. And we also did these workshops in a number of conferences. Actually, these numbers are a little bit outdated. And we started to gather results. And of course, what we saw was a wide range of maturity levels. And we also saw some very interesting patterns or maybe I should say anti patterns. And these are what we have started calling the waterfall wasteland, the agile outback, and the headless chicken. So what is the waterfall wasteland? Well, this is the name that we started to use for teams or departments where the left the right hand side of this model was ignored. Basically, what we saw was there were teams that had a lot of attention and put a lot of energy in modeling after they understood the context. And then also into validating these models and getting these models approved. But once they had a an approved architecture document, they moved on to the next project. They also didn't think that they were making decisions, they were putting the decision in front of management and making sure that management had the information, right? So they considered themselves advisors rather than decision makers. And they, they had very little involvement in delivery, right? So this, the icon of this, this caricature is, is the ivory tower, right? These are the architects that have kept on working in the classical way. And of course, you know, this is a caricature, as I say, this is not the real world. We didn't meet this extreme, as I'm explaining here in the real world. But there were certainly, there are a lot of teams that are sort of tending towards the left hand side of this model. The opposite, of course, also happens, which is, which is the, the antipattern that we call the agile outback. And here, what we saw were teams that made decisions, they made design decisions. And then they immediately started building. They did not first model it out. And the reason for that was that the agile manifesto actually has something to say about how to make architectures. And it uses the word emerge. There's a principle in the agile manifesto that says that the best architectures emerge from self-organizing teams. And a bit later during this presentation, I'll get back to the principle. But they saw it, you know, as telling them not to model, they were sort of afraid that they would interfere with that magical emerging process, if they would do too much modeling. And validating, that's also something they did not pay too much attention to. And the reason was that they said, well, you know, it's better to fail early and fail often, right? It's you learn quicker from making mistakes than from doing a lot of thinking. And of course, there is a point in that. But it is a little bit one sided. And certainly in very business critical or safety critical systems, failing early and failing often is not an option at all. So that's the other extreme, the agile outback and the icon for the agile back is the crocodile, which emerges from the swamp. Just to symbolize that the emerging architecture is not something that just happens magically from a crystal clear pool. Your beautiful architecture emerges. No, actually, emerging architecture is a lot of hard work. And if you're not careful, it will bite you. So once we establish this, the question, of course, is how do you find that balance? It's all about the balance between five responsibilities. And what we found out after a lot of trial and error and talking to a lot of people is that there's a number of principles that really work quite nicely if you try to balance these extremes and find the right balance between the waterfall and the agile way of working. And the first of those principles is that you have to see architecture no longer as a blueprint that you create, but you have to actually see it as a streaming of decisions. It's not a one thing, you know, not one big thing, one big document or model that you create at one point in time and then handle. No, it is something more continuous. Some people call this continuous architecture. And I'll go into a little bit more detail for each of those principles in the coming minutes. The second principle is about focus. What should architects worry about? Well, that should, of course, be what the business needs, right? So business impacts should determine your focus. And what does that mean for architecture? The third principle is about how far into the future you should be planning or designing, right? Classical architects tend to want to have everything as future proof as possible. Basically, they're designing for eternity extreme agilists. They refuse to see further ahead than one sprint or two maybe. And of course, the truth is somewhere in between. And that's what we call just enough anticipation. But how do you calculate what is just enough? We have some tips for that. And then the fourth principle is about who is doing the architecture. And I already said a little bit about that, but architecture in an agile context is teamwork. It is not something that's done by one person with one goal. So just to go into a little bit more elaboration for each of those principles. So this is the traditional involvement of architects in the software world in the digital world, enterprise architects. I tend to talk about architects in the digital world because there's this big continuum of infrastructure architects, software architects, enterprise solution architects, domain architects. Well, I think there's about 50 of those. And I sort of gather them all into this one denominator, talking about architects in the digital world. And this is how what they used to do. They used to be in their own department. And at the beginning of a project, they would deliver architecture guidance, usually in the form of an architecture description document. And that architecture description document, sometimes, by the way, was called an SSDD, which of course is a term out of the systems engineering methodology. But mostly in the Netherlands, what's called the PSA, the project start architecture. And then in other countries, it's mostly the SAD or the systems architecture document or the software architecture document. And that was delivered. And then after a while, then the architects, of course, needed to make sure that the team, the project, was still compliant with the architecture. So I showed it at these checkpoints. Well, this model does not work in an agile context. Agile teams do not accept this type of architecture. They call the architecture guidance, big upfront design, which is a square word in an agile. And then the checkpoints, they call mind your own business, right? We're a self organizing team. So the best architectures emerge from us, right? So we don't need your interference with your checkpoints. So we need to find a different way to involve architects. So basically in the traditional context, architecture used to be a phase, right? A design phase in a project. In an agile context, what you see is architecture is more continuous. And basically, there are little bursts of design and decision making and validation, et cetera, you know, all of the architecture responsibilities that I mentioned. And these bursts are driven by the backlog that the agile organization or team is running. This is a Kanban, which uses, in this case, the swim lanes of shape of the skilled agile framework, but basically an epic goes through a number of swim lanes. It starts in the funnel, then it becomes the backlog. And then there's this analysis, swim lane. And when an epic is in that swim lane, that is where most of the refinement is done, right? And refinement means you're figuring out how to build it, what it's going to cost, what is the best way to do it, basically architecture work, right? That's where the design decisions are made. But because there is this stream of epics, you might wonder what an epic is. You may have heard the term user story. An epic is basically a collection of user stories or, well, it's not really that. It's something that the business needs, basically. And the business keeps on wanting things. And there's this stream of needs that are these yellow sticky notes here. And as the stream is sort of being digested by the team, that's when the epics or the stories or the speeches go through these phases, these swim lanes, I have to say. So basically an epic sometimes behaves as a little project with its own specification, design, build, and test phase. But if you digest them like this, then architecture becomes a continuous discipline. So one of the key things that you need for evolutionary architecture is you need to have short feedback loops. Because when an architecture evolves, when it needs to respond to changing needs, then you cannot afford to have long feedback loops. That will mean that the architecture will lag behind the needs of the business. You actually need to be able to have, you know, to quickly validate, to quickly design, et cetera. And this is one of the reasons, by the way, that we are sort of looking at these decisions rather than at the whole architecture documents, which are too big to have a very quick feedback loop on. So there's basically two feedback loops in architectural design. The first feedback loop is between the design and the stakeholders. And this consists of communication and analysis. And better understanding of the context leads to better design. And then the better understanding of the design by the stakeholders will need to better formulate the needs. So this becomes a virtuous circle if you do it well. And if you can do this in a manner of days, or maybe even hours, rather than weeks or months, which you would need for a big architecture document to be approved and reviewed, et cetera, then that will lead to a quicker feedback loop and then a more agile and higher quality system. And the other feedback loop is between the design and the working system itself. And there the feedback loop consists of, you know, basically trying stuff out or building stuff and then seeing how it works out. So experimenting is allowed there, of course, but you should also analyze the system in production, you know, because there is one, because this is evolutionary architecture. So you should use that knowledge to also improve your design. So in order to speed up that first feedback loop, what we need to do is we need to get away from these big architecture documents. And this is why we focus on the slower entities of the individual architectural decision as your primary deliverable. I'm not saying that there should no longer be architecture descriptions, or SSDDDs or whatever you want to call them, but they are no longer, you know, considered the primary reason or the primary end product of the architecture responsibilities. And that's the decisions. Of course, from time to time, you need to be able to reason about the design and to communicate the design. And for that, you still create documents. But the individual decisions become the primary entity that you work with. And because they're smaller, they allow for a quicker feedback loop. But also you get something else. And that is individual decision time. Now, this is a very important aspect. The timing of an architectural decision is very tricky. Agilists tend to say you need to delay especially the important decisions to the last responsible moment. Or how do you calculate that? Well, this is an attempt to have a formula for that. But basically, the time to make your architectural decision, your big design decision, is at the moment when the risk of making the wrong decision becomes lower than the cost of delaying the decisions. And of course, the risk of the wrong decision becomes smaller and smaller over time because you get more knowledge, right? And the cost of delay, you know, that depends very much on what else depends on that decision or the dependencies on my decision. Like, okay, I need to order hardware. And, you know, if we don't order the hardware now, then in six months, we'll have nothing to run our system on. So you have to decide now because that basically means the cost of delays sharply going up at that point in time. And it's not just ordering hardware, but it's also teams basically not being able to continue if the architectural decisions are not being made. So, and if we go back to that big architecture document, basically what happened was that we were forcing the timing of all the design decisions in that document to be synchronized at the moment of approval of the document. And I don't know if you have, you know, been involved in this kind of stuff. But if we, you know, I certainly have noticed that usually in those documents, there were a lot of decisions that I would rather have delayed by a month or so. You know, it's not that important. There's no real cost of delay for that decision. And a month from now, I can make a better decision. But it still needed to be made because it has to be in the document. Otherwise, the architecture is said to be incomplete. And the business approver says, I don't know what I'm getting. And likewise, there would be decisions that you had already taken two months ago. But nobody acted on it yet because the document had not yet been approved. Right. So that is the cost of sort of synchronizing all of these design decisions in one document. And that's something else that you gain by timing, by looking at these decisions as your primary output rather than the document. Okay. So what does that mean for your architecture documentation? Well, in an evolutionary architecture setting, basically what you get is you get this cycle of making architectural decisions, and I'll say a bit more about that in a minute, which is driven, of course, by what the stakeholders meet. And this architecture work that is done in that cycle leads to two things. It leads to an architectural decision, which is register, which starts empty, oops, and then grows over time. And it leads to architecture knowledge models and other knowledge that you gather during your architecture work. And what you basically need to do is from time to time, these decisions are your primary deliverable, your models are what you use to validate and to communicate your architecture. But from time to time, you need to have a snapshot of your architecture. And this is what you used to use the big architecture documents for to show your stakeholders evidence that their concerns are being addressed. But in evolutionary architecture, that is not the end product, but it's just a snapshot of the situation of the evolution of the architecture at a point in time where they need to make their decisions. And that creates the baseline on which you do change management. And basically, when you say that, you know, the primary output of architecture is decisions, then it becomes this, what we call architecting microcycle, this becomes your workflow, you start by identifying and prioritizing architectural concerns, which is the problems you need to solve, they become your backlog. And then you research possible strategies or tactics, you know, the tools you can use, and you decide on the best fitting one. And that becomes your primary output. But this is a very simple decision making cycle that that is used to make architect decisions. Okay, Alexander, are there any questions up till now? Well, there is a command. Oh, there are many of them, actually, I missed a lot of them. There is a command, if you like, you can react on that. From Hisham Ozafar, in the mechanical field, there is another loop related to procuring prototype, which can be longest lead time. This can greatly influence learning between architectural iterations. Okay, yeah, that's an interesting point. Thanks. Yeah. Yeah, there is actually a discussion in a chat. So I think, yeah, I just opened the chat and I had a look at it. Yeah, if you have further slides, let's just go further. So there are no direct questions. There are no direct questions. Okay. Oh, and now I see the Q&A actually has something. Elaborate on the headless chicken architecture maturity level. Okay. Okay. Well, that is well spotted that I did not mention that. And, okay, I'll, because I have no slide about that, but basically what we noticed is that there's apart from these two, sorry for this Alexander, I'm going back, but apart from these two anti patterns, this is the waterfall waste, and this is the agile Alpec, we also started to see something else, which is organizations that were very mature in the four lowest responsibilities, but we're very poor in understanding context. And this we saw also occurring more and more over, you know, the two or three years that we have been doing this, we have. And what that means is that there is a lack of connection between the architecture function and the stakeholders, you know, that have to tell the architects or tell the teams what they need. And that means that, you know, even though you can be very good at making decisions and modeling and validating in the delivery, if you do not understand context, basically, what you have is a lot of execution power, but little sense of direction. And this seems to be a worsening problem in organizations and, you know, something that can run very fast, but doesn't know where it's going. And it's the headless chicken. Thanks to John Goodwin, one of my colleagues who came up with that name. All right. Okay, let's continue. Let's go to the business impact. So what is the business impact of architecture? Well, it turns out if you really look into that, and there are some people like Mr. Raymond Slott, who wrote his PhD thesis about this. The real business impact of good architecture practices is in risk and cost control. He investigated a large number of projects and he looked at how they applied architecture practices and what the resulting project success factors were. And he noticed quite strong correlations between, you know, applying architecture practices and risk and cost control. So, for example, the projects that did apply architecture practices had an average budget overrun of 3% and the projects that did not apply architecture practices or did them in a worse way had an average budget overrun of 23%. So that's quite a big difference. So basically, you know, architecture is to improve risk and cost control. Those are the main business reasons to do architecture. To put it another way, it's perfectly feasible to do stuff without architecture. You just win a little bit more risks and it's probably going to cost you more. And if you talk about risk and cost control, then you'll quickly get into this visualization of how the risk and cost uncertainty decreases over time. This is called the corner of uncertainty. It is quite an old diagram and it's used to visualize that. And the job of the architecture function basically is to reduce the uncertainty by doing research and by making decisions. And if you shorten your architecture feedback loop, I try to visualize this with these cycles here. You see the shorter cycles allow you to make quicker decisions, better decisions, and then that will be used to have basically a shorter or a quicker reduction in uncertainty. And that's what we're trying to achieve here. One of the main points there is that, you know, it's especially the big decisions that are most helpful in reducing that uncertainty. And you also, there's another reason to make them in the beginning, the big decisions is because every decision you make constrains the decision you have to make later on. And you do not want the low impact decisions to constrain the high impact decisions. And this is why, you know, that's the ordering which you have to make your decisions. I'll quickly move, I see that I'm going through my time quite quickly. So I'll go to the just enough anticipation bit. So how far ahead should we look if we're doing continuous architecture? Well, in order to calculate that, once again, we have to look at business value. And for this, we use this interesting coloring scheme by a guy called Philippe Grusen, he is one of the real heroes in the software architecture world. And basically, what he says is that the stories in your backlog or the features or the epics, they are in two categories, they are, there are visible stories visible to the end users. And these can, these contribute direct business value. But there are also invisible stories. You can call them under the hoot improvements. And the skilled agile framework calls them enablers. Because they, they are, they don't have any business value by themselves. But their business value is indirect by enabling these green stories to be created more quickly, higher quality or whatever. And so this model allows us to reason about the, the business value of these architectural stories. And that's actually quite important. Actually, both of these stories also have a negative counterpart, which is, you know, red for defect. So if there's a visible thing wrong with your system, you have to repair it. And that repair work is a red story. And then there's also stuff in your system, which we call technical debt. And our definition of technical debt is it's work that needs to be done in your system. But it doesn't directly increase the business value. It's an enabler. But as long as you do not do that work, you are paying interest. That's why we call it technical debt. And the interest usually is that you run higher risk, or the team runs is less productive. You know, seemingly very simple green stories take a lot of time because if there's too much technical debt in the system. So by using this framework of colors, so yellow is architecture, architectural components, architectural improvements, green is a new business features, red is bugs, and black is a technical debt. Then that will allow you to in a continuous architecture setting to be very smart about how you want to develop that business value. And what is the right order to do things. And I'll explain that to you, starting with this simple picture, which most of you probably have seen before. This is actually a picture that is associated with the scrum methodology of agile working, right? We have a solution increment basically what, you know, in agile, of course, you almost never create a new solution, but you always create improvements on existing solutions. Those are the solution increments. And these are created by doing work that is in backlogs. Every sprint, this is a sprint cycle, you do work that is in your sprint backlog, and the sprint backlog at the end of every sprint is populated by stories from your bigger solution or product backlog. So what I have done here is I have used these four colors to indicate the type of business value that is in these stories. You also see this strange little curl on top here that symbolizes the daily stand-up meeting and basically the short feedback cycles that you encounter in the scrum team. So where do these stories come from? Well, the black and the yellow stories, the enablers, are usually the result of architectural decisions. And you see here, there is, of course, the architectural decisions, remember the architecture microcycle, they are there to address architectural concerns. Now, where do these architectural concerns come from? Well, they come from the stakeholders that need new user features. And they sort of supply the green and the red stories. And all of that comes together here. And of course, the main problem now is how to prioritize all of these stories in such a way that the yellow and the black stories, even though they do not create direct business value, still get sufficient attention that they are not left behind. Because what happens if you leave all of the black and the yellow stories in here? Well, there are enablers. So that means that some of the green stories will become much harder to build or maybe even impossible to build if the architecture is not there. For example, let me give you one example. A good example of a yellow story in an enterprise architecture setting is an API gateway. So an API gateway is something that no end user will ever see. It is a way to make the data inside your organization's landscape available outside of that organization. That's what an API gateway is for. But by itself, it doesn't have any business value. However, the business value is indirect because it enables, for example, mobile apps and websites that are outside your organization to use the information that is inside your organization. So it's very hard to write a mobile app without an API gateway. So if there's a green story here for a mobile app, it can be done, but it will be a clunky solution and it will be very, very hard to manage in terms of security, information flow, etc., responsibilities, etc., etc. So I hope that example clarifies this a little bit. Okay, so you will have gathered by now that this is mostly about dependencies, right? There are dependencies between the yellow and the green stories. And there's also dependencies with the outside world and the events happening there. So for example, if we hear that a competitor will release a shiny new next generation product, we need to have our product updated with a shiny new feature as well. Otherwise, they will get more market share from us. But maybe that new feature cannot be built if that piece of architecture runway here, that yellow thing is not built first. So this allows us to reason about how this business value comes into being and to basically pay sufficient attention to architecture and to technical debt in our continuous architecture work. So I realize it's a lot of information, but maybe if there are some specific questions, we can talk about that. I only have one principle left, which is architecture's teamwork. That of course is not so hard to explain. In a traditional setting, a waterfall-like setting, it was mostly architecture work that was done by a particular person. In an agile setting, it's less defined than that. Let me explain. So this is a screenshot from the agile manifesto website. If you want to check it, agilemanifesto.org. The best architecture's requirements and designs emerge from self-organizing teams. I've already mentioned this principle. I think this is, well, from my perspective, certainly one of the sentences on that website that has caused most damage. Not because it's wrong, but because it was misunderstood. So people saw the word emerge and they thought that it meant that it magically would happen. As long as we abide with the agile bible, then we don't have to think even about architecture because it will emerge magically. Of course, it doesn't say that at all. This sentence is about responsibilities, about ownership, self-organizing teams. Basically, it already says a little bit that in order to deal with architecture and requirements and designs, you need to spread that responsibility and you need to create ownership with more than one role. Basically, if you look at the classic architecture, a way of doing architecture, you used to produce an architecture document which had hard rules. It basically gave the constraints within which the developers were then allowed to make their own smaller decisions as long as they do not violate the constraints that were set by these red hard rules. Now, in evolutionary architecture, it works differently because if you have this big red piece here which basically puts your architecture in, sets your architecture in stone, then there is no room for evolution. What you need to do is you need to have a more lightweight upfront architecture. That's the red part. Then there should be a lot of gray stuff here which you can say are suggestions, but these are left open and have to evolve. People call this design intent. You are certainly allowed to give the teams multiple options, for example, for making a particular decision. Filling in this gray area here is the joint responsibility of the delivery team and the people doing the architecture. This is the key to the architecture's teamwork thing. It means that in evolutionary architecture, architecture becomes much more a vertical function. What I mean by that is referring to the metaphor of architecture as an elevator. Architecture, just like an elevator in a skyscraper, connects levels. This is an example of connecting levels, the architecture level with the realization level and all the levels in between. How do you do that? I won't go into detail for this slide. There are various styles here. You have the classic architecture, you have the completely crowdsourced architecture where there is no named architect, but there are some useful models in between like architecture marshals and architecture owners that you can use to base your way of working in doing architecture's teamwork on. Here are some references that might be interesting to you. That's basically all the slides I have for now. Let's open the mic for questions. Thank you very much for the presentation. I will start with one hand raised. Matias, thank you for that. There are some questions in the chat room. I will start with a comment on this slide with updated scrum cycle. If you can open it when I read the comment. Tom McDermott writes, that was an excellent slide. Neil Harrison agrees with him, writes, really pulled out a hidden dynamic at work that often makes prioritization feel like a challenging conversation. That's just a comment on that topic. The question which we have is, do you have these green ones, the user features above and the defect below is just a coincidence or that means something? From your point of view, user features are more important than defects or it is not the saying of this slide? No, the position of the colors here is due to this matrix. This is a Boston matrix and basically what is on top here means that it is positive value and the stories at the bottom of this matrix, they represent work to remove negative value. The green is work to add positive value. Red is work to remove negative value, but all of those are visible. This is direct value. On the invisible side, once again, positive indirect value is yellow and the removing indirect negative value is black. Okay, thanks for an answer. We have two options. Dear colleagues, you can send questions and the questions and answers section by text or you can raise your hand. Matthias, I see your hand and now I give you, I think, the opportunity to say something. You can turn your mic on and you can ask the question if you like. You might even turn on your camera if you had one. Yep, so you're technically allowed to turn your mic on, but I cannot do that for you. Okay, meanwhile, when you prepare yourself, just interrupt me when I'm asking for the question. Oh, no, there are no more questions in the queue. There is another one question from an anonymous viewer. Hello, I have a curiosity about how to represent the architecture in the most effective way, but also avoiding excessive documentation. My company, Mechanical Engineering, chose to deliver the architecture of each department only in a graphical form, block diagrams. Afterwards, on the top level, the diagrams are joined and this method actually simplifies the process. How other companies do that? Which are the most common tools representations use it? Yeah, so excellent question. So it depends a little bit on what you mean with architecture. So if you say architecture is decisions, then, you know, but that's not what this refers to. This is very clearly about the modeling, right? Block diagrams are models, right? And if you constrain yourself to only a graphical form using either a tool or some or Visio, you know, you can have more intelligent tools that there are, of course, software architecture modeling languages like UML or Archimate.  So you need to basically separate this documentation based on the value that's in it. So the model, let me go back to the relevant slide here. It's this one. The block diagrams are in the architecture knowledge repository. But they are probably not fit for consumption by business stakeholders. So you need to make that translation there. And that means that you probably won't get away with just having one style of modeling or one style of communication. You know, just referring back to the architect elevator, you need to translate. You need to speak the language of each level in your organization. And of course, in the engine room, they may be perfectly happy with these block diagrams. But if you go a few levels up towards middle management or even towards the penthouse where the board sits, then you need to make that translation in these views. Does that answer the question? Anonymous attendee, are you happy with that answer? Okay, we'll never know. I do hope I will get a feedback. But meanwhile, yes, thanks. That isn't so good. Another one question. Do architecture models play a role in the workflow presented in the slide 23? If so, which one? It is an important one. Sorry, do what was the architecture models play a role in the workflow presented in slide 23? Yes. But it's hidden. So the models are used to, for example, to help make the bed make the right decisions, right? So the models are, they give input because they help us to validate the decisions that we make, right? And then very often, the models that we make in some form accompany the stories, the architecture runway and the technical death stories, but specifically the architecture runway stories are quite often accompanied by models that will help the team to realize that story. Because they, you know, because they have the model, it makes it easier for them to understand how it should be, should be created. That is the most important place of the models in this, but it's hidden. What's the difference between solution backlog and sprint backlog? Yeah, so the sprint backlog, the solution backlog basically contains all the work that all the stories that stakeholders have asked for. And so that's, and the sprint backlog can never contain more stories than you can do in one sprint. So one, one, let's say two weeks, two week cycle, the sprint is a cycle and it depends on your organization, whether that's one week or two weeks or maybe even six weeks in some organizations, but sprint backlog basically is filled up with stuff that can be done in that one sprint. And the process of picking the right stories, prioritizing the stories in your solution or product backlog and filling up the sprint backlog for the next sprint, that is a very important process because if you do it very naively, you will forget the enablers, you will forget the yellow and the black stories because the role that is usually responsible for this arrow or this gate here is called the product owner role. And you know, one of the first things they learn is whatever you do prioritized by business value. And then lots and lots later, they learn the difference between direct and indirect business value. But by that time, many have already lost interest and then they tell you only do green stories. This actually happened in a lot of organization and can be really harmful. Okay. We have one minute left. Alexander, do you think we can answer one more question? I think, I think we're pretty much done though. There are no questions more. The Matthias, he just wrote the message that he got the answer from I think the another one attendee. Okay. And I think it's the perfect time to retake, make a recap. So I will say thank you again. We have a lot of comments, like people say that that was a great presentation. They say thank you and so on. That is important thing. I say the same thing again. What I will do is, dear colleagues, the recording of this presentation will be available for INCOSE members on INCOSE Connect and for GFSE members on GFSE Internet. Definitely. Some of the webinars are being published for some reason on YouTube channels of both chapters or organizations. I will send you a link in the chat room. We do not have any decision on this specific webinar, but who knows. You can meanwhile subscribe to the YouTube channels of INCOSE and GFSE. And what I will do before we say goodbye to all of you, again, we have further webinars. There is another one next join GFSE INCOSE webinar. You can take a look at that. It could be interesting for you as well. CISML hashtag architected description. And the next INCOSE webinar from the HL systems engineering working group we have, by the way, at INCOSE, the HL systems engineering working group. And I would be really curious if somebody from the working group took part at this webinar because I see a clear interesting collaboration opportunities here. That is really, really interesting stuff. So, nevertheless, I think that was pretty much it. I think you all will be notified by an email about how you will get the recording of that as a member. And I say thank you again. And that was pretty much it from our side. It's I think just in time because I hear the ambulance coming to get you. No, no, no, I think I deny it's always that way here. But thank you. That was about we were about like 130 people at the peak. And that was really great to have you all day. Thank you very much. Thank you, LTV. Thanks for your questions, guys. Okay, bye bye. We see you definitely. Bye.


Hello and welcome to the session. This is Professor Farhad and the session we would look at introduction to adjustments. This topic is typically covered in a financial accounting course as well as intermediate accounting course, also covered heavily on the CPA exam. What I'm gonna do first, I'm gonna lay the groundwork for adjustments. Why do we need adjustments? Why is that necessary? Then in the next following sessions, I would look at each adjustment separately and explain them. As always, I would like to remind you to connect with me on LinkedIn if you haven't done so. YouTube is where you would need to subscribe. I have 1,600 plus accounting, auditing, finance and tax lectures. Please, if you like my lectures, please like them, it doesn't cost you anything. Click on the like button, share them, put them in playlist. If they benefit you, it means they might benefit other people as well and connect with me on Instagram. If you need additional resources, please visit my website farhadlectures.com. You'll have access to material, multiple choice through false, the notes, the PowerPoint slides. And if you're studying for your CPA exam, 2000 plus CPA questions. So let's take a look at the idea of adjustments. Why do we need adjustments? Why do we need to prepare adjustments? Well, we have an accounting, something called the accounting period concept or the periodicity concept. Simply put, what is this concept and how does it fit into this picture? Well, the life of any company can be broken down artificially. For example, we can take the company and usually even if you are not a medium or a large company or publicly traded, at least annually, you have to sit down and prepare your taxes, at least annually. So basically most businesses, at least they have to prepare their financial statements or they have to report annually on their performance, even though they don't have to report to a bank or investors or anybody else, they have to report for taxes. So some companies might report their financial statements annually. So that's their period. Some companies, they may break down the life of the company into two artificial period and they might report semi-annually. So every six months, they will prepare the financial statements. Okay, here we'll prepare the financial statements once a year. Why would you prepare the financial statements on a semi-annual basis? For example, you have investors, you have creditors, they want to know how well the company is doing or not doing so you prepare financial statements for them. That's why you wanna do it on a semi-annual basis but they're okay, they can wait six months but beyond six months, they don't want to wait. Some businesses, guess what? They want to report, they want their financial statements on a monthly basis. Every month they want the financial statements. Well, a case in point is what I used to practice accounting. What I used to practice accounting, we had a lot of customers that were MDs, medical doctors, dentists or just general doctors. And what they wanted, or at least my partner convinced them that having monthly financial statements will be beneficial for them, which it is because you know what's going on on a monthly basis, what's going on with your practice. So what we did is we'd prepare financial statements every month, that's fine. It's gonna cost more money but it's gonna give them more value. But as we prepare those financial statement constantly, we get efficient at doing so and the timing it will take us to do so it will go down. But that's a monthly reporting period or we can do it quarterly. Now quarterly is very common, not common, it's mandatory. It's common in the sense that everyone has to do it. It's mandatory for publicly traded companies. So publicly traded companies, they have to report on a quarterly basis and there is no really such thing as a fourth quarter. They have to report the annual. So for the whole year. So publicly traded companies, they have to. They have to report their financial statements on a quarterly basis. Now any period other than a full year, it's called interim financial reporting. Interim financial reporting. And let's talk about annually. You could be annually January 1st till December 31st. We call this the calendar year or you could be any 12 month other than January 1st to December 31st. We call this the physical year. Now we need to talk about another term that's important. It's the difference between accrual and cash accounting. So we have accrual basis and cash basis of accounting. So we need to know what is accrual and what is cash basis? Well, we're gonna start with cash basis. It all has to do accrual and cash basis has to do with when do we recognize revenue? When do we recognize when? When do we recognize revenue? And when do we recognize expenses? So simply put, at what point do we recognize revenue? At what point do we recognize expenses? Starting with the cash basis, very easy. We recognize revenue when cash is received. Very simple concept. If I have the revenue, if they paid me its revenue, that's it. Expenses are recorded when the cash is paid. Obviously cash, cash in, cash out. So the cash basis is basically based on the cash. If you paid cash, it's an expense. If you received cash, it's a revenue. And that's very simple and easy to understand. However, that's not the method that we learn, nor that's the method for generally accepted accounting principle. The method that we need to learn is, which is we already kind of learned it without even calling it accrual, is the gap basis, which is accrual basis. So under accrual basis, when do we recognize revenue? We recognize revenue when the product or services are delivered. Simply put, when we earn it. Earn it means we did the work. If we earn something, it means we completed the work. I cannot bill you for something if I did not do the work for you. So once I can bill you, it means I did the work. It means it's revenue for me. You may pay me immediately, okay? So you may pay me now or you may pay me later.  Now, when do we recognize expenses under the accrual? We recognize expenses when they are incurred. What does it mean incurred? It means if they happened, if we have the obligation for the expense, then we have an expense. We don't have to pay it in cash yet, but we still have an expense. I always ask my students to kind of think about this. For example, we are in January, February. And let's assume you paid your rent for January. You paid your rent. You had the rent expense, but you paid it. In February, you don't have money to pay your rent. No money. Do you still have an expense? Yes, you do. Although you did not pay it, you still have an expense because now you are responsible for paying it. Although you did not pay it, you still have an expense. We're gonna see what do we call this later. We call this accrued expense, but we'll hold on that on the terminology. But the point is you have an expense as long as the expense did was incurred. And the best way to illustrate the accrual versus cash is just to look at a quick example. Then we're gonna work with this a little bit further when we work the adjustments. But the adjustments are based on the accrual basis and based on the periodicity principle where revenues and expenses have to be reported in the correct period. So let's take a look at this transaction. First, it treated as on a cash basis. Then we treat it as an accrual basis just to see the difference. Let's assume a company paid 2,400 for 24 month insurance policy beginning December 1st. Here's what's gonna happen. Under the cash basis, what do I do? Under the cash basis, I paid, therefore I have an insurance expense 2,400, credit cash 2,400. I have an expense. This is EXP or expense damages. Under the cash basis, I have an expense. So on December 31st, I paid 2,400 cash. Using the cash basis, the entire 2,400 would be recognized as an insurance expense in 2019. And notice this month is highlighted in yellow to tell you the insurance expense took place on in December of 2019 when I made the payment. So no insurance expense from the policy would be recognized in 2020, 2021, which is that's what we learned. We learned that when we prepay for something, it's an asset initially, then we expense it later. So let's look, this is the cash basis. Let's look how we treat this transaction under the accrual basis. Under the accrual basis, what's gonna happen is this. We have, we paid 2,400. We're gonna divide this by 24 month and we're gonna expense it $100 a month. Therefore for December, we're only gonna expense 100 for 2019. For 2020, we're gonna expense 100 each month. And for 2021, we're gonna expense the remaining 11 month. So on the accrual basis, 100 of insurance expenses recognized in 2019, 1,200 in 2020 and 1,100 in 2021. So what we did is we took the expense and we spread out the expense over the period it covers because this insurance policy doesn't only cover 2019 because under the cash basis, it's as if it only covered 2019. That's all with the expense took place. Well, the expense should take place over 2019, 2020 and 2021, 11 month in 2021 because it's serving those periods. So the expense must be matched. The expense is matched with the period benefited by the insurance coverage. Therefore, what do we do when we buy the policy initially? When we buy the policy initially on December 1st, we're gonna debit a prepaid insurance 2,400 and we're gonna credit cash versus an expense when we debit it earlier. So this is prepaid insurance. Remember, this is an asset. Then we're gonna learn later on. We need to adjust this account. We'll work on that shortly. Two more topics. I just wanna make sure we cover them one more time although we kind of cover them directly or indirectly recognizing revenue. Okay, the revenue recognition required that revenue must be recorded when the goods or services are provided to customer and at any amount expected to be received from the customer. Simply put, you did the work. How much do you expect to receive? This is the revenue recognition which is the revenue recognition under accrual. Expenses or the expense recognition or the matching require that expenses be recorded in the same accounting period as the revenue that are recognized as a result of those expenses. This is matching of expenses with the revenue benefit as a major part of the adjusting process. Remember for the insurance policy, we did not expense the whole thing in December of 2019. The reason is because we're gonna give all the expense for one period and that's not true. We have to match the expense to the period at generating revenue which is one month in 2019, 12 month in 2020 and 11 month in 2021. So we are here complying with the recognizing expenses or the matching principle. So having setting all this information, we're gonna learn about four types of adjusting entries that help us comply with the time period assumption with revenue recognition and expense recognition. Okay, that's why we have those is we wanna make sure the revenue is reported in the prior period, expenses are reported in the prior period. To do so, we're gonna deal with four types of adjustments and the four types are the furl of expenses or prepaid expenses. This is also called prepaid expenses, the furl or revenue or this is called unearned revenue. So those two are called the furls, the furls. Then we have two more. One is called accrued expenses and one is called accrued revenue. Those are called accruals. Okay, so we have four types of adjustments, two deferrals and two accruals. What are we gonna do? We're gonna go over each one of them separately, each one of them separately and those adjustments, they will help us make sure our financial statements are properly reported. So how do we prepare the adjustments? Well, it's a three step process which I will go over when we'll do on this but if you're gonna copy this down, first determine what the account, what is the current account balance? So what is the balance now that's showing on the trial balance and we have to determine what is the balance should be? What is the balance should be? What is it now and what it should be? If it's now a hundred and it should be a hundred, I have no adjustment to make. If it is now 100 and it should be 80 then I have to reduce it by 20. If it's 100 and it's supposed to be 120 I need to increase it by 20. So this is how we prepare adjustments. We need to know what's the balance now and what's the balance should be, what's the correct balance and we make the adjustments. So we take the difference between step one and step two and prepare the proper adjustments. Now, this will not make any sense unless we look at actual adjustments and the first adjustments we're gonna be looking at is the fertile of expenses or prepaid expenses which we'll see in the next session. As always, I would like to remind you if you're looking for additional practice, exercises, additional help studying for your CPA exam, visit my website, invest in your career. It's a long-term investment. Study hard, accounting is worth it. And if you like my lectures, please again, like them, share them, subscribe. Good luck and study hard.


Hey, this is Thomas Surpukin, Associate Administrator for NASA Science Mission Directorate. And I want to congratulate you for the opening of this facility. This facility is focused on orbital debris, a topic that is going to be even more important as we go forward, as we launch thousands of spacecraft into a lower orbit. It's absolutely critical to understand where these objects are and to understand their dynamics. Also, I want to remind you that this facility has already transformed our understanding of nature. Wilt, too, found by Professor Wilt, who was really right there when this facility opened, has been the site from which Stardaus brought samples back to Earth, transforming out our understanding of comets. Congratulations and thank you.


Hey guys, what is up? Welcome to my channel. For today's video, we are going to be doing my monthly eyeshadow paleo rankings So if you want to see what the worst was and what came out on top then just keep watching Hey guys, if you're new here, my name is Morgan. I am a product knowledge enthusiast I just love knowing anything and everything about all the new makeup on the market and sharing my thoughts with you guys particularly eyeshadows, I Love me some eyeshadows So how many palettes did we try one two three four five six seven eight nine palettes this month And honestly looking down at my table here. There's not a palette that I do not like So even the worst palettes are actually really really good. So this video is gonna be pretty positive So we're gonna start off with number nine my least favorite palette this month, which is still really pretty That is the Odin's Eye saga of Freya. Oh my gosh, you guys were coming down my throat because I was pronouncing it free Ha I'm learning to Spanish right now. Okay. I was like pronouncing it in Spanish anyways saga of Freya Chapter one tears of Freya. So this is what it looks like Odin's Eye came out with a Freya collection So there are three palettes that you're gonna see reoccurring in this video But this is what the palette looks like quite honestly It's ranking at number nine because it really just is not my favorite color story of everything. It's probably my least favorite It's a little little too warm for me And I did struggle with a couple of the colors kind of fading away But again, you can get a gorgeous look with this palette the quality is decent to the shimmers or what stand out in here Really incredible. Honestly, like I recommend this palette. I think it's nice It's the one that I recommend the least in this video, but I recommend it I think it's really pretty this whole collection in general Odin's I did a fab job with so Number nine I like it moving on it's number eight I have only used this palette once I will be honest with you and I'm very impressed by it This is the Sephora collection. I love palettes in the shade I think it's warm cool because they have like warm medium cool medium Light dark deep. So I chose the medium cool one So I just did a video earlier this week Testing a full face of Sephora collection. I have always been so curious about the product So I thought why not make it a video? I got the products on a decent discount And this was the palette that I chose honestly I was doubtful at first the packaging looked boring and the shadows looked a little bit cheap to me You know a little makeup revolutionary and then I tried them and the quality here is a beautiful This is a great everyday palette for me. I love these tones. It's really in a portable compact I think the reason that it's ranking at number eight just looking down is because it's kind of boring compared to everything else But I like boring the shadows really impressed me. This is a great value. It's $14. This is a great little guy you travel with It's not too expensive. So if it breaks or you lose it It's not that big of a deal, but it contains literally every eyeshadow shade You could need for a vacation or just the everyday to grab for throwing your purse Yeah, I really like this the mattes and blended really well the shimmers were really gorgeous It wasn't like a wham-bam shimmer. You know the shimmers aren't Superb, but they work and the mattes blend really beautiful. I don't have anything bad to say This is just where it felt. I actually am really into these palettes and I recommend them They're really great for the price another $14 palette that is really fabulous that I got is the elf the new classics Now elf eyeshadows can be a little bit hit or miss for me Sometimes I feel like the quality is especially when they try to be a little bit too crazy with their color story The formulas just don't match up but with a good neutral palette. They did a fabulous fabulous job with this one So this is another one. It has all the colors you could need I compared it to my Scott Barnes palette So if you want to see how that compares to Scott Barnes, then check out that video. So the shimmers in here They're good. They're not the best the mattes or what's amazing in here, which normally it's the other way around I love the mattes in here. It's a really easy to read palette It's very easy to create a look follow along not have to think about it I actually you know, I tried this only last week and I've used it three times That's a lot the lasting power on this isn't the best But it's a really solid palette with great neutrals definitely worse $14 in comparison to the Sephora This for has actually better quality I like the color story of this better because you have some fun pops in here You have some warm tone neutrals. You have some cool tone neutrals You have some grades and silvers in here. You have this fun green gold the color story is a little bit better for me So that's why I like it number six. We're back to miss Freya over here from Odin's Eye So this is the big guy from the Odin's Eye collection. This is the Freya saga palette Get it out of its cover a little bit clunky for me But in this case that's okay just because of the style of the palette supposed to be like a book So the first side you open it kind of like warm reddish kind of tones over here I created a gorgeous look with this side of the palette and then you flip it and then you have some more Greeny kind of neutral tones this you can actually get a really gorgeous neutral smoky eye this shade all over the lid I'm drooling just thinking about it. I haven't used every shade in here But if you aren't familiar with Odin's Eye They definitely have a really great formula for the price as well and their shimmers are what puts them on top But I don't love love love this color story. I think it's great I think it's versatile, but it's not a palette that I look at and I feel immediately Inspired by again really really pretty. I don't know. This is just where it fell. It's not my favorite color story in this video Moving on to number five. I have not shut up about this palette recently Wait till we get to the other ones because I've talked a lot about those as well But this is the color crop and Malibu Barbie palette I've talked about this in my top 10 recommendations for summer Because it truly is just such a fun summer palette You can also get neutral looks in here as well You have the fun pops of blue of pink of yellow you can get a warm look you can get a neutral look You can get a really hot fire pink look now It's not top-notch quality like this shade right here in the middle You maybe use a glitter glue or a wet brush, but you know what it works It's a great value actually this is one of color pops more expensive palettes But color pop is having their 30% off sale Maybe not at the point that this is uploaded, but hopefully you got it during the sale if you did want it But seasonally I'm into this. I think if it was winter right now, this would probably be number nine I just wouldn't be feeling the color story, but because it is summer. I now have a full-time career in the beauty world I'm all about the color having fun. I'm in a great mood every day. I really like this one This one has been fun for me. I've had a lot of fun with it This is my third video I'm filming today, by the way, so I I'm going loopy Moving on oh my god. I'm so thirsty moving on to palette number four last time I'm gonna talk about Odin's I sorry their collections always have so many palettes This is the chapter 2 cat with golden carriage Okay, so if you're gonna get one palette from this collection You need to get it solely because there's a cat on it No, I'm just kidding it actually is the best color story in my opinion as well But as you can see the artwork is absolutely stunning as Odin's I palettes always always are but what a unique color story If you're looking for a fun unique color story for summer if you really like blues You're gonna love this the shade right here bling. I Just dug my nail in there one of the most insane shadows of all time a beautiful blue Again, I just think you would have so much fun with this palette be a little bit careful It can get muddy if you don't use it the correct way But this one is really fun and I always love to point out unique palettes and this one is unique Number three this one is not unique and it was actually just featured in my actually these last three We're all in my June favorite. So this will be repetitive But the Patrick Tom major dimension shadow palette honestly, it's a boring But I love boring these are shadows that I've been reaching for kind of off-camera. It's not an insanely Unique palette. It's not fun. It's not the reasoning for every other palette that I put here It's just easy to grab for so a downside of this I feel like is you really can't get a ton of different looks But you know exactly what kind of look you're gonna get and the thing is that look that I'm gonna get with This palette is the look that I want to wear a lot. So I actually have been reaching for this a handful of times I want to say like five or six times I've just reached for this to throw on a quick every day. I look you know, it's not a phenomenal Palette, but it's just something that you end up using boring but functional and it works The quality is great that shadows blend the shimmers are really pretty I wish you would have put some different shimmers in here though. There's something missing in here I feel like but oh my god apparently not because I keep grabbing for it So I have to put it at number three. It's probably my most used palette this month moving on to number two I'm counting these all this one palette because you guys know, I feel like these should all be one palette But these are the Sydney Grace and Temptalia collaboration. I am currently wearing radiant reflection It's arguably the most colorful one, but I'm wearing the pinky side Rose tones here. So you can definitely get a wearable look with this palette even though it's the most colorful I could have even made it more wearable, but I always like to go a little extra on camera Anyways, I mean just with Sydney Grace in general They have some of the best eye shadow quality ever if you like pigment you're going to love these if you like really Rich mats and rich shimmers lots of pigment lots of coverage lots of reflex You will love the Sydney Grace formula I must admit while I did give a little bit of shade to the way that she organized the palettes Temptalia chose some of the most beautiful colors. I've ever seen I mean the looks that you can get with these Honestly, literally this these palettes contain some of the most beautiful shades Definitely watch my swatch and sip where I covered these palettes if you want my full review my full kind of thoughts and recommendations But I will say if you aren't sure which one to get quintessence This one right here is my favorite But I love purple tones and cool tones and all of that and this contains those so this one is my favorite But they all are phenomenal. All right It is time to move on to our last and final palette for today's video You know what it is, don't you if you've been watching my videos, you know what it is This is the 8b h. Norvina volume 5 I think I featured this in 10 videos this month because I just love it so much So it's a giant palette if you don't like giant palettes this one's not for you But I also really love how functional the packaging is this mirror is fantastic I've just been putting out on my desk and I can do like a full face of makeup without having to like scrunch in a tiny little mirror But that aside, I mean if you like purple is this is it for you I feel like the color story in here is one of my favorite color stories for purples I love the neutral row that you have here I just feel like the color placement everything was really well thought out I think that these Norvina palettes seem to have some of the best quality as well I feel like a bh really revived to themselves with this launch because everything has been kind of yawn prior to this and That Norvina palette like got me pumped again to see what they can come out with. I was ready for it I was excited for it. I really love it I don't think you'll regret it if you get your hands on it as long as it's a color story that you're interested in But also I just love the color story. It's purple So it was gonna be somewhere near the top as long as the quality worked All right, you guys there we have it those were all of my rankings for this month's eyeshadow palettes Yeah, I already have on my list for July palettes that I've tried two palettes. So it's July 4th No, it's July 5th, and I don't think it would grow too much since I'm gonna be out of town But we will see how long next month's list is but this isn't the longest list that we've had so Anyways, I hope you guys enjoyed this video if you've tried any of these palettes out Let me know what you think or you can rank your own palettes. I'd love to hear it I love reading your guys's comments when you participate. So if you aren't subscribed to my channel already I would love it if you would consider taking the time to do so and I will see you all in the next one I guess have a good one