Right. We'll go ahead. I appreciate you guys having me out here tonight. So our topic tonight is going to be a discussion around how to speak the language of application architecture. Okay. So we're going to touch upon quite a few things here tonight.  We'll talk about the software architect world because that thing seems to move around and have different things morphing with it. We'll talk about continuous design and application architecture design principles. We'll go over some things that will lead to generic models. And we'll talk more about modeling your software, a little bit about design patterns, and something called architecture review books. And finally, we'll go into a little bit of EA or enterprise architecture and frameworks that are around it. So without further ado, let's go ahead and jump into this. So as much of my name is Brad Bierman. I work for a startup downtown that's called Kapow and we get involved with corporate events management. And then we have a platform that manages that and it actually goes on the Ruby on Rails stack with SQL. We've got React in the front end and a lot of other fun stuff in the middle that make up our technology stack. And I work as the director of technology acting there for close to a year. I also own a website called ProfessorString.com, which is a website that's for about 10 years or so dedicated to guitar strings. And so I also hand wind them and have a company up in Wisconsin that helps me do that. And so we run strings for celebrities, like Carrie Underwood's guitarists. We did some strings for prints, views around stuff. So yeah, all the fun stuff that goes on with it. So ProfessorString.com. Check that out. So that's another company of that. So a little bit about Kapow. Again, we're in the corporate event space. We have about 1,000 customers. We've got 5,000 events and different experiences. What we kind of bring to the table is instead of going to just a hotel for a large sales event or just doing the regular steakhouse, kind of offer some different experiences as I was talking about. So one of the things we've got is if you have a corporate event that you want to do, it's a little different. We have for something that involves ax throw, archery, pizza toss. We even have adult tricycle races. We've partnered up with companies such as Nike, which you can go to a Nike store and have a corporate event hosted it. And Nike absolutely loves it because you can walk in to just a shoe store. There'll be wine, cheese, food, presentation, everything is set up. And so it works out really great. We've really established quite a platform for that. But the big news for us really came about a month ago. And this was the headline right here. So we actually just got bought. Sivan, which is the largest company in this space. They're about $1.8 billion in size. And they came in and bought us. And we were about 50 employees. And so a very exciting time for us. And so the cow said about six years ago or so, and we were actually out to look at additional funding and see what it says. Man, you guys got a great thing going. The number two office space in Chicago, that's actually a picture of our front office. Yeah, we like to capture what an event kind of looks like. So we better moose bar in that. Anyway, that's it. Let's get into the stuff. Software architect role. This is an interesting role because it's changed a little bit over the years. And it's often broad in what it encompasses. We have four buckets that really captures. And so we've got things that focus on applications. So really the designs and structure of applications. This is where you'll see something software architect, app architect, or framework architect. And then we've got folks that are sales and support. One time I worked as vice president at Oracle. And I had close to 30 what they call solution architects reporting to me. We would go out in the field with our architects and help sell. I shouldn't say sell. Assist customers with the implementation of the product. That was a solution architect. Sometimes also knows a field architect. Very popular in the license software area. And of course the systems, skill and infrastructure design. This is the big one right now, cloud architect. We've made a lot of changes from infrastructure architect to system architect. Of course operations. And operations of the enterprise. Enterprise architect, integration architect. So those are just some of the roles. I know everybody's kind of seen those over the years. But they take different shapes and forms that we're going to focus on these two. And the discipline that's around. So what are the essential skills to really become software architect, so to speak. So the main area with an architectural modeling language is a key piece. Fluent and creating diagrams. Visual feature representations. You've got to be able to do that. The main area with a framework like Togat, Zachman, ITIL. We'll get into those in a little bit. We'll also want to talk a little bit about, hey, just comfort around a code base. It might not necessarily be a developer as an architect. But you could be around a code base. It varies depending what you do. But you've definitely got some experience as that walking into that role. So your key thing here will be to present a vision of how something is built in an holistic way. And also drive cost-effectiveness designs and options for as you build a platform. Debates and symptoms. This is kind of interesting to talk here because growing and mentoring architects. It's not really happening at the level today that we see probably some years ago. Particularly these things were more waterfall, more longer design period and that that were going longer. So that role really became more prominent. Today's architect, they don't see a lot of that happening about, hey, how do you grow that role? Or something there because now we're just doing our work in little snippets. We're doing little releases. This thing called Agile came along. So the role took a little bit of a different turn there on how it was grown. And the other thing too is it's kind of hard to measure design as an investment. Because I've got a friend of mine that sells architecture roles. He's like, you know, it's really not much different than selling vitamins. So it's something we know we should do. We know we should put design and things that are in a rush to be agile. We'll get right into the cup and do this small one week spread. There's two weeks spread or something. We really haven't put down anything diagrammatically. We haven't put anything visually. We maybe just did some envisioning and boom, code starts coming out week after week after week after week. Year after year after year. Now you've got it's massive code base. Perhaps possibly there's no design documents around it at all. So that's a sticky wicket. And why is it that way? Well, some folks think design slows development. Okay. Oh, I got to take time out to do this. That's just slowing me down. Our other, here's my favorite one. The code is our documentation. It just says, just go read it. You know what it does. Okay. There's what runs. So it really doesn't describe things. We'll get into that. Okay. And agile development. Yeah. The envisioning step. Really not being done correctly the way at least it was intended in the original manifesto. The design discipline guidelines, principle number 11. Very loosely defined by design. That's the way we wanted. We didn't want to dictate how people should design stuff. But it also has kind of manifested itself and said, that step could be somewhat skipped a little bit. Just a little bit of a discussion between you and I. That's how we're going to do it. And boom. That's how it starts. And so code delivery ended up being prioritized over design. And so what we end up with is a complete abandonment of architectural skills that we really had in waterfall. And so oftentimes I find a lot of developers that, you know, just basic you know, don't know the principles around that. How to diagram things. We'll get, again, more into this. This is an interesting thing here. So I almost took this from Simon Brand. He says, it's an industry sacro that should say anything bad about the agile manifesto. But it has some games.  Nothing's perfect, right? Going from a developer to an application architect. So as I've worked with developers, you know, I have a group that reports to me.  I've been in development for a long time. I'd like to go more into that role. I said, well, there's been a mind shift that goes on with this. As a developer, nature of work is more an instant gratification. I write something. They maybe run some renders and I get to see the results right there. Instant. I get to see it. In your application, success is measurable. Okay? Your product is a code base. As a developer. The code is viewable. You can actually see the code as a developer. Okay? It's low abstraction.  A little bit different as an architect. So the nature of the work is more of a delayed gratification. The success of architecture is hard to measure. Your product is a vision. Your product is a vision of what something has to be put together. It is something that is somewhat invisible to us, but it's omnipresent. Even in this room, just from construction, we've got architecture here. How is it put together from our architect perspective in that? It's something that's not really visible. We see the improduct of the building, but what was down in the blueprint was the thinking. So a little bit of a vision that got us here to what this architecture would be. So a bit of a higher abstraction in this role. Okay? So where do you start as an architect? To start by thinking about being design driven. Okay? Design driven is where you want to go. Step two? Well, yeah. Be design driven. Start there. Ease into it. Don't rush. This is a discipline. This is a discipline of being an architect. Think about how something, a business, consumer works, and the strategy behind it. This is the kind of thinking mode, the strategy type of all about how we're going to build something. Resist the issues to hurry and draw something or rush into patterns. I've seen folks get in. It's just, well, let me just, I feel like I've got to draw something. I'm the architect. I've got to get up at the border. Throw me a drawing race marker right now. I've got to go and do something. Take your time, man. It's a vision. That's the product. And this takes a little while to evolve on that. A bit of a discipline going from I'm writing code right now and booting there. It runs, type of thing. A little bit of a delay gratification that goes on. Very strategic in nature. And it involves articulation. It's easy to overwhelm an audience. Hence the cards. Okay. Now that you have an open view of the system, now we're ready for more detail. Come on, give me a break. Think big. Think big, but start small. Little pieces. Kind of like what you manifested in those pattern modules. So get the big picture. Get the holistic view. But let's start in small pieces here. And then start to segment and decomposition that now. So code versus strategy. Our code tells us what is being done. The code is merely a set of instructions. That's what it is. Okay. Architecture tells us why something is being done and how it is being done. The architecture is a vision and strategy again. So for folks that like to say, hey, the code, that's our documentation. That's our base. Well, it really doesn't address, why are we doing this? Or how is this to be done or anything? So again, just the code is a set of instructions for a process. So again, thinking at those higher levels here. So one of the things that we started focusing on here, this is, I come up with something called continuous design. And we'll go a little bit into this. Those of you that were around during the dot-com boom, you'll think about around like 1999 or so. There was something that came around that was called Extreme Program. Okay. Very popular at the time. And this was starting to come right after Agile. So it had this thing called continuous design. And this is the practice of creating and modifying the design of the system as it's developed. Rather than reporting a specific, to specify the system completely before it starts. And that's the whole genesis of where really Agile came from. And there was an interview with Martin Fowler. He said, where did you guys really start with this when you were up in the ski lodge in the 17th of you? He says, well, we were having this huge Agile about extreme programming. We just need to really get this into some type of modification here. We're two years into extreme programming. And it has really worked on control. It was the extreme programming part. And having this continuous design. Okay. Continuous design was popularized by extreme programming. Continuous design also uses tester involvement, which we use a lot today in refactoring processes. Okay. So that's where that piece came from. Back in 1999, when this kind of started, the manifesto came around in 2001. And so we've seen where it's going on today. And so that was kind of the genesis of where this comes from. Today, we see different companies taking on and saying, oh, we're 100% Agile.  Some companies are saying, well, we're on the move from waterfall and the Agile. Okay. So right now it might be Scrumfall or Water Scrum. I don't know what you would call it. It's a mix of the two. Some folks have gone from waterfall. They tried to go 100% Agile. Maybe they got as far as they went and said, you know what? This thing has got some gaps. I'd like to hybrid this thing. And that's a move we're starting to see as Agile is now. Well, we're kind of approaching 20 years on this type of thing going on. So it's been with us for a while now. So people are really starting to embrace a lot of that hybrid. There will be friends here. And so it's a mix really of both. We still love the things that we saw in designs in waterfall. We still love the things that were analysis in there. But it doesn't work to spend the next couple of months working on that. We still want to keep this practice. But yet we still like our Agility here. Be able to do erative coding, small releases, quick deployments and things like that. So how do you get this to work together with each other? This is how it kind of works. So as you've seen this here, this is actually our life cycle at Kapow. When I first came to Kapow, it was a one week sprint. That's kind of tough. And as I came in, 70% of the points would roll over the following week. Sound from there? Yeah. We've created a new waterfall. Roll over. And so it was a real problem. And as I brought in younger engineers, people had less experience onboarding them. Absolute nightmare. Because there was no documentation around the code. Here's a code base that had been going on for four years. Now one single document. I had two developers, lead developers. It's all up here. It's all up here. Just go talk to person X, person Y. Well, person X and person Y, I'm managing them. I know this one's about ready to lead. So there goes the stuff out of the door. We've got to do something to get on top of this right here. And so continuous design. Let's borrow that chapter out of Extreme Programming. I put it right here. Stretch it out to a two-week sprint so that it allows us to start thinking about this. It's called Design Just Enough to Get Through the Sprint. In fact, there's a popular book out by Simon Brown. We'll talk about one of his models here in a little bit. It's a book called Just Enough. And that's what it's kind of discussing. Just enough design to get through the sprint. Now you've got a running document. You've now got a running artifact. And what we do in this is we'll create a crutch to 4 plus 1. You might do a little bit of UML modeling. You might do a C4 model. A couple of things. It continuously lives with the code. We could just write the code and that does it. But what I found is as we start doing these diagrams and we start to build in, getting somebody onboard it, man, did that become a lot easier because I just put some diagrams in front of you to see, here's how this process works. Here's a sequence diagram. Here's a crutch to model. We'll go into that in a little bit. So what that means? Huge help. Absolutely huge help. As a big success, I think for a lot of junior programmers, one of the challenges we've got today as an industry is when you go out there and look in the job boards, 90%, we usually want somebody that's a senior developer. How come everybody wants a junior in work? These code bases have become so complex and things. Not everybody has documentation. You've now backed yourself in a corner. This is so complicated. I've got a big ball of mud I've got to really dig into. So we've got to find some way to nurture these folks here. And so this is kind of a cycle. We spend just maybe a day or two on this and we'll go through it. We'll do our spread planning. We'll do our grooming around those things. Do the development.  The typical rest of the cycle. That's how we're kind of working in the two weeks, making sure that that continuous design piece is in there. And that's really the focus of what we're talking about. As I started working with the team, I found a lot of folks that are, I'm going to say that we're not around during the dot com, that we're not around kind of early days, hey days of waterfall. Things like Yomal, those disciplines really aren't taught anymore. And so we've kind of lost a little bit of that. Continuous design principles. So incremental design. Design just enough, again, to build the sprint, but build upon the application's holistic view. And that's what you end up with, is you keep going down your sprints and building up your design doc with it. Pretty soon over time, now that you have a built up code base, you've also got the design built up with it too. And so one of the key successes for us is as I pushed this forward in December, we were getting audited. I didn't know it was really in audited, but it was called diligence phase when we were out there trying to get funding for Kapow. They came in and wanted to see, hey, how'd you put this together? And what they were fully expecting was to see no documentation and hit the reject button, as what they've done with 98% of folks out looking for funding. When they came in our shop, guess what I had them ready for? All these design docs out there, and I just handed it over right there, but we passed right through that, and they said, we want to talk. Pretty soon a couple weeks later, we want to buy. And that's a huge difference because that allowed an investor to come in and see, oh yeah, I get it. There's some discipline around this thing, and I visually see what's going on with it. So build confidence in your funding cycle. Build the change instead of building to last. That's a key part of obviously being agile, but not to say we're going to go out there and spend all this time on design, but again, just an incremental piece. And it's always going to be changing. So nobody has to stay up on these diagrams either. Just get the latest one we've created. It's always continuously going. Model to analyze and reduce risk. Use design to identify key engineering decisions. It helps with cost, obviously maintenance, whatever else. Recognize the late-graphication. That's really in the design. Use models and visualizations as a communication and collaboration tool. That's key for your continuous design principles. I first started to have some engineering people come up and say, all right, well, I guess we'll get up to board and draw a picture of what this kind of looks like for you. And like, wait a minute. We're going to draw a picture. We're going to draw a diagram. Just even the lexicon has been lost. A picture. This is a picture. It's worth 1,000 words. This is a diagram. Diagrams are right to the point, and often should be a few words. Boom, succinct, focused on one thing right there. We don't want it to be interpretive. It's got to be a specific segment and get to a point of what it is. That's really kind of one of the things we want to look at here. And so Simon Brown, I've said this guy's name a couple of times. This is really interesting. Far too many teams allow their code bases to grow without having an insight into the structure of the code. As old as often the proverbial big ball of mud. Code base that's tangled, hard to understand, hard to work with, hard to change. This is the key phrase right here. Visualizing the structure of your code is the first step towards improving it. Isn't that true? If you can't visualize it, where are you going to start? Where are you going to start? It's tough. And so one of the things Simon Brown does is he goes out and consults. He goes out to these big Fortune 500 companies and takes the lead engineer or lead architect. Please draw me what your code base is right now. These are actual drawings. He gets. One of these is actually from one of the... I'm not going to call it. It was somebody from Baxter. It really kind of heads up a lot of the problem in there. I don't think it's on there. One of these is his. There's actually somebody from a couple. It's just interesting. I'm not even going to say who these folks are. But look at this. This is somebody trying to communicate to maybe somebody like you what their system is. I mean these are some real masterpieces. Like what is this? This one here is actually my favorite. It looks like it's structured. There's no function view. I've never heard of that as an architect. There's no formalized thing called a function view. There's nothing functional about it. There's no communication. It's just some boxes or whatever. This one was actually drawn by the company CTO. Okay. There it is. What's going on here? Again, our ability to visually communicate our code structure. We kind of lost some of that right there. I'm going to show you a few tools. To start into this. Our quest to become agile is lost ability to visually communicate our code. Let's talk about some generic models. What can I dig right into? Just make this a little bit easier. There's been an evolution of these models, languages, and notations. If you've been an architect for a number of years or been around it, you'll notice. You'll recognize some of these things going back. This has been talked about since the 60s. Even with the invention of things such as small talk. Beautiful little object oriented language. Object oriented design came around. This was also one of the first modeling techniques that came along that was based on object oriented design. For those of you familiar with Brady Butch, you know who that is, but this is one of the things where we first started seeing the idea of use cases come around. OMT1, which is object modeling technique 1 and 2. That was introduced by Jim Rumba out of MBIT. He was also a friend of Brady Butch's. There was some competition between these two here about how to model something. Then somebody else jumps in the game, creates Uzi, object oriented software engineering in 1992. Then this company called Rational showed up. They created a product called Rational Rows. I think people have been familiar with that. Yeah, okay. Awesome. That stands for it stands for pretty much a software package that's Rational Object Software Engineer. What they've done here is these guys got together along with another guy called Ivar Jakobs. Ivar is often known as the father of the use case. That is where we actually first saw a use case come up. He is actually similar in this time frame too. These guys get together and then we saw the release of UML 1.0 and then as we started to go into the dot com movement you started to see a lot of people using this language. It stands for Unified Modeling Language. It really takes the summation of these and rolls it up right here into the standard. It's really ingenious and it really has a lot of great intention behind it. The tool that you use is Rows. You create your diagrams in this.  You know how it works. But some things started to change as time went on because this whole thing this gets complicated. There's a lot of diagrams. Today there's 17 diagrams in UML. That's a lot.  It's kind of crazy. But it worked at the time because we were still very much waterfall right here. So it worked in that design period. So then we started seeing extreme programming come about. And then incremental pieces of stuff. And making the design continuous thing with it. And then while we were at home those guys got together and created the manifesto. Then we started seeing service-oriented architecture. And then in 2003 IBM goes and buys rational. And then somehow or another the party kind of came to an end at that point because Rumba and those guys were fabulously wealthy after that point so it was great. Right there. And now some company comes in and buys it and now just kind of puts it off to the side because that was a better. So we started that was really kind of the last hurrah that we saw as far as the marketing the publications the daily stories about modeling languages. It's kind of a shame because we kind of lost it since that time here. Different things have happened but UML continued to evolve as a standard but the tool of growth has kind of disappeared. It's kind of an expensive thing too. I remember as of March 1st we paid a quarter million dollars in our license for it. Absolutely insane. Man, they were making money over a hand or a fist but we had some beautiful designs. We had walls covered with it. We invested a lot of money in it and after two months of no-code and beautiful design we'd had it. That's it. So it was time to look at something else. But what it got there, what it got for us is if you take a look at the arrival of modern frameworks this is when we started seeing something like Rails Spring Django, Symphony, what are those? Those are frameworks of popular programming languages. PHP, Ruby, Java, all that. A lot of the design behind that came through a lot of the design pieces here in this language to build them. And now we've got something we can go out there and quickly build with. We don't have to put together all these complicated components so now it enables us to go fast. Really fast in our architecture and in our work. So we kind of left that behind and just boom, now we're kind of out where we're going today. We're going to talk a little bit about C4 modeling, business process notation and what's going on with the latest year. But now we've also got the arrival of microservices which is kind of a new design paradigm too. We'll kind of talk a little bit more about that. Right now we're going to focus on correction 4 plus 1 and the C4 model. Let's get right with what those are. Aside from reading the syllabus on this talk. It's always interesting when I bring this up, this crutched thing, because when I brought it up to my team it was just all blank phases. And I also asked them to get up to the board and draw something and it wasn't much different than what you saw earlier. So this is a useful thing here because they've really embraced it and we've sped things up. We're able to do more points in our sprints because of this by the way too. So what is this? A model developed by Philip Crutching worked for rational for a while too. He was kind of one of the sales people out there. There was so many damn diagrams in UML he just wanted to distill this down to just a few so he could go out there and sell a rose. But what he ended up doing here is creating a really nice, abbreviated model that a lot of people latched onto. And that's where they're called the 4 plus 1 model. It's a rather generic thing. So it's several things. This scenario considers to be a use case or a story. And around it I'm going to go ahead and create a logical view, process view, development view and a physical view. So I'm going to find out structurally what's my code what's the process to behavior as the user uses it, the implementation view which is awesome how I view it from a component way what interacts with third parties and stuff and then this is my infrastructure view but what's this stuff running? Cloud-wise, server-wise, stuff like that. So I get a nice 360 around what's this use case or something. And it's great. It has been really good for describing a lot of different things. So the scenario is really helping you capture the requirements for all the stakeholders. Think of this your stories, epics everything is around the same and it's really key for putting together all these views because the logical view it's designed to really address the end user's concern about what's being used in the system. If you're familiar with UML in that logical view we call that a class diagram and the class diagram you just list out the classes of your system of what you're using. So we've captured what the classes are. Process view for people who are designing a whole system those of you familiar with UML let's call it a sequence diagram I'll walk everybody through UML here in just a little bit too. Just see several diagrams. Okay, so we'll all know what this says but just for this for you familiar this maps over to UML development view, that's a UML component diagram. Okay, this shows how the modules are organized, reuse supportability, physical view, again this could be our network diagram and everything so what we do is we take a crutch and every time we start a sprint we'll do a crutch and say, okay for these group of stories here what do we need tomorrow on this? Okay, we'll start looking at the process view so somebody up to the board start writing a sequence diagram for that after we've already got what the use case is then somebody might go back and draw a developer view. Oh, here's the APIs I need to kind of connect with this thing over here, you know brain trade to get my payment all this other stuff so we'll kind of start to show that then we'll start to abstract into what classes are we using in our current code base and start putting together a class diagram or something new around that and we'll do that maybe from a conceptual diagram first, just give a holistic view of what it is and then finally my devops guy is always standing and says we're going to run this on the EC2 instance over in such and such an AWS cloud right there so we just got everybody engaged in this and we got it visually mapped right there and now people are going to go back they got this reference in their head, this vision of what this is okay, one other model I want to point out too is a C4 it's not explosive C4 is developed by Simon Brown this was, he started using a little bit of this around 2006 but really published it in 2011 this inspiration was crutched in in Yuma this guy was huge in Yuma he started back in the day, he really was in the UML and stuff and then as we saw the evolution go on with it, he felt hey there needs to be something a little different here too so the C4 model, it's generic just like the crutched model, it's visual non-notational when I say non-notational I'm speaking in terms of like a language like UML is notational BPMN is notational you don't have to learn notation it's just a model a hierarchical set of software diagrams, context containers, components code, that's really what this looks like his inspiration was Google Maps for this thing when we talk about context we're talking about a holistic view of something when we're talking about code, we're talking about the street level view so if we want to work our way backwards on the C4 model if I started at the street view, this is my code most granular piece, I know where it's at okay and then if I zoom out a little bit further here I see that this road here is near maybe a KFC or a limited car parts or something near a Waterworks Valley so I zoom out even farther and I'm starting to look at containers, okay this is code, components containers and then we're going to work our way over to context those are the four C's it's a zoom model if you will it was interesting as Simon went through this, he asked people where's this road at it's almost like you're going in a code base and said where is this what does this section of code represent? explain it to me without the context of what the whole system is without any type of representation visually how do you get a good accurate picture it is really tough not only until you've been working with that code base for quite a while do you know what it is and so we need to have some type of context around this and so we start looking at zooming out here as he started using this example of the street he said where is this at we started thinking oh it's by a KFC limited car parts it's over by Fern Valley probably here in the United States right as we zoomed out it's in Jersey you can stop by and say hi to Snooki but as we look at this further we found out no I need more context in it's actually in France it's an island off of France same thing with the code I need to zoom out and find out where I'm at so that's how we do this with the model the model starts out as this take a look at what the overall software system is put your container on it in other words this is your client side web app server web app side console applications mobile apps micro services all those things go in a container and then we start to componentize that and take that down to a code level is essentially where you had with that okay I'm not going to go into the details of how to do it but definitely check out C4 model also check out correction 4 plus 1 I didn't want to make the intent of this to teach everyone how to do it but it's become more of awareness of how to do it those are the things modeling your software three ways architecture design often happens ad hoc no method at all just start going it just evolves I'm starting to write code just starting on or we go with an industry standard hey I might use a C4 I might use a crutch might use some notation I'm just going to roll my own just get up there and say well I'm going to draw it on the board this is kind of what it should do and then let's start writing something around it not everybody might understand those are kind of the three but again it's to show that architecture is an omnipresent but not always visible okay let's focus now on UML UML is quite an evolution along with that chart that I just showed there's many things that actually contributed to UML you have Moses, you have Soma, you have open OML there was different things that contributed so what we saw here in the early stages there's many different types of modeling techniques, many different types of models you really need to standard it on this thing and that's really what came together and that's what Ramba that's what Buj, that's what Jakobsen all got together and they were known as the three models that released this UML 1.0 and this was something that was accepted by the object modeling group and that was a standard and since that time we've kind of seen new releases of UML but there really hasn't been anything else around that being done until we started to see SysML which is a derivation of it, it allows me to do system architecture modeling and I've started seeing some people use that in their cloud architectures and that's a very handy notation for that in the business process modeling rotation a lot of people ask me, hey Kapao which version of UML are you using it's a good question we're using 1.0 it's just it's just a real simple thing 1.0 and the tool we're using is Gliffy that's in it's asking confluence you can use Vizio, do you use any tool like that and what's interesting about those tools is if you go take a look at it they're actually based on UML 1.0 there's a reason for this when UML started to become more complex the thing that they were trying to do with UML is if I could create enough diagrams that depict the whole system I could generate software with it and that's what Rhodes was essentially trying to do so if I put all these diagrams together in UML it would generate the code and sure enough you'd see that in a demo that's interesting, what you create was a happy path of the NBC you wouldn't see exception handling in that code that was always one of the things I wanted to see the most is that and there's where they wanted to start to take you about well let's capture the rest of that now we've bloated this thing out to a complete nonsense it's just too much and it becomes so complicated and it's a shame but there are key pieces you want to learn how to do sequence diagram, class diagram component diagram those are the three right there that'll get you through a crutch done that'll get you through a crutch done and you can also use that with the C4 as well because if you know those use that in your model as well so it's just a notation it's a visual modeling language applies to modeling and systems it's used for expressing artifacts it's based on object oriented paradigms so that works well for lever languages developed by the three Amigos I mentioned these guys got to some again known as fiber abuse cases and so what is UML and what is not it's what you do in your architecture your modeling stuff it's not a tool or repository specification it's a modeling language specification UML 1.0 UML 1.5 those are specifications for this modeling language it's not a process it enables processes sequence diagram we'll see what that looks like here in a second we're enabling things with it today's UML this was just published not too long a good 70% of UML was a useless part so overpriced clunky tools looking at two rational rows don't learn UML to go around annoying people with useless class diagrams do learn the basics so you can read a sequence diagram and learn to think this way that's some pretty solid advice actually don't go through and try to learn the whole thing don't boil the ocean just a few diagrams is just enough to get you to structure a new language together as we got acquired by Sieven they have eight different platforms running at Sieven 13 different languages there's I believe he said a dozen different frameworks going on like how on earth are you able to talk to each other he says we're kind of screwed right now I'm like that was a real mission of guilt I was like but I just got to tell you because he already saw our presentation I said it says this discipline we got to get our arms right because it's a big thing for us we have a lot of people that are on Java but they can't talk to folks over on rows here how do you get it to a universal language I said right there and let's bake it in so that's kind of what Oliver is getting at here too is hey just learn a few of these just learn a few of them that way you can have this communication tool and send stuff back and forth with each other makes a huge difference we're not going to spend our time on these diagrams we're going to keep them up today I think it's just a tool so we can avoid what we saw on those whiteboards earlier it's just oh my god so use case is an end-in-processed description the office kind of came up with this idea it includes many steps or transitions it's not normally an individual step or activity identified by the actor can log in the actor can print a document print a document as a use case I'm just identifying by saying the actor can't what's an actor that's what it's called in UML but we've also known it as a user but the formal way is an actor why wouldn't they call it a user why do they call it an actor that's kind of interesting when I was learning why is that why don't they call it meatware it doesn't necessarily have to be a person it could be something playing the role in fact when I just worked for Quaker Oaks some years ago when we did our use case model for them we were doing some things with pet food and the actor was a pet he was a dog he was trying out this taste system and it would register in the software so yeah good case right there it doesn't have to necessarily be a user it'd be anything use case has a pre-condition an action and a post-condition so pre-condition is this is something in a system so login pre-condition I'm greeted by a prompt waiting for my user ID and my login password that's a pre-condition what's the action type it in I hit enter what's the post-condition I'm logged in I see confirmation there's the login use case right there is that a design pattern you bet it's used everywhere and when I'm at sea vent no matter where I'm at no matter what platform that design pattern exists I could go and represent it by this I just call that login common language so there's this thing called essential and real use versus real use cases so in essential use case it's a very abstract less detailed use case real use case very concrete more detail when I write up this thing more information about it so you can get as detailed as you want about your use case when you write that thing up okay so that's the difference between essential use case, real use case so this is a very summarized high level the example I just gave there that's kind of more of an essential use case so login I didn't go into details about do I got to remember the session you know should be encrypted should I show the password I didn't get any more details of things so that's more of a very real as opposed to that I'm just essential use case diagram anybody seen these before yeah okay nothing new here if you have but okay so this is what it looks like so after I identify use cases I start to put together a use case diagram so I might have my use case is by stock supervised store staff my other actor is store staff they can update status they can make inventory report you start to get an idea of what's going on in this system okay this box around here is called a system boundary and it's where all these use cases play into we call it the inventory system in this example so what we're modeling here is use cases that make up an inventory system can use cases extend each other and include each other and by stock I get payment that includes that type of function by stock can extend report quality issues to supplier can also include return damage goods I'm using some type of notation here to show what the heck this system is supposed to do we do this today in agile we call them stories but the challenge we get when we're using a tool like JIRA we put all this stuff in a backlog I really don't get this from doing it if you're doing story mapping okay anybody doing story mapping with their agile today a lot of people skip that that's also one of the challenges out there so that's also one of the other quests I find the product management has really done well at easter is keeping some type of backbone of what's going on with this so we want to also think of this in terms of a conceptual model so the quintessential object-oriented step in analysis where investigation is a position of the problem in individual steps the things we are aware of we call this a conceptual model the focus of the conceptual model may show concepts, association between concepts, attributes of concepts I gave two examples down here this is related to a flight system so yes a flight actually has a date and a time real world concept, not a software class or artifact so my conceptual diagram, my conceptual model that's what I want, something real not abstract, let's just flight, database date, time this is a software artifact, not a real world concept, when you're abstract when you're in some type of conceptual diagram, deal with your real workable, don't start thinking in terms of your software yet, that's one of the things I see is people are starting to come from the software developer role in architect, immediately want to start thinking like this no no no, we want to talk like this here because what is it we're trying to do for the business what is it about the user, there's a user focus here, it's product management speaks like this, business speaks like this, get to that level they don't care about flight, database is a record, buried somewhere in my secret, whatever we'll get to that later, it's important we'll get to that later, but not at this phase so that's how you want to start with your abstraction, decomposition into classes, and so you don't know how a class is a description of set of things that share some attributes, methods relationships, manage, you already know that for a lot of object-oriented programming operation as service that can request an object for a different behavior here we go, let's compare the two alright, so this is one of the conceptual models here, I've got a flight with a date, number of time, it flies to the airport in a name those are two potential classes, right we want to get a little more concrete with this, we want to get more software oriented at this point, so call out your classes in operation, well I've got a flight class, it does have a date and time it's described by a flight description and what is this right here we call these multiplicities that's your notation, so for every flight, I have many flights about one description okay, I can also have a flight description, many flight description that only flies to one airport okay, so that's how you multiply early on as you're putting this together what are you essentially getting right here your data model right off this diagram, it's coming right off as you identify your classes, how they relate from your class diagram, this is that I remember when I was at Capala the first time I had put this up to this conceptual diagram, my lead software guy had him, he's really sharp he looked at that, and he knew what these were right there he says, after we got everything done up there as far as the conceptual line, he says we're already done with the data model just like that, and he had a reference for the thing he was able to go sit down and take the sink and run with it and start putting in a crutch and so it was great right there and we also got to communicate this and find out from a business level does this logic make sense why decomposition in your conceptual model well, decomposition is really an intermediary step, going straight to classes is tough I've seen some people try to go directly into classes as they're talking to their product manager again, don't think like that to get your object kind of how do you get it keep it in a real-world terms put that into the model and then you want to decomposition into classes then you can divide, there'll be plenty of time to do that with your engineering team or yourself or whatever keep it at this real level and then decompose later if you're struggling to find your classes or abstraction go back to your conceptual model because you might have missed something that's where it comes from I keep mentioning this thing about a sequence diagram in UML, it's a real simple thing shows a particular course of events within a use case shows the external actors that interact directly with the system, shows the system of events that the actor generate and the ordering of events should they follow the use case so actually right here, I have some type of actor can send a message, this class fires off of it, this is called a life line each class has one, these are probably what methods that are in that class I'm calling we see the interaction between classes how my actor uses the system this is a sequence diagram in UML it doesn't matter what language I'm in doesn't matter what framework I'm in but we can all talk this language this is one of the key things and this was always so nice about it when we had a lot of people cognizant of notation so getting back to this discipline it's huge it makes a huge impact on things so basic sample right here, cash here use case is what? buy items enter item, there's my method UPC, quantity, how's that enough to work with the system can have it in cell, make payment amount we're starting to see how this all is enabled by what cash here so I've got a visual representation of what's going on with this thing one of the things we've got in our system is checkout a lot of people got a checkout in their systems modeling that in a sequence diagram and ours was huge it was just ginormous, there was a lot of stuff but what's interesting about it it was just one single method that called a whole bunch of stuff going on in the background, had to verify had to go through payment had to go through zip code there's all kinds of stuff related to making a payment and at the very end there was a return method that came out success also works for front end one of the things that's become more complicated here is our front end we didn't used to have some of the front end complexities for a while some of the front end frameworks you guys got involved with React, Angular, View, Embers and for a while those things were changing a lot every 18 months or something it was driving me crazy it's still JavaScript at the end of the day but why so many frameworks? you go out there and look on MPM it's a wild ball of less there's a bunch of stuff going on out there wouldn't it be nice if you could actually model the front end in this and kind of reduce some of the complexity of the framework that's kind of what the sequence diagram will also do so I gave an example here too of how we could essentially have the user piece going in with this and then communicate with the back end application whatever's going on here I could expand this out to multiple classes where it's check log in, validate log in oh this is coming back from this is probably what? JavaScript right here so I'm modeling the front end and at the end of it, yeah, save the user again, same type of diagram sequence diagram let's talk about this other diagram class diagram so it illustrates the specification for software classes, shows definitions for the classes identifies the classes participating in the software solution and shows the class relationships that's an interesting thing when I take a look at one of these large code bases that's like one of the first things you're kind of going after is like what does this class do what's it about there's also a point where you see some of the worst design software out there too is like what was it thought behind creating this class and look what it's evolved into some monstrosity I can't begin to follow and without a visual representation to tell me what the heck is going on that is damn difficult particularly can you imagine coming out of a 12 week dev boot camp and your background was originally I don't know archeology that's what you got your degree in you don't have much of a systems background and yet you're wanting to get into software development so you did this boot camp that you paid anybody go through boot camp that you paid 20 grand for and it's still tough to find job once you land the job you get put in this huge code base and now you try to figure out these classes that you figured out in your dev boot camp and it just doesn't make any sense at all for a long time and you always had to go to help because who knows this who knows how this is running that's probably been the guy or gal that has been in this code base for a number of years they're working with it they've traveled all the different places in the code base and it's still up where and they're happy because they haven't created any of this stuff yet is their job secure who cares how secure is the company at that point is that person walks out you're just now doubled your the amount of money you're going to spend here to try to get some people up to speed try to figure out what's going on this is an investment over time this is your vitamins right almost as if you just ended up on the OR table as that person walked out the door on the operating table and said oh man we should have invested in our vitamins I hope that makes sense that's kind of a goofy analogy we're working with it for now use case or scenario in the crutch then right buy items look what I was involved with buy items I got a store class I got a post class I got a sale what looks in what houses it's showing the interactions it shows the multiplicities this is the class diagram in UML for buy items I'm also showing instances variables methods all these different things what is it about that's interesting about this class it's got methods but it doesn't have any you did it same thing with this one product catalog it's got a method for specification but not that for specification it's only got fields but no methods I can do that just for I haven't even looked at the code yet and now I know that I really don't have to much about period or what language this is in I immediately got that from this extrapolation huge help huge help in knowing what's going on in this code base that's kind of the power of this thing remember the statement I showed earlier that guy was saying don't waste your time with all these useless class diagrams in a way it was kind of right because when UML was out it was not uncommon that I would see a class diagram with over 300 classes on it and it looked like the biggest spidering web ever I couldn't begin to follow that was somebody that did not say you know just kind of oh yeah I did this and just start writing out everything you got to do it in chunks you got to do small pieces and that's where the iterative process comes today it's back to the Simon book called just enough just enough to get through this is that a great big thing component diagram this is the last one we're going to cover it's useful because it gives us a high level architecture of what will be built as an architect to verify that a system's required functionality is being implemented as a VML 2.x components are now strictly logical design time constructs and they actually call these constructs now but since we're on 1.0 I like component diagrams if you use Gliffy or Visio guess what the little thing he's going to have on it for you know it's going to be called component diagram if I were to go back to use case diagram that you saw with the actor and says use case thing what version of you know is that one doesn't matter anybody else the answer is it's all but that's where it came from this one yeah yeah so yeah one covers so much from the beginning and everything what was added later on in those additional diagrams to get us out to that generative software for rows to generate code base and everything so we have relationship diagrams we had class split diagrams it got insane everything too bloated no we just need the basics just the basics of this thing an artifact would be a physical unit a file gem modules yeah we're on we're on rails and so it's not comfortable just to put some gems up in a component diagram show me how this gem this is what the internationalization gem shows how it works with my home page okay so that's all that gem does 18n some other things in java some other things in php you guys are familiar with it so this is a component diagram and in the uh we have something called uh vendor portal application so if I'm Nike I'm a vendor I've got a place you can come and have your event at if I'm regal theater I've got a place you can have your event at I'm considered a vendor so I will go into the portal into my information one of our key vendors that we've got is regal theaters a lot of people last December for the release of star wars wanted to have their office sales party associated with that so we partnered up with regal because it is really tough to get people on the theater on a monday afternoon or tuesday afternoon the theater is empty so when we show up say hey we've got a deal for you we've got people looking for space that they would love to go to during that time of day and have their business meeting let's hook up and so on the release of star wars we had 92 events across the country all booked at the same time for that release party that's what is going on the vendor portal you can sign up for this thing so you can create you can almost describe what's going on with our software right here so yeah you can go in and create a group form you submit there's a can can can gem anybody familiar with rails that's your authentication that's your authorization that's what allows authorization in gems it's kind of the gem that controls that it used to be called can can gem the first version of it is called can we're all placing bets on what version 4 is going to be I'm saying quad cam group AR model salesforce.com yep that's also part of this google maps where's your venue at I tie into google maps with this too right that's what I'm showing you so I'm using the API and group information out of salesforce you signed up as a vendor with this you have a master service agreement that's also part of the form that I'm submitting right there there's a whole flow about component wise I'm talking APIs here, I'm talking gems I'm talking different components the library diagrams again, sequence class component those are three you need to know that'll get you through a question be familiar with what a use case is you already used stories today same type of thing in that question diagram you have physical view there's a is anybody using a cloud craft cloud craft is used for modeling your AWS infrastructure you can actually have like a three dimensional thing that shows all the components you're using we'll show you a costing how much is costing you each month you can make the entire drawing of your AWS system of cloud craft we've taken cloud craft and we've put that in our crutched and physical model we just boom, take a snippet oh this one's running on EC2 instance for Gemini that's associated, we know where this code is running that's another thing, coming into a large code base where's all this stuff running we've got seven different instances splitting up this application like why are they all there and the guy starts to draw me one of these dash lines I couldn't begin to follow what's going on show me this, now I know where it's at show me a physical view, boom right there and when I just hired an engineer a few weeks ago to come on board he just looked at it I said describe the system for me after reviewing these things he said so we've got seven instances we've got redundancy because they repeat he just went through the whole thing I said how did you know that he looked at me like what are you doing you know I'm here physical diagram, this is again this is what I'm showing for infrastructure so even if you're using your Jenkins instance out on EC2 you've got Jenkins out on EC2 you've also got ZipFile that's uploaded here to our S3 bucket AWS Elastic Beanstalk for my load balancing how it triggers those are all part of your physical deployment diagram let's talk a little bit about how we do on time here so so design patterns this was something that was very popular early years and on that timeline you'd see it start to evolve somewhere in the 80s and then 90s patterns became very popular and then pretty soon as the turn of the century came around Y2K or so we'd start to hear components being used these were all the things we knew about building software and pretty soon as we'd put a bunch of components together and diagrams you'd start to see an entire framework and that was a genesis of where we got jangling and rails and things like that that's how it came about so patterns is what we used to work with and today we still use patterns pretty different way they're very simplified so in software engineering a design pattern is a general reusable solution to a commonly occurring problem in software design design pattern is not a finished design that can be transformed directly in a code rather it is a description or template or how to solve a problem that can be used in many different situations it's this repeatability that's your pattern that occurs in many different places patterns originated as an architectural concept by Christopher Alexander around the late 70s that's where this came about G-O-F Gang of Four some of you guys are familiar with that so this is one of these things again back to earlier years of object-oriented design design patterns they gain a popularity through this book actually called Design Patterns and it's really about making object-oriented software in this kind of reusable type of thing by the so called Gang of Four and so the books authors are Gamma Alme, Johnson and Blitz to say it is yeah those are the Gang of Four this book became very popular and is still referenced today it contains a lot of the software patterns that are in our systems today that quite frankly we don't have to worry about anymore it's baked into the framework but that is how all these systems got put together and so every once in a while I hear somebody reference a Gang of Four pattern and say oh that's kind of interesting somebody understands this and really studied it because there's two arguments that go on with this thing there's supporters why do patterns design patterns can speed up the development process and predictivity by providing tested proven development patterns seems pretty simple in concept critics why not do patterns well they're viewed as workarounds for core features missing in a language framework or sometimes viewed as a lack of good abstraction and a barrier to creativity I keep using the same paradigm am I kind of stuck in that design type of thinking do I necessarily have to think of login as login do I necessarily have to think of login as login how about I just walk up to it and start using somehow or another I'm already good I'm already authenticated I didn't have to log in it's stretching your mind to a different type of thing that's the argument with it I myself, I still like thinking login if I walk up to my keyless car it's a nice product same but I'm still using key okay, Bob I'm certainly not turning it but that's the idea here I think both sides have a good argument with it this here is saying hey productivity, I want to create stuff right now and I'm going to use the components that are available to me this here is somebody saying I want to think outside the box I don't want to get stuck in this thing good arguments for both, yes sir I think for me the bigger argument for patterns is communication if you're all using the same terminology you don't have to go to the white board you can just say what the patterns are oh we're using PubSo they have the systems talking to each other okay, I now know immediately what you mean if you know what the patterns are versus well I'm going to open a socket and we'll send some messages we'll negotiate that's the anti-pattern view because you have to go through that description and it's a good point to really bring up because think about 2001 that's when we had 17 guys getting a ski lodge and come up with the manifesto what was popular at that time patterns this was it those guys were thinking and they did exactly what you were talking about there's a ability to communicate with that fast forward 18 years ooh ooh different kind of thinking going on now it's just we don't think really in terms of so much of that if we do, I hear the term pattern must be abused at some times somebody will call something a pattern it's just a programming paradigm or something you're up either way three pattern types so there's creational patterns, structural patterns behavioral patterns, those are really the main three you need to be familiar with because structural patterns are once created they create the object for you rather than having to instantiate objects directly this gives your program a bit more flexibility in designing which object need to be created for a particular case structural patterns this is getting back to our class and object composition how the inheritance is used behavioral patterns specifically concerned with the communication between objects those are the main three pattern types so creational patterns, structural patterns behavioral patterns, login which kind is that which one would that be you got a behavior it's something I'm interacting with it's going with the system so that's a behavioral pattern so that's a real example how that works architectural review board and you guys have an architectural review board heard of it one person is saying yes an ARB architectural review board we want to align design with the company business goals, strategies and objectives improve the quality of products find the technical design standards policies and principles for the company overall something I started at Capow was an ARB architectural review board when I came in our grooming session went for three hours like my gosh that is crazy having a grooming session what I'm talking about in here as I started listening in there was a lot of discussion about architecture and design going on there was kind of blending grooming with envisioning and there was just a whole melting pot of stuff going on with it let's pull that dialogue out into something as a focus group and let's think about our overall holistic view of system architecture and application architecture you can call CISARC and APARC for short so when we get our architectural review board together we meet once a month internally I've got a few developers that are in it I've got one person for QA I've got one person from DevOps these folks all are interested in architecture it's part of their career roadmap I've worked out with them they want to talk about CISARC and APARC and what we can do to guide the direction of our system design it so we don't have to talk about this just abstractly in some grooming session and agile everything so it gets focused to it but this is not just me putting this together there's actually a format around this saying this is where ARBs became very popular MIT is probably the most popular one and this is the format we follow there's a couple of links to this I'll have in the presentation with some really good MIT ARB guidelines but when I was at I worked for Brightstar as well we also had an architectural review board a lot of companies have these it puts a little bit of focus on this omnipresent but not visible type of thing it's a little bit of focus on this thing so we can start to guide how our design is done and if it works great we also part of this we have an issues log that we're always reviewing too something structurally comes up let's put that in the ARB meeting this month or hey I want to talk about something in C4 model or hey as we come aboard with C-Vent they're using scaled agile framework SAFE that has something I call an architectural runway where you do an enablers you build just enough design consume build design consume that's called architecture runway SAFE and that's one of the things we introduced in the ARB that was new for a lot of folks it's getting back to that principle design just enough not really well spelled out in the original manifesto but certainly in the scaled agile framework we're starting to see that and they want that piece in there the big question mark is what are you doing during all that these are our ARB goals they kind of sound a little corporateish but these are really actually just taken right out of the the MIT portion of their short term goals you still want to create this agile mindset create architectural road maps that support your business long term, prevent framework glow and achieve a platform that can be easily maintained being strategic, being visionary with the thing reduce the long term technical debt that's what we've addressed in our ARB at what point do we need to take on our technical land how come we avoid it? one thing I've noticed is we've started doing this for the past six months put that small design piece in there I've noticed the amount of debt that piles on man is that really shrunk because we're being very strategic and thinking ahead about our design and putting it out there we don't have to just patch work something along just to get to another place right there and say that's out for the sprint because we don't have enough design around okay cool we have to patch work and say we'll catch up on it later and just call the technical debt let's go ahead and build it it just builds up and it just crazes crazes off and this keeps our technology cost in mind too that's a big thing with ARB we have everybody, you guys on AWS some of you running on AWS you've got an AWS bill Google bill what's the other one? Vima I think it is for the healthcare one they get to be pricey they get to be pricey, you can spend easily hundreds of thousands of dollars millions of dollars out there in the cloud but how do you know you're not purchasing too much how do you make sure it's right how do you make sure it's lined up this is one thing that your ARB can do find out Sysarc always be modeling Sysarc it's a key thing because you want to start small or plan big try to boil the ocean focus on quick wins show your results really and often with the end of mind and then create a maturity roadmap and follow it we're talking enterprise architecture and frameworks when you think in terms of enterprise frameworks like cities, think of enterprise architecture as a city portfolio architecture as a street system architecture as a building kind of the architectural continuum that's one way of framing this in terms of that enterprise architecture enterprise architecture is a strategy to minimize IT and business mistakes many competing perspectives approaches art to EA here's the key thing there's really no single agreed upon enterprise architecture standard like we do in APARC APARC we got UML we've got some models out there Sysarc not quite the same way with enterprise architecture so that's a key area you want to focus upon that's why we've got these things called architecture frameworks just like software frameworks there are enterprise architecture frameworks these frameworks help us be productive in creating and managing our designs the main frameworks that you use from we use Togoff I really like Togoff specifically Togoff ADM stands for the open group architectural framework application design model I'll show what that looks like here some folks are familiar with ITIL Zachman was popular in the early 90s or so it's more like a grid, a 12 piece grid and it shows you how you make your decisions based on your enterprise somebody had asked me what this one is this is a department of defense architectural framework this is for software as they write it too so they follow it on framework as well there's a mill spec enterprise architecture and a lot of the older systems even that the missile systems are built in based their software follow this type of enterprise architecture framework so we use Togoff the open group architectural framework we're currently on version 9.1 with this anybody using Togoff is this the first time you've heard of it a lot of this doesn't get the airplay it should it's key because it's the go to framework for enterprise architecture and this group kind of maintains it what you do with this thing and this is how we run it in ARB I start the architecture review board session we've got kind of a simplified version of this a lot of these guys are still kind of new to this so I've taken out a few of these things but we start with the architecture vision I'll have a slide on that so what do we want to work on we have something called current state future state technology vision governance and you can just walk through those and that's what you're reviewing in your architecture review board so you can say here's a current state of the system here's what we need to address here's future state what should we scale to what are we expanding to so you're always reviewing this in every ARB we go through this thing it's called the Togoff 80 and architectural design mark we walk through that every time it makes a big difference too because one of the advantages we've got here is actually coming out of Europe which is the GDPR okay from there with that one yep right there part G Togoff that's where you want to address that standards like that are key so we always keep those in the highlight anytime somebody wants to bring them a new technology introduce it into our stack it goes through this whole thing let's run it through the gamut and see what happens if it makes sense for us is it a sound decision to make that that is it questions I have a bunch of questions this is a very good presentation thank you that's kind of because we we went from water many years ago we went from waterfall into the natural world and we what we ended up doing with our stories is actually making design of required artifacts they would just get scheduled in they'd get pointed and scheduled so we stayed on the one big sprint but you wouldn't maybe consume that artifact until the next the next sprint and I'm wondering is that reasons against that or because you just decided to kind of sound like we'll make our sprint two weeks and you'll front load those tasks in the early part of the sprint and for that reason so we give ourselves some actual runway as you call it in a scaled agile front load so you want to create a runway so we're actually planning the sprint after and so when we got things going on for the very first one we did I put in the design for what needed to be put in and then we started from there and so as we go to the next sprint the design work that we're doing we already did in the previous so that helps with product management to plan what's coming out in the next release and everything that's just the way I kind of decided to do it there I noticed in the one week sprint there wasn't a lot of time to discuss and get our arms around it and the chunks ended up being so small just for where we're at I wanted people to also learn this so it gave some time to adapt to this because this was something kind of quick and given how much points were rolling over each week it became apparent to me we're trying to bite stuff in too large a chunk so we didn't know how to decomposition we didn't know how to decomp stuff that's because we really didn't know how to design we really didn't know how to chunk this up into a visual representation oh here let's just do this put a crutch in around this thing and let's see where that ends up right there find out the dependencies find out what happens and oftentimes the story mapping story mapping has this thing called a backbone in it a backbone gives you this holistic view of things and this is where your stories come out of and you start to see the cards come out of the backbone of things those were just kind of some of the reasons there's no one particular thing but if it's working for your group if you feel that's enough time depends what your deliveries is to be but we've had to split things up but I've gotten away from it I'll tell you that because I don't like having something partially complete because that's only a partial design I'll first ask that we can design a good chunk of it in this sprint let's not start going until we get a good feel of it we'll go into the next sprint and continue on with the design that we pick up and it might be just enough right there let's go ahead and build it at that point then we get a good left hanging in the middle of something where design thinking uh-oh and then there's another requirement that comes in so it may change your mind so it kind of prevented that so that's why I stretched it out a little bit farther so it gave me a little bit more running didn't want to go to three weeks or four weeks but it causes a lot of anxiety for people that are coming off of a one week sprint for one but it also I think two weeks just seems to work just right for what that company was doing as you think when I was at Brightstar we had a three week we started with a four week sprint but there's a lot of people coming off a waterfall too it's like oh my god that's real bad and it's like can't we make it go longer it's like what are you trying to do it's like well I want to get to this like well don't we have enough to go here well yeah okay so yeah this isn't my own judgment on that good question do you have a problem with running to a sprint cycle and really carry over every sprint that I would probably per se but virtually it's about it's never actually over you're on combat I think we're not true fully I don't know if you're tired but isn't everybody? yeah I have people within the sprint do come up if I have something I'll split out into a couple sets of teams we've got one area that's just for what we called project intake and then another area was vendor portal if that team on vendor portal wants to work as a combat because you already know what the work is going to be and you're all confident in your time management as well as what's coming up and what's expected then that's fine to work in it but you're still working in the context of the end release data and things the biggest issue I find with doing the combat really comes down to time management because I find some people will just cry I mean just give me more and they'll go back to the pop give me more, give me more I've also found it's just a perfect way for a slacker to be in there and just oh yeah I did mine and it just depends I've had developers when I first came into engineering I came in as a design engineer working in manufacturing and we had people on the factory foot it was a combat system I'd see people out there taking breaks galore not really getting the work done but yeah I'd see some people out there cranking and running out of parts and stuff so it became a management issue of really can you manage the time to make sure that that's effective in terms of design around combat again for however far we want to go now mind you I don't want you designing for the next couple weeks how far do you want to meter the combat that's going out so think ahead of that so as I work with those guys on the combat piece it's really metering the design you're still thinking in terms of releases you're still thinking in terms of releases so maybe a grouping of a function as you put it together in your story mapping okay I want to take this segment here and I want to offer that how much design do I have on it okay you can still segment it you just don't have this formalized we're going to release on this date you know have a retro and things of that nature so again time management kind of a key piece on that and one of the things I worked with our team on was cover the 7 habits of highly effective very popular series right there the time management tool in there still very popular today core quadrants what is it important, not important, urgent, not urgent you want to work on things that important but not urgent you want to move things that are urgent and important stay out of that that's management by crisis continue to move them in to important but not urgent some folks just really struggle with their time management so just giving them that tool right there prioritize the stories about getting your team together and one might go out to the board and present one viewer and then the other one will come up now is it an architectural or an architect what is the scheme would it be for example developers coming in and taking on some of those responsibilities or is this design work primarily handled by architecture or is it on set work good question it's really a question because where is this architectural role at today what do we call an architect today so when I come in I'd see people that have got that title architect and I'll ask them about crutched in UML toga okay well tell me what architecture is to you and for some of them as we're looking at rails well instead of creating everything we decided to add another structuring here so we can put out our config files into this section so we've changed the overall architecture of how we work with rails and that's architecture I'm not arguing but no so where I start with when I do career planning with folks what is it you want to be I'll pick out the developers and say I'm interested in being an architect and then I'll sit down with them just like what we did here in fact this presentation was the very first one I gave to them and so they just had exploded on things and I said let's just go into some baby steps so let's first start off with doing a sequence diagram so one guy I had who's been there a while he knows a lot of software and his head he's often going to be the one talking so I said just go up to the board can you put a sequence diagram around I'll walk you through it so I'm kind of instructing how to do the sequence diagram how to do the component diagram and then getting this in the classes and what's interesting about it is when we're changing something in the code base he already knows which classes are there he already knows the structure and he's just down and putting it on the board in a language that the rest of the developers can understand so what I'm doing is I'm picking out somebody who has an interest in this discipline so there's some architectural coaching that goes on with it and it doesn't take long it doesn't take long at all and if they're really interested they'll do it and I still have to sub them to get to the board because they're not real confident in a couple of things one is still getting comfortable with this but two trying to figure out the problem itself because man here's this big ball of mud of code man that is a lot to juggle and we've continued to just keep going it's something you're building it's a living thing just like your code base your design is a living thing you're building upon it you're not going to create a moment of day just little pieces and after a year if you look back on this thing collect all those you've got pretty good view what's going on and you've also got better I heard engineering chops with how to diagram something I'm going to be hiring more engineers we're looking at bringing in eight more engineers for our team because we're going to scale the power to fit in the sea level we've got about 1,500 customers we're going to scale to 25,000 one of those customers spent almost as much as all of those 1,500 we have so 25,000 so we've got to scale some people so as they bring people on board that'll be a key piece we'll want to get them to acclimate and everything so that's the key aspect there is to look for individuals that see this as a potential career path or maybe even not that but just show a desire to think a little bit differently in other words you can be a coder you can be an engineer and just kind of encourage that that's what I'm going to say right now a lot of times I think people are comfortable just having everything and to do that without being part of the analysis and how do you be part of the ownership of that product that you're building to understand it it's like the statement of Simon Brauman if I can't visualize visualize it then how on earth am I going to be able to improve it and along those lines at some point you can't have every developer in your barn work at the architectural meetings right so you have to have mechanisms for disseminating what your group comes up with to the masses so to speak and I was curious about I don't know why I say this before last for this group do you put things into motion to make sure that the end source code is somehow linked back to the architecture like is it in the heading this this this PC code was generated based off of this UML model or that sort of thing or in another thing along those lines is if you're programming in a world where you have to conform to specifications like data transmission specification and stuff like that do you include those in your diagrams do you provide a mechanism for actually linking it to the source code that's question number five I'm done those are all good and they're relevant and related to each other because that's an important piece how we manage this what's the tool for this so how we go about it is Jira, that's our main ALM tool application lifecycle management tool we've also got Confluence we're using Gliffy some of the ones that you see up there I did those in Gliffy so after we go to the board I'll take a picture of it then I'll go ahead and enter it into Gliffy by using the UML notation that's in Gliffy and I'll create that into a digitized thing I'm trying to get some guys up to speed where they can do that they're able to draw it up in the whiteboard so we've got to get to where they can use it on Gliffy and he's got to be pretty good with it so that's one step get it into Gliffy now what's this in Gliffy I can tie that into Jira because it's the same platform so I can put a link to the Gliffy diagram in the story I'm looking at reading the story I'll click on the diagram maybe the architect went through and now see how this is designed so it's carried with it same thing with the UX guy his comps are also in the story too there's a sigma for a UX design so we have comps in there so what's being followed in the story is really central in Jira so I made a link to my Gliffy diagrams which has a crutched in it it's got my UX diagrams and if you've got standards in there that's going to be part of the story right up that's in there and I can put a link into something that's probably out in Confluence that I've got linked up and that's how we kind of tie it together I don't know if you guys saw was it two or three two or three weeks ago Atlassian released a product called Gliffy Project can anybody see that announcement this has got to be one of the coolest things I've seen in Atlassian gets it, they understand this gap going on but we'll talk to them I've talked to these engineers and I thought like where are you going with your project it says we're going after design because IBM's going after everybody else and so they came out with Gliffy Project what Gliffy Project is doing is you can take a diagram that you created in Gliffy or a picture that I took of the whiteboard just a JPEG create a hotspot on the diagram or the JPEG that hotspot I can tie to a car, to a story and it's drag and drop right onto the visual right there and so as I've got my use case diagram as I've got my class diagram whatever I'm going to be working with any type of diagram up there I can put a hotspot on that diagram and literally drag the sprint number on top of that thing so what I got there is something to visually tie it together which is kind of cool the way what's really telling about the way that Atlassian did this is when you read the literature you're trying to address the tool for project management and they show this flowchart of how you're managing the project it's a nice little business flowchart it shows how you're dragging your stories over into the project but when you go watch the video that they're promoting this thing with there's the real telling thing, it's only a minute it doesn't show any of it it shows a system architecture diagram system architecture diagram mind you this is a physical view in Ecruchton they took the CISARC diagram and it's got their AWS diagram and showing that as the diagram that they're dragging their sprint stories into and it's pretty cool because my dev ops person is going to be sitting there saying oh jeez, here's my task for what we're building right there and he continues to build up on that diagram for future state for what we identified in the Togo right there and so he's got his diagram, he's got the sprint with all the stories visually tied to the hotspots in the thing project manager can look at this thing too and say oh that's where all that's running at the whole thing ties together like that pretty cool stuff, that's the only AOM tool out there right now that has it where you can couple together visual with the actual assignments on top of it and it carries it through it so I think he's a great project and something I was able to talk my management into saying let's make a pilot on this and this is a thumbs up we're going to give it a shot I'm also trying to push for a backbone too in the story mapping so story mapping, another thing what's the documentation? that's the question, what's the documentation so is it is the documentation a diagram that we created? is the documentation a story that we previously worked on what's tying all this together to where it's not dated and we're going to have to stay up on the maintenance is that the angle when you do your code you can link to the release in the Jenkins, the repository so you can tie right to the repo and see where that's at out of GitHub so it's real, I said Jenkins, but it's GitHub so you can tie in to Git and see what's the code attached to that story that's got that design diagram and this guy maybe the UX portion on there now as time goes on before updating stuff, I can go back to that one I can go back to it if it changes in a big way then I don't want to go back and redo that thing that's fine, I'm just going to go to the most recent and I can still put a link in reference to prior so they're always linked so you can always go back into the hierarchy of the history and that's where we want to see where does this thing originate from? what was the genesis of the thinking that got us to this code base? that's something we don't have becoming this big ball of mud I don't have anything, what made us decide to go this path? as time goes on we start to see the linkages for each one of those things it's the most recent one that's up to date my UX the person that does our UX today he was pretty excited about this Glyphy project because he said, I got components that I reuse all the time and we've got a lot of repetition here I'd love to be able to call those out on this thing so I can find one a new one that is needed and as one becomes obsolete you can start to flag those things right on his actual comps that's the system I would recommend also taking a look at Simon Brown book just enough he also had some good ideas there's more than one way of doing the same anything that avoid going back to what we were doing in Waterfall, that is we made these beautiful diagrams for the past 2-3 months everything and then we got to keep up on this thing because we're not going to touch those things because we're going to write code for those 3 months everything and it's all dated no, it's a living breathing thing the prime tool is what's key JIRA, confluence GET, all these are key things that tie to it so just to be clear is that providing you some like if you're writing in javascript it's giving you a header you can actually plant in that piece of source code that says this is here's your architecture documents that support why this was written this way in the actual code base? it's not in the code it's all related through the album that's right, it's related through your JIRA ticket that you used to create that javascript code so it's a code check in against that ticket so you know all the diffs and you're referencing the ticket in a GIF transaction something like that and you can go back and get REAP on see what was deleted, what was added and that's a great tool too I think the last thing I had a competing product I think it's still out there, it's called FishEye they competed up against the REAP and you could see what was changed but GitHub does all that now but for me it never solved the design down from using JIRA I'm still, I think it's a question you're kind of getting at is the doc just lives in a JIRA ticket so you can never find him again and as soon as you add new features where's it at? Joe didn't you work on this code somewhere over here what was the ticket number? there's the guy who knows all the ticket numbers so there's always the guy you're absolutely right and what you're getting at now is do I keep mentioning story mapping? it's creating that thing called a backbone in story mapping there's a guy named Pat they come up with this thing and you always got to go back there because you'll see where it's at with it that's a product management feature what's product management doing to help you on this too that's the other question they just build a thing doesn't it what to kind of build on that too I worked in like a very large software organization so there's like hundreds of thousands of git repositories and different software artifacts and like I guess how do you, maybe that's where enterprise architecture comes in or is helping keep that we're going to ask, especially if you're a new person part of the first immediate problem is just understanding what are the different software artifacts and which one is relevant to the particular problem that I'm supposed to be solving right now just so I can even begin to discover where documentation is or what I need to know or how it interacts with other artifacts that sounds like to be a pretty good-sized team that came up with that much that's a good-sized engineering development group or is that something that's been accumulated over time yeah I work at so there's like both it's both it's been over time and a good-sized team as well so how are you managing the scrums how are you managing the artifacts and that are you keeping them so as you do your scrums I mentioned scale agile framework there's less there's dad, there's a couple of these others I think scale agile framework because it's using this architectural runway to keep managing it so as you have somebody doing a scrum of scrums out there varying results on that what are the tools being used how are they managing that piece as they're working with product management on the way and as he kind of points out there the only good is what you're going to be getting in that's what it is with all this the real weak spot in here is I don't have good requirements to begin with or they're extremely vague how far am I going to get zero but that's also good too because I'm not going to start building something I don't know enough about it is much more difficult to write software for something that's just generic as opposed to something that's very specific if I know the details then it's a heck of a lot easier to write everything it gets back to the Mona Lisa versus Dagon picture versus Dagon very explicit what is this for you showing everything that's what the diagram is going to get at but managing that whole repository of those documents as you want to call them design documents if you're working with stories where are those coming from is there some type of master document or a BRD business requirements document that product management you're working with and that's kind of coming from there in I'm always curious to see how they're managing that there is a notation if you notice it was on that framework called BPMN business process notation business process modeling notation there's a notation that actually coincides with UML and so that was one of the ways they wanted to tie together UML with product management it's like product management's got its own notation set that ties in and I can marry all this together with this product manager to have taken time for that in common this many fingers it just hasn't been it's a discipline again it's a discipline very real problem and I don't have a quick answer for it one of the other questions I had is I guess some of the friction I always felt when I was kind of studying UML in school a little bit and then later is and maybe it's just like a UML specific problem but a lot of the notation seemed very coupled to like a classical inheritance based like object oriented programming paradigm yeah and as soon as you sort of get outside that mapping the designs actually or translating designs to implementation kind of starts to break down a little bit or even if it even if you can follow through it doesn't really necessarily need to like a clear simple implementation so I'm curious sort of like how that how you would address that how your team is I'm trying to see if I understand how this is being asked of what you saw was something that was coming out of an object oriented nature right what if you're not dealing with an object oriented base let's say it's a functional program like elixir or something working in phoenix frame elixir being a functional type thing how does this stuff work because if everything's based on objects how does that go forward you don't have this notion of classes well what is it that we have a functional program it functions right that's one thing so yeah we can absolutely break this down into functions as well if you don't want to call it a class I took a notation I didn't call it a class I just put it as a function and here's all the things with it so that's how I adjusted it and worked fine so functionally I can see how that's put together all this was a genesis out of as you saw in the timeline from small talk that's how we package stuff up that paradigm that's not the only one out there that's a great example what do you do with something like that you can adapt it it's still a notation you're still trying to convey an idea because again getting back to the very beginning what is your product as an architect provision what it is and you're just trying to communicate that's all the diagram is doing no more just communicate what that is as you can see from all the scribbles on the board we struggle with that so just try to standardize it good question very good question which is going to look like if it's not a function or an idea still how do we go about solving the problem visually capturing it it'll probably be a good opportunity to start another type of modeling language if you're interested give me a call I'll see if we can find some funding for that deal because those guys got really wealthy yeah it started a small team in the group it started playing with the main group of design just a couple of the slides you mentioned people programming out of it just used business terms not really often there and do you work with that at all if you've been exposed to that it sounds like you've been able to explore it a lot DDD and triple DDD whatever you guys said design driven the main driven design and what you were referring to was what we call a conceptual diagram it's before I go into thinking about code before I go into thinking about a system it's getting that thought process of what's the problem I'm trying to solve here because it's a customer or something like that and that's really where our best developers come from it's about solving a problem so I want to be able to speak in that language so if I can get up there and start putting some type of composition or diagram that speaks to business terms and how I kind of arrange it oh yeah, there's a flight, there's a date there's a location well I don't have to say it's flight whatever I want to name the method as the class don't think like that it's getting yourself out into that thing that was one of the challenges I would say that I had with an engineer with this particular company but another one was pulling him out of that he was really heavy in the spring and really thought in every way of that and I said don't reference to that when we're at the business I said just strip it down what does this class mean pretty soon he started kind of really interesting he started kind of thinking of a different name for the class as he was talking about it to the that's how he was kind of translating it into a business term after he got done with all the business he goes like why the heck do we put classes in this, why do they do it this way and you start to see how decoupled this was from the original thinking so you don't want to be reversing it oh I need code to get to my business problem now I want my business problem to work its way to where I can decomposition down into some package into classes, functions or whatever else I try to reverse it everybody talked about it in terms of servers Gemini Apollo they named their servers Minotaur I still hear people reference it oh that's Minotaur what about Minotaur that's a server, that's what a code buys I don't know anything about that I don't know if I'll do respect it's something in this person's mind because they know what's out there on Minotaur that's some instance on an EC2 I don't know anything about it well Minotaur is the front end piece and it's called Gemini these are cute names but it's doing nothing for me from a visual standpoint why not just call it vendor portal why not just call it land portal meaningful names but it's cool when you're this hip start there's just a few of us doing it it's called sponge bob scorpions I don't care it's a goofy thing that's just part of the maturity of getting it there and getting those people to think in terms of I don't think about it from a server perspective I don't think about it from a code perspective it's a function and it really helps a business I must say when we get service tickets and that helps in a big way because somebody is thinking like that right there because it's real tempting to think about where that code is happening I don't think about it, what is that person trying to do because you might end up finding it doesn't that do with the code that's already written that's where it is and it helps with communication with the business too both directions because you're actually using the same nouns if you're not if you're not talking controller, controller, controller then it's nothing to the business at all if you're saying of the user or the portal or whatever it is can, can, can oh that's in can, can, can that's inside, that was hilarious I'm not going to tell you it was a jump that came out about kicking cans and stuff it's just getting out of it but that's okay, that's just part of the iteration curve that's what differentiates how you might have learned something to think in terms of solving a business that's what we look for in a more experienced engineer right yes sir so you mentioned that you use the correction so when in the two weeks sprint you put those together right at the very beginning in the planning meeting or for a couple of days and who's involved in creating those yeah good question who's making the call when to have it too that's your scrum master so scrum master's got to be a little kind of thing so I've had to work with that we scaled our team down to 50 people and the scrum master role is rotating it's not a dedicated person and so people that have also become a scrum master might not necessarily know design I've been asking as an engineering the director here say do we need design on this oh yes, right up front do we need design on this I don't know, do we understand what we've got to do here and then somebody starts thinking about it from the system somebody starts thinking about it from the app well, I'm not sure and I say okay, explain to me what we're going to do very yet, go up to the board start thinking and if it's a deer and they have lights we need design sessions let's play together for that there's not a lot of argument at that point because you can't go up and articulate it even though I may have my most experience in engineering, it's like it's no problem I know exactly how that's going to go we're good for you what about the rest of us as a matter of fact, that person's one that's going to be going up to the board and that's great that person's also growing too because they're mentoring they're showing they're learning this stuff it's a win-win what about the judgment call if I don't have my hand on that if I don't watch that they will go right ahead without design and do the color and everything so it has got to be an intentional thing it's not an eyes-brow momentum oh, Brad wants to do design they understand that that is an investment they've seen the merits I've got two of those guys coming up and saying what I'm doing 12 more points in each front than we did before because we can go farther with it I know the depth of what's going on here we're more efficient because of this there's other stuff coming out I've got a junior developer she's always asking are we going to do a design? I know why they're asking they don't understand this big problem they want that visual there's other people driving so we're on it we're just part of our cadence but getting started that takes some things and you have to have some people that genuinely want to become an art engineer as he got to be familiar with this he kind of said this really is information I kind of like staying in my code base I like doing that piece of it that's fine too, that's cool that's absolutely cool no problem we're a small team so it's like 7 people so it's like bring on QA too because where they got they got our test scripts what's this thing supposed to do how are we doing? we should wrap it up we're good thank you everyone, really appreciate it and thank you for having me a lot of great questions thank you