Podcast Transcript
The following is a special presentation of Tony Kurre Radio with Dr. Alex Heublein and Dr. Josh Klapow. This is Adapt or Perish.
Josh:
Welcome to Adapt or Perish along with Dr. Alex Heublein, president of Adaptigent. I’m Dr. Josh Klapow. Today we’re talking about the pain of technological complexity and Alex, I remember particularly with my technology company, we always had this battle between front end user experience and the back end that was driving it. And one of the things we said was it does doesn’t really matter how complex the back end is, as long as the front end is accessible. And that the user experience couldn’t be all over the place, because then it didn’t do any good. And so really balancing that complexity and finding that balance between the two. What are your thoughts with regard to Adaptigent and what you’ve seen in the marketplace?
Alex:
Yeah, it’s an interesting topic. When you start looking at complexity, we have a saying at my company that complexity is the enemy of innovation and when you look at… And I think it goes beyond just businesses. When you look at what’s happened over the last, let’s say 40 or 50 years, the world has gotten a lot more complicated. Everything is complex compared to what it was 30, 40, 50 years ago. And I think part of that is just that the human race has grown so much. I was looking at a statistic the other day that said that when I was born, about 50 years ago, the world had about half the population it has today. And so, you’ve seen this amazing population growth.
We’ve had great technological growth, but it’s introduced a lot of complexity into our society. That’s hard to get around sometimes. Just something like doing your taxes. 50 years ago, or even 30 years ago everybody got the forms from the IRS and you’d scroll in all the deductions and you had these little worksheets you filled out and everything else. And I suppose you can still do that. But my wife owns a small business and we went to do our taxes last year and we got the little forms and everything out. And we were like, “You know what? There’s no way we’re going to be able to figure this thing out.” And we’re fairly smart people. So, you look at just doing your taxes is something that’s gotten amazingly complex.
And so as a result, you’ve seen businesses get more complex. You’ve seen government entities get more complex. You’ve seen state and local organizations get more complex education. So we see this idea that complexity is increasing and it keeps going up and up and up and up and up. And so the question comes down to, “Well, how do I deal with that complexity?” And I read a book when I was… I was in college when I read it. And it was a really fascinating book. It came out in, I think the late 80s, and it was written by an anthropologist and his name was Joseph Tainter. And it’s called The collapse of complex societies. And what he did was he went back and looked at all the societies over human history that have collapsed. The Romans, the Venetians, the Mayans, and he went back and did a lot of study on this.
And he came to a really interesting conclusion. And his conclusion was that complexity is what caused these civilizations to collapse. They couldn’t deal with the complexity that they had created. So you take the Romans they expanded this empire. It got really, really complicated, but they didn’t have the tools to manage it effectively. And so his hypothesis was look, you have to invest in things to deal with the complexities of society and businesses have to do the same thing. When you’re a very small business, you don’t have to have a lot of bureaucracy. You don’t have to have a lot of processes and procedures and policies and so on and so forth. But as you get bigger and bigger, you do need those things just to run your business or to run a government or whatever it happens to be.
And so his hypothesis was that the minute a society invests a dollar to deal with complexity, and they don’t get at least a dollar back on their investment, these societies collapse. And it happens really, really fast. At least relative to how long that civilization or that society had been in place. And so I think we’re starting to see some of that happen in the war world. The world’s getting more complex and we’ve got to do something about it. We’ve got to be able to go out there and deal with complex organization structures. We’ve got to be able to deal with complex technology integrated all together. So that it’s relatively straightforward to use. And so I think this is a battle or around complexity that we see. Again, not just in businesses, but across the board everywhere you look. And I’ve worked for a lot of big companies, as well as small companies. And Adaptigent we’re a relatively small software company, but I’ve worked for a lot of really big IT companies.
And what we found, or at least what I found was that you go into these big companies and they have a process and a procedure and a policy and a rule for almost everything. And you need those processes and policies and bureaucracy has turned into a bad word over the last few decades. But you need some level of bureaucracy to manage all of that complexity, to run your business in what I’ll call a steady state environment. The challenge you run into, though with all that complexity is that it really stifles innovation. If you’re trying to do something quickly, if you’re trying to do something that’s really, really innovative and game changing in a big company, that all of those policies and procedures and IT systems and everything else, they all get in your way of innovating.
And I don’t think people do it… I don’t think they do it explicitly. They’re not trying to stifle innovation. They’re actually trying to promote innovation. But a lot of businesses don’t realize that, “Hey, you know what? You’ve got to let those innovations happen.” And you’ve got to do it in a way where they’re not just crushed by all the weight of this bureaucracy and this complexity that’s needed to run the steady state business.
Josh:
So let me ask you a question because as you’ve been talking, you’re using complexity. You’re describing complexity as a negative thing, or potentially a negative thing. And that we have to overcome it. We have to manage it. We have to, like you said, we have to get an ROI. If we put a dollar in to manage it, we got to even get more than a dollar out. But is complexity inherently dangerous, bad, not advantageous for innovation and sort of differentiation? Or is it complexity that gets away from us? Does it inherently have to be a bad thing? Because I would actually… I’m sorry, I would actually think that certain systems have to be complex. We want them complex. We want them to be advanced or am I wrong on that?
Alex:
No, no, no, look, I think you’re right. I don’t think there’s anything wrong or bad or negative about complexity. It’s just something we’ve had to deal with over time. And a great example of this is like, you look at a city like London. London was designed and built… At least a lot of it, the core of it was built long before there were automobiles and technology innovations. And so the city is relatively complicated. They’ve had to build the underground stations to move people around, so on and so forth. So I think complexity is just a natural result of trying to scale things in a lot of cases. Think about every time I go to a big city like Tokyo or London or New York, the first thing that strikes me is how the heck do they feed all of these people?
Just something as basic as getting food to a city like Tokyo that has 35 million people in the metropolitan area, and they don’t grow any food in that metropolitan area. So somebody had to figure out over time how to supply enough food to feed 35 million people every single day. And it’s just a staggering level of complexity. So we had to come up with systems for doing that. We had to come up with laws and regulations and supply chains and so on and so forth to make that happen. So I don’t think there’s necessarily anything wrong with complexity. I think the challenge you run into is that when you’re trying to… The complexity we’ve designed into a lot of these systems was designed to run them efficiently. But it wasn’t designed to promote a lot of innovation.
And so a lot of times that complexity in our responses to that complexity get in the way of us actually being able to go out and do new and groundbreaking things. And so I think that’s the big challenge that you run into with complexity. It’s not that it’s bad in and of itself. And our responses to complexity, some of them are great. We couldn’t get by without the responses that we’ve had to complexity and the systems and processes and everything we’ve put into place. It’s just that they end up slowing down innovation. And that’s a big challenge because the world is changing faster and faster. You’ve got to be able to innovate faster and faster to keep pace with what’s going on in the market or what’s going on in the world.
Josh:
All right, so let’s talk some examples because I keep thinking, as you’re speaking. I keep thinking, “All right, well, if I’m going to create this amazing idea, I’m going to innovate, just going to come up with something that’s just mind blowing. Well, even to your example, we’ve got to feed a million people in a small, tight quarters. How are we going to do that?” So I can sit here and come up with lots of creative ideas, but to actually implement that, to get the logistics there, to have the operations, et cetera, there’s got to be some complexity there to make that happen. But when we’re talking about technology, how do we use technological solutions to either, I guess, avoid complexity? Or if we’ve gotten ourselves into a complex situation, again, you use bureaucracies as a great one. Companies that have been around for a long time and they’ve built layers and layers and layers. How do we use technology to get us out of that situation so that we can still have the creative ideas and not be slowed down?
Alex:
Yeah. And that’s really the $64,000 question, isn’t it? What do we do about it? How do we deal with the complexity and how do we use the technologies that we’ve developed and emerging technologies to go do that? And I think you mentioned supply chain. We’re obviously in the United States going, going through a huge supply chain crisis. And I think it’s not just the US it’s across the world. And so we built up this very, very complex interdependent supply chain. Where it’s very, very global and just getting goods from one point, to point A to point B is complex. So we came up with all of technology solutions to be able to do that. We do things like collaborative forecasting and replenishment, where buyers and suppliers actually work together to say, “Look, I think I’m going to need this many of these things. Can you supply me with those?”
And they go, “Yeah, we can supply you with those.” And those drive all of the automation and the factories and how much they need to produce. So I think we’ve been able to use technology to overcome complexity quite effectively. The trick is making sure that you do it intelligently. Because now we’ve seen what happens when the supply chain starts to break down. There are huge issues there. And they’re going to take some time to resolve now I think we’ll get through them, of course. But you can see that there are some disadvantages to having such a complex supply chain and the technology behind it. So I think one of the things that we’ve really focused on at my company is this idea. And one of the ways of dealing with it is, goes back to your earlier example around the front end and the back end.
One of the ways of dealing with complexity is not just to try to remove the complexity. But it’s really to go out and make the complex look and act simple. So, that’s one of the real keys. If I can make it look simple and act simple and make it really accessible to people, then the complexity on the backend, so to speak, isn’t so important to me. So, I’ll give you a real world example of that. The company that I work for Adaptigent, our mission in life is to take IT systems, these older legacy mainframe-based IT systems and make them look and act simple to the rest of the world. Because these systems were developed over… Some of these programs that run things today, like your credit card transactions and your bank balance and your accounts, you wouldn’t believe how much of that stuff still runs on mainframe technology.
And it’s great technology that’s really reliable. It can process billions of transactions a day, so on and so forth, very secure. But the problem is a lot of these programs were written 30, 40, 50 years ago. Really back before we knew what we were doing. And so a lot of businesses to depend on this older technology for good reasons. But now they’re trying to deal with this idea that this has gotten complex. If I’ve been in business for, let’s say 50 years, I’ve got one of everything in my IT stack. I’ve got just about every generation of technology that’s ever existed. And it’s really complicated. So, what we do is we try to help organizations make that complexity look simple and act simple by integrating it with the more modern technology platforms like cloud native applications and so on and so forth.
So I think that’s one strategy that’s been very effective for us and for our customers is being able to make it look simple, act simple, at least to the users. And what that gives organizations time to do is actually then go back and say, “Okay, how are we going to consolidate some of this stuff? How are we going to reduce the amount of complexity?” And to the people that are using the technology, they don’t really know any different. If I decide to make some changes on that back end, I can shield the people that are using the technology and using the data and using the transactional systems. I can isolate them from that so that they don’t know really what I’m doing on the back end. And I think that’s a very important idea in dealing with complexity. Make it look simple, make it act simple. And then at the end of the day, it is simple to most of the people that use it.
Josh:
So take me down two roads. So one that you’ve just described, which is right we’re in a business we’ve been building up. We’ve been this for 20 years, 30 years. And we’ve been stacking these various technologies and holding things together, plugging things in one offs, just so it all works. And then what you’re saying is that through software solutions like those with Adaptigent, we can make them work if you will. Even if we’re changing the back end, we can make them work functionally the same way. Or maybe in some cases, even better on the front end without having to wipe the slate clean and bring in an entire new core system, is that accurate to describe?
Alex:
Yeah, absolutely. And that’s really what we do. And it’s something that we call a layer of abstraction. And a layer of abstraction is just a layer you put in between two things so that they’re not dependent on one another completely. And there’s an old joke in computer science that every problem in computer science can be solved with one more layer of abstraction. And so, you tend to see these things everywhere. You just don’t know that they’re there even something like going to a webpage. Like when you go to a webpage, you type in a URL, www.whatever.com. And the reality is behind the scenes, what really happens there is that, that URL gets translated into an IP address. And an IP address is what you actually end up using to communicate with whatever server or whatever computer you’re talking to.
It’s like, it’s unique identifier. But people said, you know what, first of all, people can’t remember a big string of numbers, so that’s not going to work. So we’ll give them these URLs made out of words that they can remember. But more importantly, if I change the server, if I move it from one location to the other, and it gets a new IP address, well, guess what? I don’t have to do anything. I’ve got a layer of abstraction in place where I can get that same URL that www dot whatever that I’ve typed in will now resolve to wherever that new server is or wherever it’s located or what’s changed on it. So that’s a really good example of a layer of abstraction that exists that very, very few people even realize is there. So we try to do that with our customers.
To be able to put a layer of abstraction in between all of the applications and systems and people that need access to these legacy data sources and transactional systems. We put that layer of abstraction in place. And then that lets us move things around underneath the covers without them ever knowing we just… Oh, instead of changing every application and every user and everything that accesses these systems, I just change the abstraction layer. So I change it in one place. And now I can make changes on the back end that get reflected in that layer of abstraction so that I don’t have to go changing my website or my mobile app or whatever it happens to be. So that’s one of the ways that we use these layers of abstraction. We use them so that now I can make changes. I can start to eliminate or reduce the complexity behind the scenes, but I’m not disrupting my business as part of doing that.
Josh:
So are there situations though, where… And could you hear this a lot where you have to come in and change? In other words that you can’t just layer in abstraction in order to, whether it’s to modernize or maybe the company, the business has a couple of ideas about where they want to go. Whether they’re pivoting in business practices, or they’re just adding in functionality, is there ever a situation where you come in and you’re essentially having to say, “Yes, we can do layers of abstraction, but there need to be some core changes?” Or is this essentially limitless in this approach? Because you see frequently companies will go in when they got legacy systems and they bring everything in, they change everything. They get the whole new enterprise chords change. Does that ever have to be done? Is that ever have to be done or is that just a old school way of doing things that we don’t have to do anymore?
Alex:
I think it really depends on the situation. So, I’m going to answer your question directly, yes. There are situations where you have to do that. Where you’ve got to go rip and replace technologies, pull them out. And it goes back to that idea that if I invest a dollar in managing complexity and I wind up getting a dollar out of it, that’s the inflection point. Where I say to myself, “Okay, this has to go.” I’m investing money in it, but I’m actually getting a declining marginal return earn on that investment. And so that’s really important. And I think to your point, that’s the inflection point that it occurs at. And I think a lot of organizations, they remain on technology platforms and they know that in some cases they need to move maybe to a new, a more modern platform. But there’s a lot of risk involved because a lot of these systems, they run the business.
They run the core of their business. And so they’re terrified to do it. They’re looking at it saying, “Wow, if all goes well, I’ve moved onto a new platform. If it doesn’t go well, I’ve just lost my job.” And there’s plenty of people over the years that have tried this sort of thing and in fact, lost their jobs as a result of doing it. So, yeah. So I do think that there are situations when you really sit down and look at it and you look at the risk profile that you’ve got, you look at the marginal utility of your investment. And at that point where if I invest a dollar, I’m not getting back a dollar, at least a dollar I’d like to get $10 back as a business.
But the minute that that return goes negative, that’s when people really start taking a hard look at it. So, to answer your question directly, yes, there are circumstances where that’s absolutely appropriate. And there’s circumstances where let’s put an abstraction layer in place, and then let’s deal with this over time that makes sense. It really comes down to how you run your business, what you do and what your tolerance for risk is.
Josh:
So, take us now… So I was thinking about this, give me a little preventive medicine. So we’ve been describing, “All right, your arteries are already clogged up. You’ve been running on brittle bones for years, but it’s okay. We’re not going to have to cut anything off or do a triple bypass. We’re going to be able to stent you and it’s going to work.” But as you were talking, I kept thinking, “Okay, I’m starting my business now. I know some of the core elements of where I’m going to want to go, what my company’s going to do, but I want to position myself so that I don’t get stuck if you will.” And I kept thinking, is that no longer an issue? In other words, if we’re starting fresh from today, do we still have to worry about that we’re going to be in a position where we’re going to have legacy systems? Or is there a way to do this where essentially we can use abstraction layers in perpetuity? How do we do this right to start off?
Alex:
Yeah, no, that’s great question. And I think one of the keys to it, when you look at what we’ve learned about IT systems and developing software over the last 50 years. Back in the old days, you built systems that you didn’t worry too much about the future. You wrote applications because back then things like memory and disc storage and processing power were just crazy expensive. Just crazy expensive. In fact, the phone that I’ve got right here in my hand it has more power and memory and storage than the fastest computer and the best computer in the world had 50 years ago, maybe even 40 years ago. So, back then you made design decisions about what you did based on available resources.
Now, as technology has expanded and Moore’s law has really kicked in, and we see this doubling of processing power every couple of years and the doubling of the amount of memory and storage and everything else. We eventually got to a point where we said, “Well, we’re not nearly as resource constraints, so maybe we should start making some better decisions. Given that those resource constraints aren’t there anymore.” So I think a lot of the modern technologies that you’re seeing right now, moving things into the cloud, making them cloud native, using a lot of the modern principles of software engineering. Now we can design things that aren’t nearly as complex, and we can design things that have integration with other things in mind when we design them when we architect them. So I think that’s one of the big things that we have to focus on is making sure that we design software and we design applications, so that not only are they easily adaptable and flexible. But that they also don’t introduce a newer level of complexity that just makes the whole problem even worse.
And so I think we’ve really started to see that in the last 10 or 15 years. There’s been a big push towards moving from… For instance, back in the old days, we had what’s known as tight coupling between applications, which meant these applications were very tightly bound to one another. And we did it for efficiency reasons, but as those constraints went away, we started saying, “You know what? Let’s make these interfaces much more loosely coupled. So that I can change one and I don’t have to go changing the other necessarily.” So going back to that abstraction layer concept.
So I think as we’ve evolved in technology and we’ve evolved in the software space, we’ve implemented a lot of new principles and ideas and architectural paradigms that have allowed us to start to reduce some of that complexity and hopefully eliminate some of that complexity going forward. I don’t think we’ll ever eliminate it altogether. The world keeps getting more complex, but I think we are making some really good inroads in making sure that we try to take complexity into account when we design things going forward versus in the past, we just didn’t have that luxury.
Josh:
So let me throw you this last question, this idea about going all the way back to what we were talking about in the beginning. We’ve got a company, whether it’s an existing company or new company. We have some thoughts, some ideas about what we want to have done, what we need the user experience to be, or a new application. When I mean application, I mean a new functionality and in the past, the way you’ve described it has been “Okay, well, you can only do X and Z because the technology doesn’t really allow you to do much more.” It feels like we’re at the point where the functionality should be the driving. The business requirement should be the driving force, because whether it’s through complexity mitigation or even just the design, you can do almost anything.
I know that’s a little strong of a word, but that we shouldn’t get bogged down in the complexity piece. But really we’re in a position now to be thinking about what is the functionality that we need even… And this is where my question is even we’ve got legacy systems. So if I’m a business got legacy systems, I want to do something different. I don’t want to rip it out and replace. Are we at that point where most of the things that we want to do in terms of our pivots can be done with software abstraction or a software adaptation?
Alex:
Yeah. I think we’re getting there. There’s been a really big push over the last let’s call it 15 or 20 years to move in that direction. And when you talk about this idea of functionality, that the business is really driving because most of what we do in software engineering is things to solve business problems at the end of the day. And so, when you look at solving those business problems, in the past, we’ve had the business says, “I want to go do this.” And the technology guys come to the table and they go, “That’s fantastic that you want to do that. Here’s what we can actually do.” And you negotiate to somewhere in the middle. So I think you’re right, we’ve gotten to the point where we can build systems very, very rapidly today. That that implement the needs of the business in a way that doesn’t add a lot of complexity to it and really gets you what you want.
And so we’ve seen a big jump just in the last five or 10 years towards what they call no code or low code platforms. So instead of having to hire an army of programmers to do things, I go out and use tools that allow… Still technical people, but not necessarily programmers to go build some very sophisticated applications without having to write a lot of code in the process. And that’s one way that we’re seeing the response and the marketplace is saying, “I don’t want any more complexity. I want to be able to do this with visual dragon drop, no code tools.” And that’s really the direction that we at Adaptigent have gone down. We have an integration platform that is truly, it’s no code drag and drop it’s a visual interface. And so not only does that help us be able to translate business problems into technology solutions more easily, but it also lets us achieve a much higher degree of what I call business IT alignment.
Where the business and the IT are on the same page and believe me in the past, they haven’t always been. So, yes, I think we are on the cusp of really making some great strides and great progress in implementing that business functionality without adding massive complexity to an already complex system.
Josh:
So in the minute or so that we have left, if people are sitting here and listening this… And again, they’re either in maybe one of two boats, “I’ve got an existing system and it’s a mess. And I know I want to make some changes or again, I’m thinking of moving in a new direction.” What is your take home message about this idea of complexity? How should we be thinking both on the IT side and the business side in terms of dealing with complexity and using complexity to drive our business forward versus holding it back? What’s your take home on that?
Alex:
Yeah. Well, I think the big take home message on that is look, you’ve got to be aware of it. I think the reason a lot of complexity exists, particularly in the IT world is that people just weren’t thinking about it when they designed and architected these systems. That wasn’t a top of mind priority for them. So I think the real key is to make sure you’re cognizant of this level of complexity and that you make good decisions architecturally, and from a design standpoint. So you don’t end up painting yourself into yet another corner of complexity. Be aware of it, and then try to use technology to combat the problem. Again, this idea of not writing code the idea’s been around for a long time.
But we finally now have the tooling that lets us accomplish a lot of those things and achieve some of the goals we set out to do that. So, be aware of the complexity design things to be as simple as possible that still get the job done and then use technology tools to be able to mitigate some of that complexity going forward and make the systems overall easier to maintain, easier to change, easier to build in the first place.
Josh:
Ah, that’s great advice. That’s great advice. Well, unfortunately we are out of time, but that’s okay. Thank you everyone for joining us today on Adapt or Perish for Dr. Alex Heublein, I’m Dr. Josh Klapow and be sure and tune into the Tony Kurre radio network for our next episode of Adapt or Perish.