The Intersection of Architecture and Implementation - Mark Richards - DDD Europe

Summary

In the presentation "The Intersection of Architecture and Implementation," Mark Richards discusses the common—and often frustrating—misalignment between software architecture and implementation. Using engaging storytelling and relatable scenarios, he highlights how such misalignments often lead to operational failures, even when individual decisions seem sound. Richards emphasizes the importance of aligning architecture with implementation through proper governance, collaborative techniques, and architectural thinking. He introduces architectural decision records as effective tools for bridging gaps between architects and developers, ultimately calling for a synchronized and iterative approach to software design and development.

Highlights

• Operational misalignment often results in system failures. 😱
• Architects and developers have distinct roles but must communicate effectively. 💬
• Effective collaboration can resolve architecture-implementation gaps. 🤝
• Fitness functions can monitor system performance and detect issues early. 🧐
• Architectural thinking empowers development teams to make better decisions. 🧠

Key Takeaways

• Architectural alignment is crucial for system scalability and performance. ⚙️
• Misalignment often occurs between design and implementation, leading to operational failures. 🔄
• Fitness functions and governance tools help ensure alignment between architecture and operational needs. 📏
• Architecture Decision Records (ADRs) facilitate better communication and decision-making among teams. 📝
• Collaboration between architects and developers is key to preventing misalignments. 🤝

Overview

Misalignment between architecture and implementation is a common issue that can lead to significant operational failures. Mark Richards illustrates this problem using the example of a system designed to support half a million users failing at just a fraction of that capacity due to poor implementation decisions. This narrative highlights the necessity for architects and developers to work in tandem.

Richards suggests implementing governance through architectural Fitness functions and decision records to bridge the gap. By illustrating operational scenarios and using architectural decision records, he emphasizes the need for a shared understanding between design and execution phases. This approach can help ensure that architects' decisions align closely with how systems are developed.

The session concludes with discussions on improving the collaboration between architects and developers, including fostering architectural thinking among teams. Richards advocates for developing a culture of continuous engagement, where decisions are shared and understood, thus aligning goals and improving both developer satisfaction and system reliability.

The Intersection of Architecture and Implementation - Mark Richards - DDD Europe Transcription

