Software Architecture Monday

hello everyone and welcome to software architecture Monday my name is Mark Richards and in this lesson number 145 we'll take a look at some techniques for analyzing trade-offs within architecture you can see a listing of all of my lessons by going to my website developer2architect.com of lessons and there you can view the video or watch it through YouTube most of the material in my software architecture Monday lessons come from these two books that I wrote with my friend Neil Ford fundamentals of software architecture and also software architecture the hard Parts as a matter of fact this lesson comes from both of the books as a matter of fact let me show you where the fundamentals of software architecture come in because in that book we coined the first law of software architecture which basically States everything in software architecture is a trade-off how true that is so let's take a look at how to do modern trade-off analysis which actually is the subtitle for our second book architecture the hard parts when we talk about analyzing trade-offs let's say an architect is faced with this kind of decision now I can't decide whether to create a single payment service or separate Services one for each payment type this is a typical architecture trade-off analysis decision that we have to make now let's see a technique of how to actually analyze trade-offs and make decisions whenever we analyze trade-offs the the first grounding aspect are corresponding business drivers for example let's say the business driver for our particular system is time to Market in other words speed to Market getting changes out to our customers as fast as possible that is the primary concern of the business now what we do is take those business drivers those business needs and then kind of interpret or translate those to architectural characteristics and as a matter of fact time to Market translates to high levels of maintainability testability and deployability and maintainability is the ease of and speed of being able to make changes in our code testability is the ease of and completeness of testing and deployability finally is about the frequency of deployment the ceremony involved and how much risk there is in that deployment all three of these are needed in order to support time to Market which by the way is a composite characteristic called agility the ability to respond quickly to change so we're faced with our decision should I make one single service or three separate Services one for each payment type well let's actually analyze some scenarios and extract some trade-offs so that we can actually then analyze what's important to the business so let's do first scenario where we have a lot of Need for updating maybe the credit card processing or we expect a lot of updates to our payment types well in a single payment service I would have to of course update the credit card processing code and may help to update the database the point is that I've got a larger testing scope and a lot more deployment risk whereas if I separate them now I've Consolidated just that particular payment type in its own service easy to maintain easier to test more completeness of testing and also less testing scope less deployment risk a lot less ceremony to deploy as well and so we see by separating those we get great maintainability testability and deployability but what about the scenario where we may want to add a new payment type let's say Reward Points well in the single payment service I'd have to add that code which means I'm changing that service and its corresponding data oh which means again I've got that larger testing scope more deployment risk maybe not as much completeness of testing watch what I would need to do if we separated the payment types all I would have to do is simply code up the service its corresponding tables and deploy nothing else is impacted anywhere and as a matter of fact that's a great example of architectural extensibility in our system however we have one more scenario we need to cover and that is users can use multiple payment types for for paying for an order well in our single Consolidated service it's pretty fast single entry point goes in we have one class file that maybe orchestrates those we have a database transaction we can do commits and rollbacks it's um not that difficult but what about if we separate the payment types then notice the very first thing I'd have to do is add another service a payment orchestrator and I'd have to Route all of my endpoints to that payment orchestrator whether we're just paying by credit card or multiple types and so this is going to be well first of all with a little bit of a single point of failure which we could certainly have multiple instances of the orchestrator but now I've got multiple Network hops so it's going to be less performance but also I no longer have a database transaction I'm in distributed transaction worlds so that if I charge the credit card maybe charge PayPal go to apply the gift card and that service isn't available there's no way to roll back those other ones I'd have to maybe apply compensating updates or something so we can see by separating them I've got less performance and data consistency so now that I've kind of done some scenario analysis to be able to extract the trade-offs now I can come back to our flow here and as a matter of fact that trade-off analysis shows well it really boils down to which is more important performance and data consistency or maintainability testability deployability and extensibility we tied those back to the architecture characteristics that were derived from the business drivers and we see there's almost a direct match here that by separating we're actually helping the business in their needs and the corresponding drivers and so the Clear Choice here because of our business needs and corresponding architecture characteristics is of course to create separate services this is one example of how notice in order to do modern trade-off analyzes you have to understand the business drivers and you'll have to be able to translate those to corresponding architecture characteristics because those generally are the things we're extracting when we have a decision to make all right so this has been lesson 145 analyzing trade-offs as a matter of fact I think I'll do some future lessons where we'll go through some trade-off analysis with all sorts of other kind of decisions for example protocols communication protocols maybe databases all sorts of things that we can now start to do some trade-off analysis with so look for those in future lessons in software architecture Monday thank you so much for listening and stay tuned and two more Mondays for the next lesson