The No-Code Playbook: Application Matrix

JASON MILLER: Welcome to Creatio's No-Сode Playbook podcast, where we discuss insights, tips, and success stories on how to leverage the no-code approach to transform business and delivery applications of any complexity. I'm your host, Jason Miller, a Head of Pre-Sales at Creatio Americas. Today we're continuing our conversation with Burley Kawasaki, Founder of Tachyon Solutions and Co-author of the No-Code Playbook. Burley, welcome back. 

BURLEY KAWASAKI: Jason, happy to be here. 

JASON MILLER: So, in our first discussion, we discussed the early parts of the Playbook. We did the intro to no-code. We talked about some new terms like the no-code creator or citizen developer. And we talked about how no-code has risen in popularity over the last several years and why now is the right time to write the book. We're going to continue that discussion. We’ll discuss more profound topics you and Katherine wrote about in the book. And we're going to pick up somewhere in the Chapter 8 area, talking about Options Analysis. But before we get there, I want to make a couple of distinctions. Two things that you talk about in the No-Code Playbook. The first is picking a Delivery Model, and then we're going to an Options Analysis about what system to implement. So, when talking about early in the book, you talked about picking a Delivery Model and developing the Center of Excellence. What were some things you were thinking about and helping you design the matrix you've got in the book around picking the suitable delivery model? 

BURLEY KAWASAKI: As we were writing the book, the Application Matrix emerged as a concept, flashing out the methodology. We wanted to keep the methodology lightweight and simple for simpler apps. But we knew that the enterprise wrestled with this range of complexity. As you got into more complex mission-critical business processes or more regulated industries, you needed to build more robustness into the methodology. And we should have emerged. There was a moment when you really couldn’t have a sized fits methodology that applies equally to both the simple as well as the more complex so-to-use cases and scenarios. And so we needed to have a way to scale it. And this notion of the Application Matrix emerged, which was can you find a way to assess the complexity of your application? And we ultimately ended up picking sort of three dimensions: there's Business complexity, Government complexity, and Technical complexity. If you sort of score grade, you know that the app in the use case you're trying to address would help decide how much of the process to use and scale the organization. And again, that wasn't in the earliest stages of some of the thinking, but it emerged because we realized we had to if this was going to be scalable up and down for a customer. 

JASON MILLER: So, when you talk about those three different areas of complexity - Business complexity, Governance complexity, and Technical complexity - you're also talking about different groups within the business and business processes. So, considering how complex or convoluted the business processes are, we could have a whole other discussion around unwinding and optimizing business processes. But that focuses on business users. When you talk about Technical Complexity, that may be something that aligns with data location integrations. It could also align with the number of systems within an overall architecture. Then there's Governance Complexity, which revolves around how you will maintain things. Did you weigh those any differently or think about all of those things as equal weight when you put together the Application Matrix? 

BURLEY KAWASAKI: As you pointed out, it starts to get into who needs to be involved, and that's more important than waiting. Because all of the complexity is important and requires different skill sets, it’s just that the skill sets in where they sit inside your organization will vary. We think about Business complexity. Many complexities run the business process or use cases, and how that may vary by region or department. A lot of that is complex, but it typically sits inside the business. And so I would argue that the business function or the business group sponsoring this no-code application probably has a lot of that knowledge in-house. And so we have this concept of a DIY model where the business team can take on a lot of this because they understand that, and they're in many ways the best ones to make sure they're meeting the needs of the process or the business. When getting into the technical complexity, there are a lot of technologies and nuances about systems of record that you're integrating with or scale of user transact. There are things there that do require many cases some amount of technical knowledge and may require developers. And so we had those notions when Gartner talked about and coined the term fusion teams, a combination of the business and the technology working together. There are different organizational models. Sometimes, they're embedded inside the business themselves. You have to develop a brand loan. In other cases, it's more of a matrix where the development in IT may have a dotted-line person that works for the project. So, I'm not making a statement, but it's a combined set of skills and knowledge between development and business that's the fusion team. Then there's a third one that we called out: trying to make sure that the broadest set of views around the process and the methods get applied. And that's around the Center of Excellence model, which helps support many of the more complex governance needs, as you point out. It might be extern governance, might be internal governance. Also, the whole notion, one of the concepts we talk a lot about, is around component reuse and composability. That's a key function that the CoE can enable and play, so it's looking more broadly than just that single project. But how do we anticipate certain parts of this application, creating reusable components that may be used by other teams or vice versa? You’re using components that may have been built by their teams, so there's a collaboration in a reuse function of the play. So those three sorts of organizational models – the DIY, fusion team, and Center of Excellence have important talent that is needed. And they typically sit in different parts of the organization. And so we talk about how you diagnose. Do you need them? That’s the first question, and that's the Application Matrix’s goal. And then the second part is how you organize and bring them together to help ensure that your project is ultimately successful. 

JASON MILLER: Yeah, and for those still uninitiated and who haven't had a chance to read the Playbook yet. The idea differs from putting together a multi-talented, multi-dimensional Scrum team. But the idea is really around understanding when you need, like you said, understand when you need to bring those folks together based upon certain characteristics that you talk about in the book. 