• 00:00 - 00:30 all right thank you all right fantastic well hello everyone and welcome to the intersection of architecture and implementation I want to start this talk
• 00:30 - 01:00 with a little story so a business sponsor says we need an architecture that will support 500,000 users concurrently uh with an average response time of 600 milliseconds underload and the architect says no problem I'm on it and the architect develops creates an architecture so the architect brings that architecture to the development teams
• 01:00 - 01:30 and says here's the uh here's the new architecture well you can guess the development team has a few questions uh first question well for all of the asynchronous communication that we have um should we use topics or should we use streams like in Kafka what do you suppose the answer is from the architect oh no it's not it depends you see there are two very famous continual
• 01:30 - 02:00 quotes from Architects you're right the first one is it depends and you know what the second one is that's an implementation detail yeah but what about the persistence framework what should we use there again that's an implementation detail look look my job is architecture your job is implementation now get to it and of course the developers implement
• 02:00 - 02:30 the architecture and what do you suppose happens once we hit about 1,000 users errors exactly and after about 2,000 users the whole system just comes up in Flames I think you're going to need this for the rest of your talk so I'll I'll leave that here okay thank you yes there we go
• 02:30 - 03:00 I better put this somewhere because we will be using a lot of it yes this is frustrating this is an all too common situation where we try to do the right things but it doesn't work why turns out most of these cases are because the architecture is not lined up and aligned with the implementation and vice versa and that's a exactly what I want to show
• 03:00 - 03:30 you in this session I want to talk about the intersection of architecture and implementation where they intersect but also where they diverge because they do so I'm going to talk about some of these problems but then I'm going to show you some techniques and tools you can use to realign and bring architecture and implementation back together
• 03:30 - 04:00 in our journey uh we'll be looking at three roads we're going to travel on the first road of alignment will be that of operational alignment the second Road on our journey will be that of structural alignment between the architecture and implementation the Third Road will be about constraints that we place on the architecture which also is a form of alignment
• 04:00 - 04:30 so we're going to take a look at all three of these and then see how to fix some of these problems well let's put some stop signs on our structural and constraint and let's take a journey down that operational road to see how this alignment works well or doesn't work so we talk about operational alignment I'm talking about those operational kind of characteristics as
• 04:30 - 05:00 the system or product or application is running does it scale is it reliable is it responsive all of those kind of operational characteristics so here's another scenario well in this new system we're expecting anywhere from thousands to upwards to half a million concurrent users so what does the architect do well the architect goes to our star rating
• 05:00 - 05:30 chart that we developed in a ne's book The fundamentals of software architecture and does some qualitative analysis comparing the quality of one thing to the quality of another which architecture would be suitable for this kind of problem well one star is really bad five stars is really good well our concerns with this kind of problem are all about scalability and
• 05:30 - 06:00 elasticity and if we take a look we indeed do have some architectures that rate Five Stars for these microservices being one and space-based architecture being another Well due to kind of the shape of the problem and some of the complexities with space space-based the architect chooses to use microservices and architecturally this is a really good choice because it will satisfy those
• 06:00 - 06:30 requirements of thousands to a half a million users that kind of elasticity because not only of the bounded context but because of the short in terms of hundreds of milliseconds of meantime to start with each individual service yeah this architecture will work and it's a good choice now let's go to development so we have an order
• 06:30 - 07:00 placement service where a customer can go and place an order to create an order but the development team realizes because of these bounded contexts in microservices that order placement service is going to have to go make a call over to the inventory service retrieve the inventory and send that inventory back to that order placement service development team looks at this and they're sharp by the way and sayou
• 07:00 - 07:30 know this is way too slow and it's coupling these Services together um this is a problem I know to better decouple these Services what we can do is put an inmemory replicated cache in inventory and then have a corresponding read only replica in our order placement and the team says and we'll use Hazel cast to
• 07:30 - 08:00 always keep these in sync so that when we do have an update to inventory now the cash gets updated in inventory hazelcast synchronizes it wow this is cool this is a smart choice because it is a lot faster we increase our responsiveness and we've decoupled our services devel development team give each other a high five and go ahead and
• 08:00 - 08:30 implement this solution after production release what happens well it works fine until we start to scale and we realize that that inmemory cache in each instance is 500 megabytes of items and their inventory and as we start to scale 2,000 3,000 users 10,000 users we can
• 08:30 - 09:00 start to see we will never ever reach close to half a million users yet again another epic failure there we go yes what happened these were two really good choices between the architect choosing the appropriate architecture and the
• 09:00 - 09:30 development teams realizing inefficiencies what happened was a misalignment where the architecture was focused on scalability and elasticity but implementation placed more of a focus on performance and decoupling thereby misaligning the architecture and those quote are you ready implementation details yeah right so this is the concern with operational
• 09:30 - 10:00 characteristics and operational alignment but there's two other kinds of alignment we have let's put a stop sign on the operational and open the road and take a journey through structural alignment let's take a look for example at a typical house or a flat or apartment
• 10:00 - 10:30 it consists of rooms as a matter of fact we can say that that that house is made up of rooms those rooms each serve a different purpose we have a kitchen different kinds of bedrooms we have a office a bathroom all these kind of hallway stairs so you can kind of think of these rooms as the building blocks of that house well by the same token logical components things that a system
• 10:30 - 11:00 does become the building blocks of our systems portions of the system things that that system has tasks for has to do and as a matter of fact those building blocks all form together just like that floor plan for the application or maybe it's services that they combine into either way logical components are
• 11:00 - 11:30 the building blocks of any software solution this is what I mean by structure by the internal architecture of a particular monolithic application or even a service so let's take a look a little bit at this structure piece and this is called a logical architecture and as a matter of fact we couple or combine some of these compon on together
• 11:30 - 12:00 into domains we could actually see the architecture we realize that logical architecture through the way we structure our code so these logical components the building box they're just not boxes on a page no they're actually manifested through the directory structure or namespace of our systems and so for example the higher level
• 12:00 - 12:30 nodes represent the domains and subdomains of our system and then the lower level nodes represent those Architectural Components those building blocks of our system so let me show you an example let's take payment processing for example well I need to write a class so I will write a class and notice it's getting placed right in that payment directory called credit card. Java and
• 12:30 - 13:00 this charge is a credit card when we write software when we write class files we physically have to put them somewhere so this one goes inside the payment directory or payment namespace why well Market has to do with Payment Processing ah but remember a logical component in an architecture is manifested or realized through the name space or package
• 13:00 - 13:30 structure or directory which means that that class file is one of the many classes that implements the payment logical architecture component so that's our definition now let's see how disastrous this could get so here's our scenario in this case um company needs a new system system for their customers to
• 13:30 - 14:00 be able to enter trouble tickets into the system for products that they buy from our company if they have a problem with it for installation or the thing just breaks uh they can enter a trouble ticket and our field experts will come to your home or office and fix your problem well as an architect this is The Logical architecture now this is void of any databases or services this is The Logical architecture how the system will be
• 14:00 - 14:30 constructed and you'll notice there's things like ticket creation assigning a ticket ticket assignment ticket routing to Route it to the field expert uh there's customer profile registration uh surveys to send and receive them um all of these are the building blocks of that system The Logical architecture of a system shows how that system will work and how it's coupled the dependent between these pieces of
• 14:30 - 15:00 functionality okay so an architect spends a lot of time drawing lines and boxes and realizing um how is this going to work now we go to development so the developers code this up by the way good news 100% code coverage absolutely everything works and this is is what the development team
• 15:00 - 15:30 came up with do we remember the logical architecture of any system can be realized through the way the source code is organized well here's my logical architecture but but where is ticket creation I I can't find it in the source code um how about things like for
• 15:30 - 16:00 example the customer registration or or even the customer profile I don't see it there and this ticket State that's not even in my architecture well all that work that I did to draw and realize a logical architecture a structure of the system is not there this is what that logical architecture looks like and as a matter of fact we can
• 16:00 - 16:30 compare these two because the structure the architecture of a system allows us to have better understanding of how it works learnability maintainability the ease of testing of our system the risk of deployment in our system how easy is it to change to understand the system extend the system adopt it to New functionality which of these looks a little closer to all of those
• 16:30 - 17:00 goals the original one but of course even though all the functional tests pass this system is not maintainable not reliable not testable no one understands it it's just a bunch of lines yeah so here we see another type of alignment between architecture and implementation the fact that the logical architecture
• 17:00 - 17:30 and the way the C was structured didn't match okay there's one more road to go through and that is the constraints road so let's move that stop sign over to the structural and go down this road of constraints yet another type of alignment between architecture and implementation when we talk about constraints let me
• 17:30 - 18:00 show you an example here's another business case we have a very tight time frame and a very tight budget for this new project no one's ever heard that before however we also expect a lot of continuous change of the data structures in this system we anticipate it we know what going to happen we don't have a good understanding of this particular domain
• 18:00 - 18:30 and when we make those database changes we have to move and make those as fast as possible there's our problem domain so the architect goes back to those star rating charts and says I wonder what architecture would satisfy that kind of shape of a problem and so key point is tight time frame and tight budget lend itself lend
• 18:30 - 19:00 itself towards cost and simplicity now here this might look confusing um because a lot of stars mean really good the fewer Stars means really bad so cost here is five stars that does not mean it's expensive that means it's really good and we can see a lot of choices here the traditional end tiered layered architecture hm that might be a possibility modular monolith oo that's popular maybe we should use that micr
• 19:00 - 19:30 kernel architecture otherwise known as the plug-in oo maybe I should put that in my wish list but also there's service-based architecture not as many stars but has some H wait a minute do you remember our problem we're anticipating and will experience a lot of changes to the
• 19:30 - 20:00 structure of that data that's changes not to a domain that's changes to a technical layer in the architecture architectures are partitioned either technically or by domain partitioning but if we have a lot of changes to our data wouldn't it make sense to have a technically partitioned architecture and as a matter of fact it
• 20:00 - 20:30 would one star for domain means it's Technical and so that kind of says well I think the layered architecture is the way to go and as a matter of fact it would be the right choice for this kind of problem I mean think about it we've got a separation of concerns technically and also layers of isolation those two things combined in a layered architecture give us great Change Control because done correctly those constant
• 20:30 - 21:00 changes to the database means I'm only changing one layer in that architecture all the other ones are good interesting the layered architecture which we've been doing for 70 decades is not dead no this is a viable option as a matter of fact it's a really good architecture for this particular domain proc problem however to make this work what
• 21:00 - 21:30 do I need to do I need to apply constraints our first constraint um presentation business and services yeah you can't talk directly to the database you have to kind of go through all those layers that's our first constraint second constraint um you have to respect the open and closed layers now a closed layer means ah I got to go right through that an open one
• 21:30 - 22:00 means I can bypass it and the third constraint is this all databased logic must exist in the persistence layer three constraints you know I would hire this architect I would work beside this architect because this will work let's take take a look at the quote
• 22:00 - 22:30 implementation detail because the presentation developers realize that this is nonsense a lot of our queries just need simple data I have to go through every one of these closed layers this is silly um one of the members on this team realized that there's a pattern called the fast lane reader pattern we can shortcut those layers and go to the database directly therefore significantly in increasing the
• 22:30 - 23:00 performance and responsiveness of our system yeah cool stuff let's do it the backend developers get really frustrated about the fact that all the databased logic is moved from the business logic I mean one of the trends that we have in this industry is of course to try to bring data closer to the processing not further away and this is making it a real hassle to maintain
• 23:00 - 23:30 anything it's taking too long so the backend developers realize you know it just makes a lot more sense and it is a trend to keep that database logic close to me so I could see everything at once much better maintainability so they implement it that way and of course let's do our production release boy don't you hate releasing software
• 23:30 - 24:00 better get ready because you know what's going to happen all of a sudden what well that database change sure enough comes about all the time but because the constraints weren't followed I have to change every single layer in this architecture and yeah you know what happens yeah disaster yes database changes take way
• 24:00 - 24:30 too long that was our primary goal so what happened here in this scenario scenario was the architecture very sound focused on isolation of technical layers agility that ability to respond quickly to change where as the implementation of this architecture Place more focus on maintenance and performance again misaligned with the
• 24:30 - 25:00 architecture wow a lot of fires in this uh talk isn't [Laughter] it all right well now we see the problem there are three types of alignment that we continuously get misaligned so how do we solve this problem what one way to do it is through
• 25:00 - 25:30 governance governance or compliance done through architectural Fitness functions a fitness function in architecture is a test it's something we write or metrics We Gather that tests some sort of architectural characteristic objectively meaning through metrics these are tests that we can run to govern all three of these problems operational structural and
• 25:30 - 26:00 constraints well let's take a look at how to apply governance Fitness functions to our problem let's start with operational where we started before we have a lot of tools and metrics or tools I should say that generate all sorts of metrics for us that we can start tracking and gathering for things like scalability responsiveness elasticity reliability
• 26:00 - 26:30 error rates we can leverage these tools or sometimes we write them ourselves in production and let me give you an example here's a website a service a system a product and what that does is it streams it makes observable some sort of metric let's say response times and user load that we stream to let's say Kafka or a q we then write a capture service which then receives all that raw data and maybe does some filtering on it because we don't need every data point
• 26:30 - 27:00 usually then the fun part comes because then we write an analytics service this is the fitness function that basically reads that data and starts tracking things over time uh looks for Trends looks for thresholds and when a threshold is reached or a trend is noticed alert me otherwise just leave me alone and this just continuously runs in production yeah here's a good example we needed high
• 27:00 - 27:30 levels of scalability so we measure our user load against response time and notice our response time starting to vary a bit but we have a consistent increase in the number of users but look at our response time this is what that analytic service does that Fitness function does it it calculates either the slope for example or maybe a standard deviation from a
• 27:30 - 28:00 variance of a mean and we can see that this is overall pretty flat yeah this test demonstrates a scalable system or it would demonstrate that it isn't scalable so these Fitness functions are really useful for for these kind of operational concerns and isn't it interesting most of you have probably heard of Fitness function I'm hoping a lot of you use Fitness functions we tend
• 28:00 - 28:30 to think of these kind of tests only for operational stuff but they can also be used not only to align operational characteristics and architecture with implementation but also for other aspects for example let's take a look again at our structural alignment or the problems we had with that that what we can do to leverage these are free tools
• 28:30 - 29:00 that are available in Java Arc unit uh in net um Arc unit net net Arc test uh sonar graph for python C++ Java c um py Arc test for python these are all tools that are available to you here that you could actually write tests to govern the structure of our system that logical
• 29:00 - 29:30 architecture let me give you a very simple example we want to have that directory structure represent our logical architecture but what's to stop a developer from naming it anything they wanted to or creating more and more and more domains this tests stops them because this will fail if that directory structure becomes misaligned with our iCal architecture are components classes should reside in
• 29:30 - 30:00 a package A B C or D and we can continue to write these tests to basically codify our logical architecture that's really cool and of course we can plug this into nunit junit um any kind of testing framework or even just our pipeline neat and this is one way of assuring this alignment between our
• 30:00 - 30:30 logical architecture and the way our code is actually structured okay well there was a third wasn't there that was constraints let's take a look at constraints because we can use these same tools that I just showed you to also govern constraints we have so presentation layer can't talk to the database can't talk to persistence you
• 30:30 - 31:00 have to go through all of the layers they're closed layers okay that's a constraint but no one's going to follow that no one cares so how do we write a test for it well in our unit it's actually pretty simple no classes that reside in a package presentation or persistence or in this case presentation should access classes that reside in a package or space persistence
• 31:00 - 31:30 check yeah these are really cool tools the same thing in C for example um types in the current domain that reside in a particular name space should not have a dependency on these now Neil Ford and I have been experimenting we we we we use these all the time and past couple of months ago we were musing hey I wonder how uh generative AI would work for generating
• 31:30 - 32:00 these kind of tests if we can describe our constraint describe our architecture uh describe what we need um Can it generate Arc unit code net Arc test code well the good news is yeah it actually did a really good job at generating this stuff yeah which now okay I'm sorry you just simply don't have an excuse now to do this I don't
• 32:00 - 32:30 have time it's a [Laughter] prompt all right so this is yet another way of aligning constraints another alignment between architecture and quote that implementation detail H that stuff works governance is really good I mean this going to keep things
• 32:30 - 33:00 aligned but there's a problem there's a big problem because the only thing governance shows us is that we have a problem we're continually slapping developers hands saying don't do that don't do this don't do this yeah governance is good I would urge you to use these tools use Fitness functions any of these tools to govern but it's not going to solve the problem of
• 33:00 - 33:30 alignment because the root problem is all about communication and collaboration let's face it this is tough developing software is hard because we do have software architecture way over here and we do have implementation way over there and the problem is these are two
• 33:30 - 34:00 separate things I mean a software architect has specific roles on any product the first is to understand what are those architectural characteristics that are critical or important to us what kind of architecture style matches those and the shape of our problem and designing the internal structure those logical components of the system that's what an architect
• 34:00 - 34:30 does and then those artifacts get sent over to implementation what do developers do well they take those components like payment or order placement and now they figure out what classes should I do that's design um class diagrams figuring out inheritance composition structures and what patterns to use also maybe it's UI design and of course
• 34:30 - 35:00 coding well this picture right here shows you exactly why we continually get out of alignment with architecture and implementation why things will never work and it's because of this single unidirectional line right here everyone there's really not a Gray Line
• 35:00 - 35:30 a gray area between architecture and design or architecture and implementation no we can get rid of that Gray Line because you know what it is it's a Chasm that separates these two camps and as a matter of fact most of the decisions an architect makes go straight into this Canyon right here developers never ever see that what do development teams do when they
• 35:30 - 36:00 Implement our architecture what they do is they actually validate our assertions and assumptions about the problem about the architecture oh yeah and those are always correct yeah so changes need to be made to the overall architecture and design development teams do that and those changes go straight into that Chasm never reaching the poor hapless architect who thinks that their
• 36:00 - 36:30 Solutions are perfect everywhere wow no one says anything about it it must be great oi listen to get architecture to work to realign architecture and implementation that requires us to fill in this Chasm and form a bidirectional relationship between architecture and also implement ation where the Architects are on the same virtual
• 36:30 - 37:00 team allowing for very effective communication of changes and the architecture itself to the development team and when not if we're wrong as the architect those changes effectively get back to me so that I can change the architecture and get those changes effectively back to the development team and as a matter of fact this is one of the only ways I've found everyone to facilitate those soft skills of mentoring coaching and
• 37:00 - 37:30 Leadership that an architect is supposed to do with development teams H so how do we do this I mean we're told yeah we should communicate and collaborate we're always told that but we're never told how we should do it let me show you how so there's two golden rules of
• 37:30 - 38:00 collaboration between Architects and development teams engagement models here's the first one if developers don't know why you made a decision they're less likely to agree with it number two if developers aren't involved in the architectural decisions they're less likely to follow it oh they might agree oh I agree with you but we're not going to do that we're going
• 38:00 - 38:30 to do our own thing yeah well let's take a look at these two golden rules of collaboration and how to solve these issues or address these issues let's start with the first one gold in rule number one if developers don't know why you made a decision they're less likely to agree with it this leads to what Neil and I coined in our fundamentals book the second law of software architecture why is more important than
• 38:30 - 39:00 how oh I could look at an architecture diagram and I could see how the system works but what I don't know is why you chose to do it that way yes so one of the ways to solve this problem architecture decision records to the rescue adrs now I want to pause right here because it used to be back in around 2018
• 39:00 - 39:30 2019 uh the the the prepandemic days uh we used to have a drinking game at conferences and it was called the conways law drinking game uh anytime anybody up on stage said the words Conway's law you had to take a drink you wondered why all the speakers were stumbling around on stage yeah because it was mentioned about every five minutes well now enter 2023 2024 that drinking
• 39:30 - 40:00 game has changed anytime a speaker mentions ADR you got to take a drink yeah and we still have a bunch of drunk people in the conference but here's the thing a lot of you may have heard of architecture decision records maybe using them but most of us think of those as grown yet another form of documentation nope I'm going to show you how to
• 40:00 - 40:30 leverage an ADR as a tool for engagement as a tool for collaboration not documentation so when we make an architecture decision we fill out an architecture decision record each decision has its own I put the title the status whether it's proposed or accepted maybe it's superseded by another one uh a short paragraph a couple of sentences about the context what is it I'm having
• 40:30 - 41:00 to make a decision on the decision itself with justifications and the consequences of that decision the impact this is not documentation this is a tool we could all use because we could leverage two sections here first the decision section I have to provide a justification for for my decision and also the
• 41:00 - 41:30 consequences I can now describe the trade-off analysis and the impact and the consequences of this decision this is a fantastic vehicle between Architects and developers to solve this why problem so this is a this just leveraging them by the way you're like ah wow what a great idea Mark but our company doesn't use adrs well neither does ours we still use them you don't have to embrace the whole
• 41:30 - 42:00 infrastructure of an architecture decision record I call these temporal architecture decision records in other words we're not going to use them for documentation no I'm using these as a vehicle so that developers understand why I'm making certain choices okay let's take a look at that second Golden Rule here if developers aren't involved in a decision they're less likely to
• 42:00 - 42:30 follow it here's the problem let's read this so the architect says this we're going to use request reply messaging between our services because it's faster and it's uh it's more scalable than rest okay right away we see a couple of problems with this statement oh the good thing the good thing is that I did justify it we're using it because it's faster and more scalable than rest but
• 42:30 - 43:00 this is not collaboration this is communication I'm telling the development team this and what do you suppose a likely response would be yeah actually we're going to use rest we checked with chat g chat GPT and it says it's actually faster and more scalable so but but but but but wait a minute says the architect I'm the architect this is my decision and in our environment is faster yeah what whatever whatever
• 43:00 - 43:30 hey wow what do we do now yeah talk about losing control of the team the root cause of these kind of real world scenarios is actually a matter of lack of trust and respect if we had another 45 minutes we would launch into that topic oh but we only have a couple of minutes left so how do we address this problem well let's address
• 43:30 - 44:00 it the answer is right here DDD ah but not domain driven design no that will not solve this problem what will is DDD remember those three letters demonstration defeats discussion DD D we could talk all day
• 44:00 - 44:30 and argue all day about something and not get anywhere if I can demonstrate for you with metrics actual results it usually stifles the argument and stops the discussion let's go back to that really bad scenario and look how to repair it so the architect says this hey I ran some benchmarks in our production environment against rest and messaging and take a look at this this is really
• 44:30 - 45:00 interesting so in our environment response times go north and we've got of course user load and watch this when I ran these benchmarks in production check it out chat PT close to right I mean yeah it was just as scalable just as responsive but look what happens because this is where our expected user load is and this is our response time service level
• 45:00 - 45:30 agreement and you can see messaging is well within this range but at these levels in our environment rest is Not So based on this says the architect I'm thinking we should probably use request reply messaging between the services are you ready what do you think that's collaboration I'm not telling you so based on this we're going to use this I think we should use this what do you you think and now the response is wow well you know we were
• 45:30 - 46:00 going to use rest but wow based on this yeah well you're right I'm glad glad you did this we'll definitely use messaging and there's one last Technique we can use to involve developers with our architecture and architecture decisions you know what that is architecture decision records again to the rescue a vehicle for engagement with the development team so
• 46:00 - 46:30 we can look at the status right here proposed accepted superseded let's add another one and that status is request for comment by a certain date RFC status this I'm opening up to say development teams um pick it apart uh what's your opinions uh what's your criticism about it and this allows developers to look at the decision before I make it and say
• 46:30 - 47:00 yeah this this is this is bad yeah no I don't like this oh yeah this is spot on so on and so forth this is a win-win situation you you can't lose by doing this I win as an architect because developers feel involved in the decisions it's not just me I win as an architect because now there might be a comment in there of something I missed I might have a
• 47:00 - 47:30 comment about the fact you can't do that there's a firewall between these oh right and therefore together we're making the right decision these are all kind of techniques that we can use to basically realign architecture with implementation so let me leave you all with this this is one of my fav quotes from our book The fundamentals of
• 47:30 - 48:00 software architecture and it goes as follows developers should never take the components designed by Architects as the last word rather it should be viewed as a first draft where implementation will reveal more details and refinements my favorite quote in our book
• 48:00 - 48:30 collaboration constant iterative architecture working together with architecture and implementation to solve that business problem ladies and gentlemen it is not an implementation detail awesome thank you all so much thank you all
• 48:30 - 49:00 right I I do believe we have some time for uh a couple of questions if there are any from uh from the crowd we do we do raise your hands oh the Wonder ball goes round and round I like that thing hello yeah perfect um amazing presentation by the way um one question actually is um I've been hearing quite a lot like in the like common point of
• 49:00 - 49:30 like uh talk is like between how do you like communicate stuff between Architects and the D teams and that was a central point in your end of presentation and then I propose a question why do we still keep Architects separated from developers in general why not empowering the development teams to take architectural decisions yes so fantastic question about this separation that we still continue you have and development teams being able to empower
• 49:30 - 50:00 them to make their own decisions be more aware of architecture um one of the things that I evangelize perhaps the most in Consulting gigs and trainings and conferences master classes is this notion of what's called architectural thinking and this notion is about how do you actually think like an architect this concept empowers development teams
• 50:00 - 50:30 to be more aware of architecture and so by doing this kind of architectural thinking um we put less stress and less need on an architect and we get much more effective uh and efficient software uh for example uh things such as knowing what are the architectural characteristics those nfrs or non-functional requirements that we need and constantly thinking about those as
• 50:30 - 51:00 we're developing software that keeps that alignment going and I don't have to be the architect to say that um things about trade-off analysis understanding that how I make a decision is usually based on those architectural characteristics scalability responsiveness agility whatever they happen to be um and also the third thing is increasing our technical breadth of of knowledge uh the amount of things I know less about but more of and it's
• 51:00 - 51:30 that middle part of our knowledge triangle things we know we don't know uh those three techniques are one way of starting to really Empower development teams uh to start thinking architecturally putting themselves in the brain of an architect when trying to solve problems so yeah yeah uh this is one of the things that I am evangelizing and hopefully before I uh passed from this world into another one um uh more
• 51:30 - 52:00 development teams will be embracing architectural Concepts do we have more questions one more question there's a handun going up in the back I some help oh boy here we go I feel I feel like I'm at the ball game again all right uh thanks so very much for the talk um it was interesting to you talk about architecture decision records because whether or not we take a drink I
• 52:00 - 52:30 feel like a lot of the time there's a brief burst of enthusiasm but the result is a lot of folders with exactly one architecture decision record in them because you don't get the Buy in and therefore it doesn't people don't realize the value so I wonder if you've got any kind of pointers on how to make it more of an ongoing process for communication rather than like an occasional we must do this and then it gets forgotten after a week sure absolutely because um I happen to be as
• 52:30 - 53:00 you probably guess a big fan of adrs I find them extremely effective however uh most companies don't embrace them uh two reasons one a lot of times to your point it is all or nothing you have adrs that describe your architecture decisions and reasons why you did something or you have documents but but if you start blending them now I've got two places to go to figure out the architecture and so
• 53:00 - 53:30 it's that full immersion of them that usually leads most companies to say yeah not yet so what I like to do um to really demonstrate the effectiveness and power of architecture decision records are the same kind of techniques I just showed you here um use these as a communication and collaboration vehicle and Tool uh between Architects and developers what we saw here but also
• 53:30 - 54:00 engagement models between Architects and also the product team product teams making certain decisions we don't understand we make decisions the product team doesn't understand and using this as a vehicle allows us both to come together in a single document artifact to be able to understand each other and to be able to also validate those decisions so by doing this temporal by
• 54:00 - 54:30 the way temporal meaning they're just temporary trying this out creates an awareness of the value of these adrs and hopefully by demonstrating that value again remember DDD demonstration defeats discussion Europe DDD Europe there we go um but by demonstrating that value and other people realizing it um might cause other teams to say you know for this new product why don't we try
• 54:30 - 55:00 adrs um maybe it's for major decisions first not every decision um organizing architecture decision records is a big Challenge and usually the response is well just store them in a get repo along with the code but the problem is who has access to your source code repo the developers but hopefully no one else so I do like storing them and get but I usually have a separate repo for these my preference is in a Wiki or some
• 55:00 - 55:30 kind of live document but um but it's really practicing them um it is not easy because you're not sure what scope you should make an ADR I'm making a decision does that really require an ADR this morning NE Neil showed you a tool you all have now for deciding whether something's more architecture or more design and he showed showed you three criteria is it strategic in nature or not what's the
• 55:30 - 56:00 level of effort uh what are the significant trade-offs things that are in that a range that he showed you write an architecture decision record for ignore things and the C and D range of that spectrum and these are some of the guidelines and ways of trying it out it's not for everybody but I find them extremely effective so all right fantastic one more hand up and I think we have time did you have your hand up yes can you pass the cube
• 56:00 - 56:30 to the front Okay one more question here woo oh wow one true nice draft pick right there draft pick number one yes hey you're on my team yeah my my question's not going to top that um so yeah I wanted to ask um with introducing adrs in this format and introducing them as a as a dialogue um would you have any suggestions of like would you follow the same pattern which is demonstrated
• 56:30 - 57:00 before advocating for the like an ADR as we're going to do the ADR pattern that becomes like the pipeline dictatorial or do you kind of use the same technique to go hey let's let's talk about this and then afterwards you tell them what that was sure um well do you remember the two things an architect always says it's an implementation detail and it depends there you go it depends um sure if I've got a fairly significant decision to make um I I likely would first of all
• 57:00 - 57:30 let me back up I would use the same format it's a good format it's pretty solid it has everything we need to communicate and collaborate and use it as a vehicle to go back and forth so in fact I would use that kind of format um however regarding the demonstration piece if it's a significant architecture decision that bears significant tradeoffs then I would probably if possible model it uh use qualitative analysis to demonstrate where I came up with something these are things we can
• 57:30 - 58:00 do within the decision section to justify the answers um with diagrams pull up the star rating chart say because this has five stars and that has one we chose this yeah okay I'm not going to argue with that and thank you for letting me know so yeah um uh the more significant a decision uh the more I would try to demonstrate that value before uh approaching it yeah exactly so wonderful hey thank you all so much this
• 58:00 - 58:30 fantastic crowd and uh thank you all all right I'm happy you didn't actually burn the stage down that's true [Music]