[MUSIC] If you currently work in the software industry in any capacity, you no doubt understand how complex even some of the smallest scale projects are in their architecture. Indeed, the entire reason that software teams have borrowed the term architecture from the building industry is a direct nod to this complexity where the use of APIs, databases and so forth have led to systems full of internal and external dependencies to function properly. Further complicating this, is that a lot of enterprises and even small and medium businesses acquire a vendor software packages and typically build additional complexity into the software to meet their business needs. And what you end up with is a monolith. Monoliths are a big reason why most organizations do not have loosely coupled architectures. In this video, we're going to discuss utilizing a loosely coupled architecture to tackle the challenges organizations face in this area. This is a topic about which Jez Humble and other DevOps thought leaders are especially passionate. After watching this video, you'll be able to define and explain what is meant by a loosely coupled architecture as well as why it's important to a successful and high performing organization. Let's get going. Okay, so what do I mean by coupling? Well, when we discuss software architecture, coupling refers to how much various mechanisms of a system depend on one another. And coupling can either be considered tight or loose. Tightly coupled architectures mean that the various components in a piece of software are heavily reliant upon one another. They require highly detailed knowledge of other cooperating components often relying upon some programming to tie them together in order to perform their purpose. This is a situation where one change to one part of the system would require changes to other components throughout the system to work properly due to a high level of integration. For example, in retail, often the point of sale system is tightly coupled to other systems. Because traditionally, POS vendors have not created loosely coupled architectures. They are not typically API or service-based architectures. So in order to meet the business needs, often organizations require integration to other systems like the customer data source or the HR system to load employee data for capturing commission-based sales. All of this, in my experience, has been tightly coupled. And when organizations are on a digital transformation journey and trying to optimize for speed, having a tightly coupled architecture is one of the main limiting factors. So the opposite of this, of course, is loosely coupled architecture. This means that various components in a system are appropriately isolated. Thus, they can be modified and tested independently. While the various components definitely collaborate to perform functions and send messages to one another, they just do it in such a way that mitigates impacting the operation of other components. This is especially useful in organizations adopting DevOps practices. Because it means that changes can be implemented more readily without worrying about impacting some other component. Switching the thinking about design and development to be more about data flow and how we can design our systems to be asynchronous instead of synchronous. Where you're waiting on data from another system is a critical component of this new way of thinking. So one team that spends most of their time working on and improving one component, largely won't affect some other team working on a different component. The idea here, is that teams should be able to test and deploy their code independent of other teams. Again, it's not to suggest that collaboration isn't important. But if you can design your systems and your architecture to enable the autonomy for teams, then that generally results in a higher performing team and an increased time to market for changes. Sometimes it can be challenging to explain the benefits of moving to a loosely coupled architecture. Often, it can feel like breaking down functionality into smaller components can be perceived as a means to avoid collaboration and sub-optimizing based on traditional mechanisms of delivery. Usually you're in situations where you have large integrated test environments and large deployments. Benefits of this approach include the ability to scale horizontally. Testing is streamlined, following a data flow approach which allows for speed and agility. Let me show you some examples from my own experience. As organizations grow, and more time goes by, generally, there are more and more dependencies amongst teams. For example, most of the initiatives at all three organizations that I've worked at require more than five teams to actually deliver against any particular initiative. At Nordstrom, we were rewriting our commerce stack in a loosely coupled way. Prior to that approach, most feature requests required five or more teams and months of development. As we started to build out smaller components, we were able to isolate functionality, test, and deploy in a more streamlined way. We started with our outfit functionality on the website. Anytime we made updates to our browse and checkout flow, we had to test to make sure we didn't break the outfit experience. When we took this new approach, we moved the business logic for the outfit creation into a service-based architecture. And isolated the functionality so we could deploy it independently. We also moved it to the cloud. This allowed us to make changes more frequently and ultimately prepared us for the next component we loosely coupled, the product page. At Starbucks a lot of functionality was tightly coupled to the point of sale or POS software. This was due to years and years of building functionality into the POS because the architecture didn't support a loosely coupled approach. When we started to build the commerce platform in the cloud, we began extracting functionality out of the POS and moving it to the cloud and APIs. One example was loyalty functionality. Most of the rules for applying rewards happened in POS. We decided to move that functionality out of the POS and broke it down into components that can be called and leveraged independently. It also allowed us to scale the rules across all customer touch points. What I found is that, a lot of organizations are really good at identifying dependencies and managing those dependencies, usually that is through an individual. You should assign somebody to track and manage the dependencies in a given project. What I haven't seen as much though in my work is a reduction of those dependencies. So when you know that you're going to require another team to deliver, an option would be to build an API, or a service contract, that allows the team to be autonomous the next time they need to deliver something instead of needing another team again. Of course, DevOps is all about better collaboration between teams and this isn't intended to suggest teams shouldn't work together. The goal of a loosely coupled architecture is to ensure that the available communication bandwidth isn't overwhelmed by fine-grained decision-making at the implementation level. So we can instead use that bandwidth for discussing higher-level shared goals and how to achieve them.
