 So many people, it's wonderful to have you all here. This is great. What I want to talk today is about COTS software in a reactive architecture. So COTS, if you're not familiar with the term, is commercial off-the-shelf software. And oftentimes that stands really kind of in stark contrast to what we're trying to do with a reactive system. And so I think it makes for a really, really interesting topic. Love to get all of your input as we go through this. A little bit about myself. I'm old. I've been in the industry for about 30 years. What I want to focus on really quickly here is, I was introduced to Scala and NACA probably about eight, nine years ago. And I did that as I was working on a machine learning platform, a little startup where we were trying to really make machine learning more accessible to software professionals. Technical people. And we came across a platform called Spark. Some of you may have heard of it. It did some really, really interesting things that we were struggling with at the time. And so we started looking into how they were doing what they were actually doing. We came across Scala and NACA as part of that study. And so we based our system using those same technologies. So that's how I came to learn about Scala and NACA. Reactive architecture came later in the game, actually. I moved from that company to another company where I was supporting a large e-commerce system. We were using some commercial software to do the e-commerce platform. And we ran into some particular scale problems. So when we talk about scale, we are doing about 10 digits in revenue annually. So a very big company across about 25 countries worldwide. Each of those countries, each of those different markets had subtly different business rules that we needed to implement against. All of that revenue was done against an e-commerce engine, right? So we were trying to scale the system to meet our customer's needs. And our loads were really fairly predictable throughout the year except for when it came time to have a product launch or a particular sale event. And the load that would come into the systems would absolutely crush our systems in play, right? And so we were trying to figure out how to scale this. I called LightBend and said, I want you to come teach us about microservices. I think that's how we're going to fix this problem that we have with our COTS implementation. They put me in touch with Yopworks of all places. And so we started learning about reactive architectures and how to implement that. And so really this is kind of a lessons learned presentation about what we did as we were trying to implement those ideas into our enterprise architecture. So the big question. We learned all about reactive architectures. We learned about how great it was. It felt like it fit many of the check boxes that we were trying to hit as we were trying to scale this enterprise. But how do you do that when the core technologies in play are not reactive themselves? It's a really, really tricky problem. And so that's what I began. I've spent a lot of time thinking about it. So when you look at these enterprises, nobody sets out to build a Rube Goldberg machine. I think many of you are familiar with this. It's this cartoonist that has this idea of there's a very simple problem, but he depicts ridiculously complex ways to solve that problem. I think this resembles a lot of ways, in a lot of cases, what enterprises eventually end up doing. This is not what they set up to build. They want to solve their business problems really elegantly and very, very carefully. But they end up with something that's very, very complex and not really meeting all of their business needs. Happens very suddenly. It doesn't, they don't set out on purpose to build all of this complexity. It's instead it happens piece by piece. We've outgrown our warehouse management system. We need to upgrade it. We need to replace it. My neighbor's company just got hacked so we need to implement an identity provider. We have too many websites across too many platforms. We need to consolidate to a single content management system. All of these reasons come together while you acquire a piece of technology. You bring it into your enterprise and eventually it ends up with all of these really complex connections and really challenging problem to try to solve. Let's talk about these systems really quickly. The reality of most caught systems is they are built as monoliths. They have to make certain assumptions about the world that they live in. They have to, primarily the assumption is that they have to stand by themselves. So they can make no, they can't assume that they are working with a particular software provider that this particular database is going to be in play. They have to have all of the data and all of the processes to satisfy their needs all contained within their system. And so it becomes very monolithic and they provide a very thin layer for how other systems would interact with it because they know they're gonna have to play in the space but they can't make any of those assumptions. So no concessions are made for their data or for their processes and we integrate them with whatever we have available. When we do that, we bend the business logic to adapt to the new systems process. They are the experts after all. That's why we bought them. That's why we acquired them. We adopt the language of the new system into our business and to our technical processes. Working with enterprises as I've done over the years, it's crazy how often a retired system for many years back, the language of that system, this transport, that data, this field gets carried into the language. Long after it's retired, it corrupts the language of both the business and the technical systems, right? So there's a long legacy that follows with it. The reality is is when we integrate systems in this way, what we're doing is we're just building a monolith of monoliths. So each individual component is a monolith itself but the way that we integrate these systems together, we're constructing a new monolith using the individual part pieces which are monoliths themselves to build our enterprise. So when you wiggle one piece, when you try to pull one piece out, adjust it, make changes, it's going to affect the rest of the other pieces in the enterprise in very unappealing ways. It makes it very difficult for you to continue to grow and scale the enterprise. When you do that, what could possibly go wrong? I don't wanna spend a ton of time talking about all of the different ways that things go sideways when you are working with a monolith and monolith but I think it's worthwhile to spend a little bit of time talking about the consequences that you might run into. First is the delivery of velocity suffers. We heard this morning in keynotes where we're trying to talk about delivery of business value as the key thing that we're all after but we're always stopped or hindered in that, worried about the technical detail of all of the part pieces that we have to manage. When you have these individual technology teams, so inevitably organization gets constructed not based on business function but really based on technology silo. So you have your e-commerce team that's built around Magento, you have your database, your DBA team, you have your warehouse management team, they're all focused around the technology and not necessarily around the business process. And so there's coherency delay as you try to get anything done inside of the business. The business would like to do a particular introduce a new feature or build out a new application for your customers but it has to touch all of these different things to integrate across all of those teams and get anything done is really, really difficult. There's all of the incidental complexity that goes into play and no longer are you talking about the business process but you're talking about, I need to convert this JSON file to ISO standard 3476. I've got to handle this data format, I need to convert to that database. You start talking about all of this incidental complexity and not focusing on the business problem at hand. And then of course, you have problems with recruiting and retention and also onboarding new people because everybody's focused around their individual monolith and not necessarily around the business problem. So that leads to other problems of course. So even simple tasks like staying current with the existing platforms becomes really difficult. Again, because there's all of these individual dependencies between the systems. Again, you can't wiggle one piece without affecting everything else in the enterprise. So it becomes a really delicate dance. Juggling many things, you're expected that none of them are going to drop, trying to maintain status quo while being expected to deliver new things along the way. So simple tasks, I need to upgrade my platform, I need to migrate my database. Those things that should be very straightforward become incredibly complex and have a lot of delays built into those tasks. Boundaries become unclear. So each platform in the monolith is going to maintain its own data, its own processes. As those systems start to work together, they may be clear at the beginning when you first integrated the platform, but over time those boundaries start to become less and less clear. Your ERP has to know about all of the customers and all of the orders and all of the products, but so does your e-commerce system and so does your content management platform. So when you start talking about trying to change critical business data, you have to now think about all of the different places that this data lives and there's no real clear boundary who is the authoritative master of which piece of data in order for you to accomplish those tasks. So again, things become really, really complex over time. Because you're coupled in time, cascading failure becomes a real problem. So you're all familiar with the story of the Titanic. It crashes into an iceberg that pulls rivets off of the front of the hull. That allows water to start filling the bulkheads which were meant to keep the ship from sinking, by the way, right? But as that those four bulkheads fill, it pulls the nose of the boat down a little bit further. They didn't build the bulkheads all the way to the top of the deck. And so water cascades into the next bulkhead and it eventually starts filling more and more back. It lifts the back of the boat up. It wasn't meant to handle that kind of weight. It breaks the spine of the boat in half and it goes crashing down to the bottom of the ocean. Do you see that at all in your enterprise systems? One little failure leads to the next failure. It leads to the next failure that causes all kinds of mayhem and chaos. And you're on, like we are discussing this morning, you're dealing with support calls on the weekends. Your family's unhappy with you. The business is unhappy with you, right? So we run into these really challenging problems. You have a lack of transparency. So we are clear on what goes into a system. We see those inputs. Bunch of magic happens. And then you see the outputs on the other side. When you're building the monolith of monoliths, all we're doing is we're chaining these black boxes together. You see the inputs and outputs from one system to the next. We very carefully, carefully orchestrate how they communicate back and forth one to another. But you're just stacking those things seriously one after the other. So what that leads to is what I call radiator cap and lug nut problems. It's all of those things combined. The problem is, is I tighten the lug nuts on my car and the radiator cap blows off. We have no idea why. There's no apparent connection between these two things, but the fact of the matter is, is I did this thing and that other thing happened and we have to spend inordinate amounts of time trying to figure out why. We are on the call with, we're looking at all of the integration points between our systems. We're on the phone with vendors. We're trying to figure out really what's going on. And you're just stuck, broke down on the side of the road, wondering what life choices led you to this particular point. So a summary, these, it feels a little bit like a Jeff Fox worthy slide, right? You might be a redneck if. You might have a monolith of monolith if. All of these things come up to add a couple more to the list, transitive dependencies. Systems include different libraries, but maybe different versions of the same library. And so to, when you get into operations, those things really start to conflict with one another. Things crash, again, cascading failures, corruption of language we talked about. So why do we do it? Why do we paint ourselves into these corners? It's pretty simple. We want to buy a commodity rather than to maintain something that's already readily available. We want to rely on the experts rather than ourselves. This e-commerce platform, they have thousands of customers that are deployed across, all across the world. We want to borrow that expertise. We want to buy that expertise rather than try to build it in-house. We want to have a vendor on the hook for support. Something goes wrong. We want to be able to reach out to that vendor to fix it. And when you look at it through this lens, it actually makes a lot of sense. We want to realize the value of those systems as quickly as we can. So we integrate it in the easiest way. But we end up building that Rube Goldberg machine that we looked at in the beginning. What if the problem is not really the monoliths themselves? What if the problem is really the way that we integrate the system? What if we're going about that process the wrong way? And that's what I want to focus on primarily. The key principle in a reactive architecture, we talk about resiliency and elasticity and responsiveness, message-driven. Those are really the characteristics of a system that we want to go build. But the key thing here is we want to have isolation between the components. So when planning for a new integration into the enterprise, we consider all of the integration points. We look at how it affects other systems in the enterprise. We think through all of those parts and pieces. We don't necessarily think about the isolation that we need in order to build a reactive architecture. There's other issues. Well, the monoliths themselves are really built really well to mitigate isolation for state and space. They're expected to be deployed by themselves. They're expected to run on separate hardware. They have their own databases. They have their own systems that they have to manage. So you're isolated well in those ways, but time and failure are often the challenges. We talked about it a little bit earlier. Because they are monoliths, they often have to keep duplicate data. And you're not sure which system is actually the authoritative master. We've had cases, for example, in an e-commerce system where I change a price. We expect that to go into effect, but six hours later that price gets overwritten because another system that was mastering that data pushes the data across and not everybody on the team is familiar with that. So there's all those kinds of problems that you run into. So you're left with question now what? Mark Seralius long, long, long time ago famously said the impediment to action advances action. What stands in the way becomes a way. There's a story about an old king who places a giant boulder in the middle of the road. And he does that on purpose because he wants to see what people in his kingdom are going to do. So he hides himself on the side of the road to watch. And what he sees was really kind of disappointing to him. Some people came and they saw the rock, they just dropped their head, they turned around and they walked away. Other people screamed and hollered and beat on the rock and did all kinds of unproductive things. After watching for quite some time, he's about ready to pack up but a vendor walks up pulling a cart of veggies, they stop at the rock and have, instead of having the usual reactions, they study the rock, they dig under the rock, they push on the rock, they climb on top of the rock, they do all kinds of things that are really different than what everybody else did. Looking off to the side, they see a giant branch that was broken off by the rock. And so they grab that, they push it under the rock, they start trying to use it as a lever. Several different positions, finally the rock rolls away. Being pretty pleased with themselves, they turn around to go back to their cart but they look where the rock was and there was a purse on the ground. They pick it up, it's a little bit heavy. It's because it was filled with gold coins and in the gold coins, there was also a note from the king saying the contents of this purse are for the person who removes the boulder and I would like to invite you to my court to have a conversation about how we can improve things within the kingdom. So once again, the impediment to action advances action, what stands in the way becomes the way. So when we talk about building a reactive architecture with components that are not necessarily reactive, I think we need to look at our systems differently and how we integrate them. So what do we do? The goals, we want to enable our enterprise to be more responsive, resilient and elastic. That's what we're trying to accomplish. We want to accelerate delivery of velocity. We've seen those impediments, we've talked about those before. We want to leverage our IT investments and not replace them. This is where I think a lot of reactive projects go a little bit askew because the natural inclination is I want to replace these systems, I don't necessarily want to, I want to build them myself rather than leveraging the investments the company has already made and that gets in our way. We want to reduce the impact of vendor lock-in, we want to decouple the model of the modelist. So how do we go about that? Few suggestions, far from comprehensive, would love to talk with all of you about your collective experience but this is what I found to be useful. First off is you do the domain modeling. We use DDD in our practice, there's other things that you could use but the key here is you really want this to be a business-driven activity. You don't want to talk about the technology, you don't want to talk the systems that lie underneath. You want to talk about the business process and the business concepts and build a domain model that matches those ideas. You want to establish a ubiquitous language as you're doing this. This activity by itself is incredibly valuable. Don't underestimate this step and I would say don't start your process without taking this step. Again, divorce yourself from the technology for a moment, engage with your business partners, let them drive this conversation and really understand what they would like to accomplish. Build a model based on that. Now that you have that model in place, now that you understand better what the business processes are, as technologists we like to think about the business process of enrolling a customer, for example. I need to talk to this system and I need to propagate the data to that place and I need to update this, right? We think about it in terms of systems, we don't think about it in terms of business process. So once you have that business model in place, then you map that onto your technical landscape. You're going to discover all kinds of crazy things. You're going to understand better who masters which data. That's really, really important to understand. It clears up some of those boundaries that we were talking about earlier as we were trying to evolve the systems. Think about how applications need to access that model, not access the technology, but access the model. So what interfaces are they going to need in order to provide the applications that drive your business? You'll start to think about interactions between systems. So no longer are we talking about the direct interfaces that are provided by the vendor. You want to talk about the interfaces based on the model, the business process, rather than the individual systems and who's master of which data in that process. So you're thinking ports and adapters or hexagonal architecture, onion architecture. You're thinking about building this abstraction layer around your caught systems. You want to build that abstraction in a reactive way, not in a way that the vendor would have you do it, not the easy way, so to speak. Think about the data that you're going to need to project to your customers. Next, you want to build iteratively. So now you've got this business model. You understand how that maps to your technology domain. Now you want to start very small. You want to pick a proof of value with very narrow scope. You want to build that directly. So maybe it's a very simple user interface that notifies them of a particular event. Maybe it is allowing the customer to be able to construct a URL that's going to allow them to interact with your business in a different way. Maybe it's, there's 15 different ways that you could look at, but you're looking for those slices of functionality that are going to really catch the eyes and attention of your business. So you can probably identify these just by looking at the particular requests that they have, the new features that your business is asking for. You identify those pieces. You don't try to build the entire model. You just take that small little slice. The next suggestion would be build alongside don't replace. So you want to be able to build a small sliver of technology and you want to allow the system to continue to operate as it does today. Let it make a call the way it does, but then after that, immediately after that call, if you're thinking of code sequentially, you're going to call this new system that you are putting in place so that you can see real time data, production scale, all of the complexity of production systems, and you can audit the results afterwards so you can have very, very high confidence in the system that you're building and then gather data around the new system that you're putting in place. Very low risk way to get things moving forward. And then as you develop confidence in that new system and as leadership in your business begins to see the value of these systems, next you're going to start talking about how you might rewire other parts of your business in order to be able to do the same kinds of things. So this is a very iterative, very slow, very deliberate approach to how you're going to build a reactive architecture with components that are not reactive themselves. Summary again, do the modeling. I can't overemphasize this enough. We spend too much time talking about the technology and not enough time understanding the business. The exercise of engaging your business and understanding it in this way will build a lot of relationships that will allow you to continue forward and it will build a lot of trust to help your future efforts. Determine how the model maps to your enterprise, build the APIs and adapters that allows you to communicate back and forth between your applications and between systems and then eventually you start to change your clients to use those adapters. A few other additional ideas. Think about how to articulate the ROI of the things that you're building. That's going to speak to your business partners dramatically. So as you're building these things, think about how to capture the dollars and cents of what you're doing to allow them to have more conversation and then also enlist internal experts. As you pitch these ideas, your leadership is going to be looking to other people in the enterprise and saying, hey, Bob came to me and talked to me about these crazy ideas. Tell me what you think about them. Should we do them more? So enlist those experts to further your cause. That can happen simultaneously while you're building. Challenges. Aren't you making things more complex? Aren't you replacing things that we've already bought? Be prepared to think through some of these questions as you're addressing, as you're trying to advance these ideas. Anticipate them and think about how you might answer them. Finally, the reality of doing this is you're going to end up building more software than what your business may be comfortable with. They're used to building small little adapters or small little interfaces that integrate system to system. We're talking about a more comprehensive approach that's thinking about things abstractly around a business process and then abstracting the technologies underneath. Again, that ports an adapter's kind of view. So you're going to be building more than they're comfortable with and that's going to require time and investment. Be patient with the process. Allow your business partners to come along with you for the journey, build confidence as you go, and I think that you will find that you'll be very successful. So a shameless plug. If this is interesting at all, the last presentation of the day, we're going to be talking about reactive fundamentals, and we're going to be going through some of the things that you may encounter, some of the concepts in a reactive architecture that's very difficult for people to grasp and understand. That's more of a conversation more than a presentation. So I want to solicit ideas from you, what you've seen as you've talked to people about reactive architecture and how you go in about solving them. Let's see what worked and what didn't work. And I hope that we can do that in a way that's fun and interactive and provides memorable learning experiences for everybody involved. With that, I would love to continue the conversation with all of you. Please stop by our booth outside, look for the people in the bright blue t-shirts. There's links for you to be able to get to all things about Yopworks. We love talking about this stuff. We would dearly appreciate the conversation. More than anything, we want to learn from one another and help advance what we can do and how we can change the industry. Thank you. Look forward to talking to you throughout the rest of the conference.