BURLEY KAWASAKI: I was going to say that over time, the process matures. I don't think it's uncommon to see that the processes get more sophisticated and more complex. But the goal is to not overburden the simple projects from being able to be still very nimble and lightweight. And so just because you have an enterprise-wide view, a CoE, and lots of governance don’t mean every project needs to go through that. So it's important you know a lot of this isn't just about scaling up, but it's about scaling down so that your small projects again can be fast and can be just as nimble as they might be if they were just the first project you were doing. 

JASON MILLER: That’s one of the biggest value props I always talk to folks about. When it comes to no-code, you can have a small enterprise scale for some of these small use cases. These small use cases often sat in the backlog because there wasn't enough business value to justify investment in the I and the developer. So, I think that's a good point, and we'll leave that there. But the next topic I want to discuss is an area that you talk about, which is Options Analysis, and that's chapter 8 in the book. Options Analysis is not about who will deliver but what we should do or what systems we should use from a platform and solution standpoint. In the book, you talk about three areas: packaged applications, custom development, and no-code platforms. So, can you talk to us a little bit about why you think certain flexibility is not there in packaged applications that are needed? Why may that take you towards no-code or vice? So, why would you go with no-code versus custom app development? I think that's a burning question that many folks are still asking themselves. 

BURLEY KAWASAKI: We’ve become accustomed to this notion of buy versus build. You have those two options. If you want speed, you want to have the max amount of functionality out of the box – you buy from package software a SaaS application for virtually every business survey function. And then, on the other side, if you want something unique that differentiates your business process or that is adapted to the specific operating procedures, you can custom-build. And so those are the two ends of the spectrum. And I think over time, people used to buy versus build. They realize that there's not necessarily a perfect fit sometimes. Because you don't want to build from scratch, partly because you don't want to spend all the time and effort it takes to build the basics of functionality, but also the port and maintenance and updates. So people are aware of the challenges when you build from scratch. But then they also want to be able to figure it out and be very agile in terms of the way that they adapt the functionality in the process and use it as a differentiator for their business. And so they want some middle ground. And I think no-code can be and is that middle ground for many companies where it gives them the speed and time to market advantages out of the box provides, but it still gives them the flexibility of customization. And in particular, when you think about the no-code that comes with, increasingly, this notion many vendors have about different app templates, you may be able to go out to a marketplace. You can find templates that are starting point and preconfigured four different functional or vertical business processes. This is a great way to get many of the benefits out of the box but still maintain the adaptability customization configuration benefits of no-code. So, I would say it's been this nice middle ground that, for many companies, hit the so middle between those two opposing forces sometimes, and I think that's partly why it's been so popular. 

JASON MILLER: You hit on one big point that many people miss many times. That no-code probably drives the most flexibility. The ability to bring these composable applications or even down to a composable architecture that you can replicate easily and deploy quickly goes a lot of the rapid deployment methodology. It helps you accelerate, getting things to market so fast, to start and finish faster, obviously. That drives a much faster beginning to your cycle. This typically brings down your total cost of ownership as well you're spending less time or professional service dollars with external firms helping build those things out. I want to shift topics and go into the book’s Go-Live section. And you've got five chapters in there that talk about everything from prototyping to MVP, putting it in feedback loops so that you're collecting feedback from the users and making incremental daily changes to help improve processes and make better use of the application and the governance checks. Talk to us about how you think about that first release cycle, that prototyping to go live and to get that MVP defined, and how you roll that out way that brings business value right off the bat. 

BURLEY KAWASAKI: I had quotes highlighted in each of the chapters. Jason and I were talking before the show about one of his favorite quotes, which is one of mine. The quote from Mario Andretti, “If everything seems under control, you're not going fast enough.” And I would say this is the heart and the soul of this lifecycle stage. You will feel like things are moving very rapidly because they are, and that's the power of this go-live approach. You're not trying to strive for perfection. And many times, people, especially those used to traditional software cycles that are long and full of uncertainty, perhaps in terms of how frequently you may get features delivered from development or IT. There is a natural instinct, I think, to strive for perfection in every last requirement. Because it may be a while before you get another release, jam it all in while you can. This is counter to this notion of everyday delivery in trying to unlock value rapidly, get feedback, identify enhancements, and keep adding those in. And once you make this shift and it's not a shift only for the team that is building the app, but it's a shift for the end users. Because when they realized that, I put in my request this morning, and it showed up on the app this afternoon or the next day. Then they start relaxing a little bit, and instead of striving for perfection, which you will never get to as a singular release, but you can get to perfection over time. And so that encompasses both the prototype-to-MVP, which is about how you break down and decompose things into small units of value that you can very rapidly iterate and deliver or have feedback that you can get immediately. And we talk in the Playbook about mechanisms in ways to gather feedback. Sometimes you have to invest a little bit in terms of process and tooling to make sure you can get as much feedback as you want. You don't want just to let people shoot you emails and know the squeaky wheel it's the grease. You want a structured way of collecting feedback and getting the speed back. Still, once you get a proper loop that allows you to process feedback from your stakeholders continuously from end users, and you take full advantage of the speed and rapid ability to introduce small use cases into the application, then that sets up this continuous flywheel approach as opposed to waiting for big releases. 

