So, one of my favorite writers and thought leaders in the industry, Mark Schwarz, who is an enterprise strategist here at ALS, in his book, he actually says that it is time for the wall between IT and business to come down. He says that old business models long ago pitted IT people against business. So he calls it "pitting the nerds against the suits." And he says that we need to start to build an environment where there can be collaboration between the two.
But now we say, how are we going to make sure we have this collaboration when we don't even speak the same language? How are we going to collaborate when tech has terminology that business doesn't even understand? And then we have it the other way around as well. Business has terminology that we don't understand as tech people.
So in this talk, we're going to do exactly what we said in the title - that we're going to start to decode this business language, this business speak, decode that. And so we're gonna look at practices that we can actually employ so that we can do that. And then we're gonna look at how we can take all of that that we got and align it to the AWS Well Architected Framework. We've all seen it.
There's a misunderstood requirement - it starts out during a conversation, makes its way to documentation, however we document requirements, and ultimately ends up in production. So you can end up with a situation like this where you've got someone from your business, the example I've got here is maybe a bio scientist, but this could be a banker, this could be anybody who is your business user. They made a remark, maybe in a meeting, maybe during requirements elicitation, they made a remark. And the business analyst, through no fault of their own, because there are so many factors that are at play when we are actually trying to build a solution together with business - so they misunderstand a remark and they take what they thought to understand and they have it. And then they go and they include this in requirements documentation.
This misunderstood requirement makes its way to the documents that your development team gets and they take this and they build that into production, all from a misunderstood requirement. Misunderstood requirements can be expensive. They actually are expensive. What we can end up with, we can end up building the wrong product, we can end up wasting time and money. There could be safety issues, something that's not safe for your customers ends up being built into production. There could be delays with delivery and we can end up with unexpected unmet expectations which result in loss of trust from your customers. And that is not what you want.
So we are talking to architects and I won't even go and talk about what the role of an architect is. I know during my time when I was a solutions architect, it was always back and forth trying to define what the role is. And it's not possible to actually define the role. I'm sure all the architects in the room will say no way you can't really give me the bullet points to tell me what my role is.
So what we actually wanna focus on then today is just based on this book that I have here and you can go and check out this book. It is an awesome book by these two authors who I've now started to follow on Twitter because I think they're just awesome. In this book, The Fundamentals of Software Architecture, an engineering approach, what these authors actually try to do, because we can't say what the role of an architect is, they're focusing on the eight core expectations of you as an architect - just the core expectations.
So if you are an architect, what is expected of you? It is expected that you are able to understand and navigate politics, that you have interpersonal skills. I'm sure you in the room say that's not just an architect, every human should have interpersonal skills. That you've got domain experience, that you've got a fair amount of exposure and experience to have a vast range of technologies and applications, that you are able to build solutions that comply to regulations and requirements, that you are able to keep up with the latest trends, that you can analyze architecture.
This book that we've got up here, we're actually gonna be referencing it quite a lot through the other talk. So just remember that as well. And then there's decision making that's also expected, that you are actually able to do this.
So what tends to happen when you get requirements from the customer, the functional requirements, and these are the business logic of the application, they tend to be quite explicit because this is what your customer, they want the application to do and those are obvious for them and they tend to be quite explicit on there. But you find that you've got the requirements or the characteristics that are not the business logic, but they are what makes the application as a whole successful and those tend to not be explicit.
So there actually is this ISO standard that actually will give you a much more extensive list than the one that we have here. The six that we've listed are actually your most common ones. You will find that these architecture characteristics are not very explicit when you get the requirements from your customers. And the ones that we've highlighted - your auditability, how often do you get a requirement from your customer and it's there and it's very clear that they want the application to be auditable? How often is it that you will see about security, about availability, performance, and all of those ones that we have? Like I just said, we've just got the six that tend to be most common. But if you consult that ISO, you will find a more extensive list of what the architecture characteristics are.
And now we're starting to talk about what we actually are here to discuss today - the architecture characteristics that you are not really getting from business, but you wanna have these because ultimately you want to build a well-architected application that has these characteristics because these are important for the success of the application.
So what also is very interesting as we were going through and looking at these characteristics, there is very close alignment to the six pillars of the AWS Well Architected Framework. And this is where we now tie together these characteristics and the AWS Well Architected Framework, which of course you will hear about a little bit more, a little bit later. You'll hear more from Jason about how we're actually starting to tie these two together.
Talking about architecture characteristics, I mentioned before that the functional requirements are quite explicit. Those usually won't have an issue there. And then these architecture characteristics which are what makes the system successful as a whole, you will have some which are explicit there, but you get those that are definitely not there.
What tends to be explicit sometimes are the ones that we have here. Like your customer will say "I wanna make sure that there's user satisfaction." But even that is not very clear - what does that mean? So we're now starting to do the decoding. Usually when they say user satisfaction, they meaning that this application should be usable. Performance - it's aligning to performance when you're talking about time to market, it's talking about agility and deployability of the application. That's what you as an architect would have to make sure that you built into the application so that you meet that for your customer.
And now we're starting to move into what I found also a very interesting part again, keeping up with decoding what you're hearing from your customer so that you can start to design well-architected applications.
This is a very interesting reference from Ted Neward. He said that architects need to practice being architects, it's only fair, right? Just as developers need a chance to practice being developers. So in the previous slide, we talked about translating domain concerns to architecture characteristics. We were already starting to look at some that you might find in how to translate these. But now how do we do this translation?
I've just done the quote from Ted Neward here. He talks about architecture katas. He actually came up with architecture katas because this is actually the practice that he actually came up with. And this is what he actually references as providing that platform for architects to practice so that they can actually get better at what they do. And this is actually inspired by code katas - you might be more familiar with those, those are more familiar. And a kata is actually a practice that comes from martial arts, karate, it is about doing the same form over and over again until you're actually good at it. And that's the inspiration for it.
And I did try to get Jason to wear karate suits to come and do this, to make sense, but he didn't want to do that. So the idea with both the code kata and the architecture kata is to create a safe environment for the architect or coder with a code kata, architect with an architecture kata, to practice and fail over and over and to iterate. We're gonna see when we talk later on iteration is very much a part of the entire practice. So providing a space for you to iterate with your customer and with architecture katas, the original idea of them is that you're not perfect the first time, it's again to provide that space for that iteration.
So now what do architecture katas have to do with what we're talking about today? It does say that the whole practice is to provide you with an environment or a guideline to iterate until you actually get better. So what we actually gonna talk about today is how we can take architecture katas and actually bring that practice to how we as architects talk to our customers until we can actually get to those architecture characteristics that are not clear to them.
The architecture kata has four phases that we can actually employ when we actually talk and iterate with our customer. So the architecture kata has four phases that we can actually employ - there's a preparation phase, there's a discussion phase, a peer review, and then there's a voting phase, which is when we actually select the architecture design that we're gonna move forward with.
Now we're just gonna dip dive deep into each of these to just understand how they work. So the preparation phase of the architecture kata is when the team is actually built. So this is where, facilitated by your customer who becomes a moderator throughout the entire practice, you start to build a team. So a team could be made up of the customer, who's definitely always there, you as the architect, your developers are also there because you are all going to collaborate together to build, to design the solution, and you're going to collaborate together to select the architecture characteristics that are priority for your business. So the first phase is preparation, where you assemble your project team.
The next phase is the discussion. Now you've got your team, you've received the requirements, and you are not able to work out from the requirements what the characteristics are and you are not able to work out from the requirements what the priorities of the requirements are. So now you start the discussion, you are the architect, you are leading the discussion, and during this phase, the customer who is the moderator is there. Now you get to iterate and ask them questions at this point.
We are not focusing so much on the technology. So we're not going to obsess over what technology we're going to use. And there could be assumptions that you might make here but any assumptions that we make as far as technology is concerned, we are not going to fixate on them so much because that is not the priority at this point.
So this is the discussion phase of the architecture kata if you were to follow that practice to get to the characteristics.
The next phase would be the peer review. So during the discussion phase, you've come up with a rough vision of what this architecture is going to be. Now, you as an architect, you then start to present it to the project team, everyone who's assembled, and now you start to receive questions from them. And this is where the iteration really starts to happen and you go back and forth and you discuss and you go back to your customer where there's anything that you're not understanding to make sure that you've got that clarity.
And at this point is where out of the characteristics that you got, you start to prioritize what we're actually going to move forward with to the customer. At the end, you might have had a couple of architecture designs that you came up with. Now you will vote or select the one that you actually gonna move forward with.
So that would be the practice that you actually use to get to what the customer actually wants. So now we're going to start to look at a couple of examples, see what the requirements outline tends to look like, and what characteristics can you make out as you look at what we're going to look at here?
I shared a link a couple of slides back where we had the architecture kata that will take you to that website. And in there you can actually go and look at example requirement outlines and these, you can just use those to just get going if you've never really seen an outline before and see what those look like.
But this is a typical structure of a requirement that you get from a customer. And you can spot some characteristics with me here if you want to as well. So this is typically what you would get.
So this is an example of a local copy shop chain. This is a description of what you just got from them. They're saying that a local copy shop chain wants to offer its customers an all-in-one computing experience. It wants to provide document creation, editing, storage, and printing.
The requirements are:
- A browser-based system that must provide for word processing presentations
- There must be document templates that are available as a starting point for the customer
- There must be versioning, print scheduling, automatic and manual payments
And then it says in terms of how many users this application is gonna expect - it says initially thousands in the local city but potentially millions if the demand grows.
Nothing in here says we want a scalable system, but you can see some of the characteristics you can kind of make out when I look at this, I can make out a system availability, I can make out security, I can make out performance. But you probably are, you could spot different ones that I'm not spotting here. This is just an example that we're just working through to see what this looks like.
Got a second example for you and this one is gonna have a diagram at the end that we're also gonna work through. So now you've got an auction company and the auction company wants to take their auctions online to a nationwide scale. Customers choose the auction to participate in. They wait until the auction begins, then they bid as if they were in the room with the auctioneer.
So that's the requirement that you've received and requirements are:
- Auctions must be categorized and they must be discoverable
- Auctions must be as real time as possible
- There must be video streaming of the auction after the fact
And in terms of users, the system must be able to handle - in terms of what, how many users the system must be able to handle - it must be able to scale up to hundreds of participants per auction, potentially up to thousands of participants and as many simultaneous auctions as possible.
And what architecture characteristics can you even make out out of this? I can pick up scalability as well. There are a few others that you probably are spotting that I'm not even spotting. So this is what you get and this is typically what it looks like.
How out of this do you go and design a system that is successful, that does not fail over, that can handle the number of customers? And this is why the iteration then has to happen until you can actually work out what really you must build into the system as the architect, as you design the application.
So this one has got a component diagram that we're just gonna work through. So from what we read before, you're gonna have a bidder - they must be able to view live video streams, they must be able to view a live bid as well. They must be able to place a bid. Then you've got an auctioneer who must be able to enter a live bid into a stream. They must be able to receive online bids.
Mark item is sold and then you've got your application which must start the auction after all of that has happened and they must be able to handle payments and then they must be able to track the bidder activity. As you can see here. There is still a lot that is not very clear. So there still has to be a lot of iteration that actually takes place before we can arrive at what we're going to design as an architect ultimately. And what's going to actually go into production.
I talked before about the architecture characteristics and that out of everything that you're actually getting, you will need to prioritize what's actually important for the customer. So as you iterate through your kata, you will arrive at what's actually the priority because you can't always build everything all at once. And for the purposes of this talk today and what you're gonna hear from Jason later on, we're going to focus on three of these um of these architecture characteristics. We're gonna focus on availability and then we will focus on scalability and we will focus on security and if you bear with us, you're going to see exactly why.
And now I'm gonna hand over to Jason Nicholls.
Thank you, Veliswa Booya. So Vista found some characteristics through the iteration process of the architectural carter. And the thing about those characteristics is you should use them to define an architecture. And what we can then do is use the well architected framework to ensure that that architecture actually aligns with the characteristics that you found through the architectural carter.
So before I continue, um sorry, there we go. I'd like to know if anybody here is a solutions architect or developers. There's a few. Ok. That's good. And how many have you used the AWS well architected framework before? That's cool. I like the tool. It's, it's great and that's what we're gonna cover today.
So for those of you who don't know what the AWS well architecture framework is, it's a um it's, it's a framework that allows cloud architects to build scalable, secure, highly performant resilient and efficient workloads for the cloud. Um it's a consistent approach that comprises if you like key concepts and patterns that you can use to build these architectures, right? And the way it works is we ask some key fundamental questions that you can then check if your architecture does actually adhere to that principle. And we actually, if you follow the process, i really like it.
So if you go to the tool itself, there's some videos that you can see, there's, you know, in depth guidance that you can follow and it shows you the pros and cons of those decisions that you've actually taken. Um and we actually believe that if you follow this process, you can build highly secure, reliable resilient applications and that should lead to business success.
So if you look at the well architected framework, it comprises of six pillars. So the first one is operational excellence that's followed by security, reliability, um cost optimization, performance efficiency and sustainability. We're gonna cover each one of those individually and then we'll dive back into the architectural characteristics that Vice were found during the a um auction company application. And we'll go through how you could actually build an architecture and then validate if that architecture does adhere to the characteristics that you found through the architectural carter.
So let's start with operational excellence. So operational excellence is a pillar that focuses on running and maintaining applications in production on the cloud. But it's more than that, it's implementing and improving processes and procedures and it comprises of a number of topics.
So the first one is automating changes. So whenever you deploy stuff, it should be automated and then responding to events and hopefully that responding is also automatic, then you should define process and procedures like run books, playbooks, et cetera. So that the entire team knows how to respond. If there is an event, if you look at the security pillar, that's about protecting information and data, right and protecting those systems. And when you think about security, it's about the confidentiality and integrity of that data, managing user permissions throughout the application. And when you think about service applications, which we'll talk about later, how do you ensure that that user gets the right privileges throughout all the various microservices and so on and then it's about establishing controls. So how do you control access, not just for the user but different microservices to different parts of the application?
If we switch to the reliability pillar, this is about focusing on workloads and ensuring that they perform the intent that that workload was actually built for. And furthermore, we want to recover from failures really, really quickly and ensure that we can meet demand. So if you think back to what Belia was talking about, how do we handle that scale when that auction company gets those hundreds and thousands of users. And so it comprises of going through a distributed design system. We want to scale horizontally. We don't want these monolithic huge systems that we built previously. You also want to have recovery planning in place and it's not just a document, right, that bit of code should be able to recover itself and it should handle failure. And we also want to adapt to changing environments because the systems we build today are pretty complicated and highly integrated. And so what happens if a system down the line breaks? How do you handle that gracefully if you look at the cost optimization pillar, this is all about minimizing the costs and avoiding unnecessary costs.
So how do you build systems that you know what the cost is and then go and monitor those to remove unnecessary expense? And the first way we can do this is to understand the spend that we're actually doing in the system, then we have to select the right resource types and we'll cover this in a bit later. We also have to scale to meet business needs. So idle infrastructure is costing you money. If you can use the elasticity of the cloud and scale back, you're saving that cost.
If we look at the performance efficiency pillar, this is about streamlining and structuring both it and computers, right? And it focuses on key topics like selecting the right, resource type and the workload requirements, monitoring, performance and maintaining efficiency throughout the system.
And the last one is sustainability and this is key to everybody. I mean, you would have heard a lot about sustainability and how do you build workloads that minimize the impact to the environment going forward? And the key thing here is it's a shared responsibility model. So you'd have heard through the presentations and keynotes over the course of this week is that AWS is gearing towards being cloud um sorry, being carbon neutral by 2025. But it's a shared responsibility model if you're using really large resources that, that you shouldn't be using, right? AWS has to offset that. So we've got a a dual role to play. So you need to make sure that those infrastructure that you select is right size correctly and maximize the utilization, use things that close to 100% you know, utilization and scale out as you need to. And then we also want to minimize the required resources that we use, which makes sense, right? Because if it's not running, you're not generating a carbon footprint.
So let's go back to Valli's auction company example. So if we look at availability, scalability and security and we map this to the well architected framework, we can see that availability fits to the pillar of reliability and security, obviously maps to the pillar of security and then um scalability, then maps to performance efficiency. So how do we scale out and scale out those infrastructures? So through the architectural carter, we would have come up with those architectural characteristics which we show you here and then you should map them to the well architected framework. After that, the next stage is to come up with an architecture.
So here's a pretty simple architecture. We've got web and mobile clients and API s and they're integrating via Amazon CloudFront, which is our content delivery network to API Gateway. You can see there's a caching component and then the data flows through to the business logic, which is the Lambda functions after which it could go to a database, it could go to other downstream systems, but we'll keep it pretty simple for now.
So how do you know what practices you should be following? How do you know what's the best approach? Well, the first thing is follow the AWS Architecture Framework read through those white papers because we give you really good guidance, but that's not enough, right? And so we have architectural best practice for servius and other systems.
So why did we pick servius if we look back at the previous slide at our architecture, the services that we've picked are all managed services from AWS that we call service services. And what are they? Well, there are services that handle data integration and compute and you don't need to manage the underlying infrastructure. And so if you go over to the architectural best practice for service page. You can go see guidance on how to build service applications that align with the pillars of the well architected framework.
But here we're mentioning serve right. And previously I mentioned the well-architected framework, the well-architected framework is very general guidance applications across the entire cloud, different kinds of applications. But what customers have told us is that we need things that are specific to our business. Maybe you do financial services, maybe do high performance computing, maybe you do service applications. And so what we did was we took the well architected framework and we created a bunch of lenses, these lenses extend the AWS architectural framework and dive a bit deeper into those specific types of workloads. And today we have 15 and you can see there's things like financial services, there's high performance computing, there's container applications, but today we'll focus on the service applications.
What I also want to point out is that you can build your own custom architectural lens. So this is great. I work with a number of financial services companies and they're building their own architectural lenses so that developers and architects will focus on those things that are key for that company, maybe it's regulatory compliance, maybe it's standards, et cetera.
So let's dive a bit deeper into the into the the service application lens. The service application lens comprises of these various layers and you can see them here so there's a compute layer data layer edge layer and so on. But if we go back to that architecture that I showed you, there's a few that we can call out. So the two or the three that I wanna call out here is the compute layer. So those Lambda functions and we'll dive into that deeper and then user management and identity layer as well as the edge layer. And how can we optimize that for the characteristics that Release were found?
So let's start with the compute layer. So I mentioned that API Gateway and AWS Lambda make up the compute layers. So I'm gonna focus on just the Lambda functions for now and you need to ask yourself some questions. Should the Lambda function connect to a database? Where does that database reside? Is the Lambda function going to connect out? And so if you think about those three characteristics and we tie them back to the pillars of the well architected framework.
If we're thinking security, should that Lambda function run in the public part of AWS and connect over a public endpoint into the VPC? Probably not. You want that Lambda function running inside the VPC. So it's got the bounds of the, the virtual private gate um your virtual private cloud. So you'd want this Lambda function running inside the VPC. So it can talk to the database directly and not traverse the internet. But then what happens if the Lambda function needs to talk out. So how do you do that? Do you have a N a gateway? Do you look at something like a private link? So these are the trade offs that we need to think about as solution architects. What are the pros and cons and these lenses help you dig into those decisions that you've made?
So, we've spoken a little about security and running everything in a VPC. Perhaps you, it's ok and you can run it just standard. You don't need to run it in the VPC. If we go further and we think about reliability, right? Are these Lambda functions stateless? Can they scale or you running everything in that specific Lambda function? If you think about performance efficiency, are you using the right type? Is it a RM? Is it um x 86? Have you optimized the memory on the Lambda function? Because if you increase the memory, you get more CPU power. So these are things you need to think of.
I wanna call out another one, operational efficiency or operational excellence. It's not one of the pillars we're looking at. But if you think about operational excellence and your entire team is a.net shop and then perhaps building the Lambda functions, in.net is better for you because they don't have to train on a new language. However, when we're looking at performance efficiency, maybe a compiled language is, is not a good idea. Maybe you want something like Javascript or Python to get better start up times and smaller Lambda functions. So these are the things you need to think about if you look at API Gateway, um it's a managed service so it's gonna scale for us. But if we think about security, how are we managing that? Right? How are users being authenticated? We haven't really spoken about um Cognito here, but perhaps that's something you want to use and how do you secure API Gateway? Talking back to the Lambda function.
If we think about user management and identity and I touched on this with Cognito, right? Maybe you're coming in from Active Directory, you need to go somewhere and then authenticate through the process and maybe this is running inside your corporate network. And so CloudFront might not be something you want to look at. So these are architectural things you need to think about, right? And here API Gateway is managing, that's the ingress part to the entire architecture. So again, think about those three pillars that we've isolated, so security reliability and performance efficiency and then you know, architectural system for that if you think about the edge layer.
So here's another place, as I said, if you're thinking about user management and it's coming from on premise, maybe CloudFront is not something that you can use, right? And you need to run everything inside the VPC. But if you're thinking about performance efficiency, which Baliwe alluded to as one of the characteristics is that running inside the same, you know, geographical region cause there may be CloudFront's, not, not needed because you get low latency directly to API Gateway. But if auction company running worldwide, you might want access to the content delivery network that is CloudFront.
So in conclusion, as we know, we started with the architectural carter, we got characteristics and then from that, we dived into the architectural um framework that we call AWS well, architecture framework and we defined these pillars and we have some great resources that you can go have a look on the AWS Architecture Center. There's architectural guidelines, there's um best practice and you can align those architectures to those characteristics that you found through the architectural carter. And that's me Feliu.
So having having gone through everything started out um on how to get these architecture characteristics where we actually started. This entire talk was quoting from Mark Schwarz where he said it's time for the business and the IT world to come down. Now, having looked at the practices that we have that are available to us, having looked at the AWS world architecture framework. Do we actually see a world where it is realistic that you can have business and tech talk to each other? And there is actually an understanding. We've got all the resources you've been scanning throughout. We've got them here again, if you missed out any of the QR codes, you can just grab them very quickly and again.
Thank you very much. Please rate us on the app complete the survey. Tell us how it went and tell us where we can improve. We do appreciate the feedback. We appreciate you being here again. Thank you so much.