JASON MILLER: In this section of the book, you're talking about governance checks and making sure not of just having those feedback loops but making sure that you've got the right, you know, eyes on the product, you've got the right people in the fusion team, thinking about what governance needs to apply, thinking about criticality and severity. The standard organizational risk models that you think about. Talk to us a little bit about the governance check process. Is it different using no-code than it is in the traditional software development life cycle? 

BURLEY KAWASAKI: This is an important topic. One of the biggest fears that IT certainly has is the classic shadow IT concern. If I just let people start building apps and they're not trained and not following the right process compliance, bad things will happen. And there's a risk or part of truth in that. But I would argue that that will happen regardless of whether people try to go crazy. You actually want them to have a standard toolbox, you want them to have a standard process, and you want to have some guidance that helps steer them in ways that will help ensure your ability to stay compliant. And so rather a just let your business teams go off and hand select point solutions here and apps there and this and that, which will, I think, potentially create a lot of security or governance issues down the stream, having a validated, proven and tested standard no-code platform is a way to steer the business to do the right thing ultimately. Getting the right underlying process and tools in place is the first step. And that's a one-time effort to make sure that's in place from a no-code platform and beyond that. Not every app will necessarily warrant going through the entire process. Some may not have sensitive data. Or some may be in areas that need to be covered or regulated by the same level of governance. And so, for those who want to make sure they still have the freedom to move quickly. But for those with sensitive data or who may be covered by a certain industry regulation or certification checklist, make sure those follow the process. The whole notion of go-live and moving as fast as you can do not give you a pass for following the governance checks, but it knows to know which is need to and then providing as much as possible a checklist and reusable framework so that the teams can efficiently perform the governance checks as opposed to having to figure it out on their own which is again the way a lot of shadow IT, so it gets into trouble as you have them trying to climb the hill themselves without giving them the basic tools for where to go. 

JASON MILLER: I find it very interesting, so what you just described as a couple of things. One is providing a set of tools from a toolbox and standards. Call it the guide rails, letting the IT and governance folks set those boundaries with either a platform or a couple of different platforms to help drive some of that business transformation. It's interesting as the No-Code Playbook came out, and there's been a great debate on LinkedIn and other social platforms and conversations. Should companies be looking at one platform, or should they be looking at multiple-point solutions that are out there? And the answer is that it depends on how much governance you want to apply. Obviously, the larger the solution, the larger the impact of the business. I believe that you want to have one platform. It's easier to maintain; it’s easier to govern from an enterprise standpoint. If you're, you know, a small little organization, you can have three or four, maybe, small no-code tools in your arsenal. But would you agree that the larger the enterprise gets, the more governance probably needs to be in place for what you're doing, and therefore, the consolidation of platforms is one of the core values that a no-code tool can add? 

BURLEY KAWASAKI: I would agree. And we talked about this earlier. The options analysis simpler is usually always better. And while you may initially think that this particular platform has some slight capability differences from another, each team or each function should pick the one best suited for them. I think you ultimately realize that you can't support that complexity. And it's not just the large ones, I would argue. It’s smaller ones in particular. I talked to many small enterprises; they don't have the IT staff to support two or three different no-code tools. They ended up picking one largely because of their internal talent wanting to concentrate their skills on a single toolset of technology. Plus, I would say that even outside of the technology in vendor complexity, there is this process a methodology complexity. Every vendor is a little different, so you do end up tailoring some of the processes and methods for that vendor's capability. And so, if you have too many variants of your methodology in the building process, it’ll also start getting more complex. So it is always best to only have one, not necessarily, but simpler is generally better. 

JASON MILLER: I agree wholeheartedly. And Burley, some of the information you provided us over the last couple of podcasts and the time we spent together have been invaluable. I encourage folks who are listening to this podcast or watching this podcast. If you have not yet read the No-Code Playbook yet by Katherine Kostereva and Burley Kawasaki, I do incur to pick it up. You can purchase a hardcover copy from Amazon or go to the creatio.com website and get your free PDF copy. Burley, thank you again for joining us. It's been a pleasure; I always love to hear your insight on this topic. Well, there again, we've learned a lot about the hype about no-code development and the power of no-code platforms. The benefits are real, and Burley has helped us understand this not only in the No-Code Playbook but also in the discussion we've had over the last couple of podcasts. 

For those of you who are watching us on the YouTube channel, please, make sure to like the video, share the video, and subscribe.

For those who are listening to us on your favorite podcast platform, we hope you've enjoyed our time together today. Check out our previous episodes on various platforms, including Apple Podcasts, Google Podcasts, Spotify, Soundcloud, and more.  

To get more information about our products and services, visit our website. And for more insights and upcoming events, check our No-code events page.

Talk soon!