Technology thought leader Randy Johnston of K2 Enterprises shares how firms should be building and thinking about their arsenal of tech tools.
Transcription:
Transcripts are generated using a combination of speech recognition software and human transcribers, and may contain errors. Please check the corresponding audio for the authoritative record.
Dan Hood (00:02):
Welcome to On the Air with Accounting Today, I'm editor-in-chief Dan Hood. Tech stacks are like opinions: Everyone has one, but no one knows how good they are. Here to help talk about what a tech stack is, what yours should look like and how you can get the most out of it is Randy Johnston. He's executive vice president of K2 Enterprises and one of the foremost thinkers and experts on accounting technology in the field. Randy, thanks for joining us
Randy Johnston (00:21):
And I am so pleased to be here on this topic. Tech stacks have been near and dear to my heart for decades, but probably the last year more so than any other time that I can think of. And it's because the selection of a proper tech stack can make all the difference in the world on productivity and solve problems.
Dan Hood (00:39):
Absolutely, and I think firms are, as you say, in the last year or maybe last few years have been starting to come to realize this, but I want to take a step back and say, first off, how would you define a tech stack?
Randy Johnston (00:51):
Well, I'm going to take two or three answers on this one, Dan. Still trying to keep them simple. First off, you can be real low level on your tech stack. You can be an all Windows tech stack or an All Mac OSS tech stack, or iOS or Android or Linux. So you can be at that level. But I think for our purposes for public practice listeners, perhaps the tech stack available from a major publisher from Walters Kluwer or from Thomson Reuters or from Intuit. And what we are finding is that instead of using a single tech stack, many, many choices are being made to say, I can't solve all my problems, so I'm going to go to best of breed. But if we could turn it over to accounting software for our industry attendees or for client accounting services in our public practice firms here, we might pick an ecosystem, might be another way to talk about tech stacks.
(01:48)
So here maybe I want to use Intuits QuickBooks online, or I want to use Xero, or I want to use Zoho, or I want to use Sage Intacct. And once you pick your base platform, then you're in that ecosystem, if you will. And your tech stack can be pretty broad for let's just say QuickBooks online. And just so you know Dan, I track these various tech stacks and I have at least 16 service deliverables for client accounting services. And in the QuickBooks online tech stack alone conservatively, I'm actually tracking 64 different products and I have way more than that. I have 64 that I recommend. Now just picture trying to wrap your bloody head around that when you just want to solve a problem. Exactly. I mean, I got to understand 64 different products to be able to select one that will solve it. Yeah, it's that batch.
Dan Hood (02:47):
Well, that's one of the reasons we're talking about this, right? To help get some people, I don't think we're not going to be able to get into picking among the 64 products for them, but we can give 'em maybe some ideas about how they can go about thinking about how they're going to pick the products to fit into Tech Stack. And I think you started off with that three or four different differentiations of possibilities, ecosystem, best of breeded, individual publisher kind of thing. Those are super useful ways to start. At the very least, start thinking about your approach to your tech stack. What are some other key considerations the firms should be bearing in mind when they're building or revising? Because a lot of firms, and stop you if I'm wrong about this, I think a lot of firms have sort of stumbled into a tech stack in the sense of, well, we use this and we use this and we use this. So that's our tech stack, but it's not a deliberately built stack. It's more of just it's an untidy pile, put it that way.
Randy Johnston (03:32):
And many times, you're absolutely right, it's accidental in our neck of the woods we see even a blind pig finds an acorn once in a while, and that's what's happened in some of these tech stacks. And I just say, oh, we need to be purposeful on this, but many of us are not. And I'm not criticizing on that life. One thing that's made it much more simple though, Dan, in the older days we had independent computers and then networks and client server architectures and so forth. And the world of software as a service running in a browser has made a lot of these decisions easier. Not necessarily cheaper, but easier. And I readily admit I was wrong on this because I thought software as a service would be the dominant deliverable by as early as 2015, and we're still not there today. So if you're in public practice and you want to run everything in a browser, lots of luck because you can't do it today.
(04:27)
If you're in industry, you got a better chance. So another one of the rules of tech stacks, and my partner Long-term partner out of candidate award, Blatch was adamant about running everything in a browser. He said, if it doesn't run in a browser, I don't want it. And as he retired out, he pretty much had everything running in the browser, but you could make that as another one of your parameters, which gives you operating system independence. But if you are in a part of the country where you don't have very good internet access, running everything as SaaS or in a browser, that's suicidal. And we tend not to think that our country of the US with 330 million people, that there are people that don't have internet access yet, but there's people that don't have cell phone access, let alone internet access. Yep,
Dan Hood (05:16):
Yep. Now I'm right now in a part of the country where internet access is questionable or relatively hard to get. So yeah, but as you say, most people don't really think about it. But I think I've seen numbers that suggest as much as 20% of the country is not or doesn't have strong good bandwidth, they may have it, but it's not up to handling an accounting application, for instance.
Randy Johnston (05:42):
Yeah, exactly. Right. And your numbers pretty close to what I've seen. Also, Dan, it's part of the reason I was so interested in fiber optic deployment across the us. That was a pretty important initiative, but boy, it takes a long time to build those infrastructures. So there are some key things that you need to keep in mind when you're building or thinking about your tech stacks as I would see it. But I always keep the end goal in mind if we want to use this Steve Covey way of talking about it, because what are you trying to accomplish for your business? Or what are you trying to accomplish for your clients as you're doing that? And you need to be very clear in that thinking. That's one. Number two, you need to be very clear in dealing with companies that are stable, you might find the greatest solution and they go out of business. And unfortunately through the years, I've made a few shot calls where there was a great platform, but the company didn't have the financial stability to stay the course and they disappeared. Or today we are seeing an awful lot of merger acquisitions, which are beyond most of our controls. But what we have to worry about there is the platform good enough that it'll survive an acquisition and still be available as a product.
Dan Hood (06:59):
Right? As opposed to, and we were talking an earlier podcast. We were talking about the great consolidation of the end of the 1990s and into the early two thousands when there was people were just buying user bases and they would sunset a product or it was always the big question, will they sunset the product right away? Will they just abandon it? Are they really just buying users or getting rid of competitors? And that was always a huge issue and people don't talk about that as much these days, but it's certainly an issue. As you say, if you've bet your tech stack on a core product, it
Randy Johnston (07:27):
Certainly is. It goes away. And if you think about this just as an example, these products survived. But if you think about the expense reporting products that rolled up in the reimburse transaction, of which there's five products there today, a very good product like Tally was part of that acquisition, and Nexio is part of that acquisition. If you were building your practice all around those expense tools and all of a sudden they no longer existed, that'd be a real bad day.
Dan Hood (07:55):
That's a bummer. Alright. But we're rapidly amassing a pretty great set of criteria for how you think about your tech stack, just say longevity of the product, stability of the company that you're buying for SaaS, where possible. And it's not there yet, but certainly that's the general trend everyone is moving towards. I mean, I don't know how long it will be, but we just assume at some point in the future pretty much everything's going to be SaaS though it isn't yet. And then the three or four categories we talked at the beginning about best of breed versus a single publisher versus the ecosystem, that sort of thing. Are there any other criteria you think people should be paying attention to?
Randy Johnston (08:35):
Well, there are a few more things that you'll not be explained to you properly in the sales process, but you'll have to go to others to determine if it's so first, the tech support, how quickly and how well is the support provided by the vendor? I don't want to be talking to chatbots or texting on platforms. If I've got a real problem, I need to be able to talk to a real person. Number two is reliability and availability. Things break. We all have systems that fail for one reason or another, but it is important to ask about the stability of the products. Now, many of the vendors will not actually tell you how often their platform is unavailable. And a lot of these systems are built on top of other technologies today that would mean that they're using Amazon Web services are Azure or Google hosting, and the vendor is dependent on another vendor's technology to run.
(09:39)
So you need to understand what the technology in use is probably a little less of an issue for some of your listeners, but a big issue for others is where the data lives today, there are six jurisdictional controls US is one, Canada has another set, the European Union, another set, the GCC, the Saudi Arabian Peninsula if you will, has another set and China has another set and so forth. So you need to understand where the data lives, if you've got a restriction around that. And if you're going to work globally, notice another thing that you might have is multi locational, multilingual requirements. So I don't want to make it sound too complex, but you need to be thoughtful about your base issues. And frankly, I always, in fact, the last call, Dan I took before our discussion today was with a new platform and I asked them about their availability and what they were running on. Those are vetting questions you have to ask every time. And by the way, you don't have to be a technical person, but you ought to be listening for things like it's SOC certified or SSAE 16 or even though those certifications may not mean as much as they should, they are important that the vendor is go into the effort of trying to take care of those issues right
Dan Hood (11:02):
At they're, at least they're making the effort,
Randy Johnston (11:06):
They're trying. I'm giving that
Dan Hood (11:07):
Excellent. And this may be a question that I should have asked a little earlier, but I'm just curious, when we talk about a tech stack, are there firms that are just too small to really worry about a tech stack? And maybe on the flip side of that is, as you look at much larger firms, do you reach a point where a firm is really looking at, well, we're so big, we really need two tech stacks or three tech stacks or one Tech Stack per major service offering or department or something like that. Are there different, put it this way, different approaches to Tech Stacks varying by size.
Randy Johnston (11:40):
So Dan, I think the best way to answer that is everybody of all sizes has to consider their tech stack. Now let's keep it real simple. Think about your home. Are you an Amazon Alexa home or are you a Google Home or are you an Apple home? And see, even on a personal level, I think you got a tech stack because for our listeners, you might've settled on the iPhone or an Android phone as your base system. And if you get outside that ecosystem, it's kind of problematic for you. Now, I think even in very small firms, you've got to narrow your choices because it reduces your costs, it reduces your training, and it makes it easier to onboard new people and new clients. Now if we go to the other extreme, that actually is something that I've encouraged on very large firms. There are times when you need different levels of systems to solve the problem.
(12:42)
So let's keep it as simple as I can In client accounting services, there's entry level systems like Zero Zoho or QuickBooks, but there's mid-market products like Sage, intech or Acumatica. And the entry-level systems are sufficient to solve a lot of the small business problems. But you don't want to try to solve problems with those entry-level accounting softwares for mid-market firms. So the probability of you having to have at least two stacks to solve accounting related problems is very high. Now, I'll flip it over one last time. Likewise, I don't think it's wise to use a mid-market accounting stack to try to solve small business problems. Now that is being done here in the us, but I think it is not economic. I think it is too complex. There's lots of reasons why I just wouldn't do it that way. But some people just say, we're just going to have one platform and we're going to solve it that way. So yeah, every problem will look like a nail if all you've got's a hammer.
Dan Hood (13:47):
But if you've got 17 different hammers, that's too many hammers. I dunno how many, what's the ideal number of hammers? I think that's what we're hoping to come away from this podcast. But way it's interesting is you talk about CAS and caskets, very complicated in terms of tech stacks for a bit. That was the, the conventional wisdom was nope, single platform because we want all of our people to be able to understand it well, to be able to deliver it optimally so that we're not confused by six different platforms. All of our guys in cast are expert on this one. But then you hear more people talking about, well, we're actually, listen, we're dealing with, we've got three different specific niche sectors or verticals that we're paying attention to on our cast, and one platform's not going to work for all of those. Or one stack in some cases where to say maybe even if the underlying GL does, I need six different things for this manufacturing or two different things for this because it's a subscription based technology company. In other words, they started to realize, well, we can't be dogmatic about this rule. We just need to be thinking about, we want to have a tech stack that's appropriate for the clients. If that means having two tech stacks, maybe we do that. So yeah, it's weird. It seems to a little bit in progress
Randy Johnston (14:53):
And your question is actually framing it right? If you're dealing with not-for-profits, you really have to be running a good, not-for-profit platform. If you're dealing with manufacturing, you have to deal the right manufacturing platforms and so forth. And that thinking was Ill-founded of trying to have that single stack. I get the efficiencies you need to do that. We believe that a single platform for your core deliverables is fine, but if you start niching, if you start having specialty needs, the probability of having to build a complete separate tech stack for that part of the practice or that part of the business, it's really, really probable. But you want to be thoughtful about it, you just don't want to stumble into it. Again, yes, I can stretch certain platforms to do things that they probably shouldn't do, but if you're going to really focus around it, need to do that.
(15:47)
So I'll just call out a couple of platforms. The accountants World Power Practice platform does a nice job in a general way and lots of people have built a very good cast practice around that, but others have chosen another platform like Zoho Books and all of the Zoho one platform to do it. And each of those solutions cover certain verticals. Now, even though accountants world doesn't handle not-for-profits, I've got firms that are configuring that to make not-for-profit accounting work, whereas frankly that have been a lot better off if they had done something like Aplos or Sage, depending on the size. So again, the problem for many of the listeners is there are a myriad of solutions if you start searching. You can't really trust very much the G twos or the cafeteria or all those resources because there's so much marketing behind them. It's about selling you a new platform as opposed to solving a problem.
Dan Hood (16:52):
Gotcha. Excellent. Alright, I want to dive a little bit more into the sort of building of a tech stack, tech stack and managing of a tech stack at your firm. But we're going to take a quick break before we do. Alright, and we're back with Randy Johnson of K two Enterprises and we are diving deeply into tech stacks, what they mean, what they should look like, how you should be building that. And I want to this portion of the episode off by talking a little bit about common mistakes you're seeing or common misapprehensions we talked about in a cash practice trying to stretch a tech stack over too many verticals, it's not appropriate for, are there other sort of mistakes you see firms making when they manage their tech stacks?
Randy Johnston (17:35):
Very routine mistakes are made in several areas, but let's identify two biggies to get us started. First, managing the security. Because what happens is we just assume that each individual platform is managing security, but the connections between the platforms also are a security risk. And if you do not have an overarching security strategy, it can be a problem. So let's illustrate it. A very popular methodology used today is single sign-on you log in once and it connects you to the different systems. But already attackers have figured out if they can get into any one system, they can use those credentials to traverse to other systems. So if you don't have an outsourced provider or somebody in-house that's managing your security, that's a big, big risk. Number two, Dan, is the connections between these systems. Commonly in this world of tech stacks today that's managed with application program interfaces or APIs.
(18:42)
There's two common API methodologies, there's SOAP and there's rest states. So the better approach today is to look for an API that's is restful. Those are easier to connect, but many of the systems don't have a way to get that done. So then we use what we've referred to as digital plumbing tools, the Zapier, the boomie, and the cdata would be examples. And there's about 30 of those platforms out there, by the way. And now all of a sudden we've got version compatibility differentials between our add-ins or our additional platforms, and we can't get things to sync and we need backups of these data. And when the data is in the platform in the cloud, how do we roll back that data to a point in the past? So backup here becomes radically critical and there's very few tools that can actually reset the state of multiple platforms at the same time at the low end. A very simple example that I'm sure you're familiar with is Rewind, because it will let you take your QuickBooks data back to a point in time along with your third party data. But what'll happen is these systems will get out of sync and ULA la it is a mess to try to fix.
Dan Hood (19:57):
Right? Right. Yeah. Eventually we'll come to the point where there'll just be software and it'll all be in the same place. It'll all be controllable and safe. But until whenever you're dealing with these, well with the tech stack, with this huge selection of different software, different packages, different platforms, getting 'em all to work together has got to require a lot of thought, particularly as you say around technology, around security, excuse me. And around that. I mean that's an issue. I don't think a lot of people think of the notion of being able to back it up to roll it back to a previous point with all the ransomware attacks and so on that are going on. These are big, big issues we're thinking about.
Randy Johnston (20:29):
Yeah, so my favorite saying from 2016, which I learned from a software executive, if you say it real fast, it sounds easy. And he was so right because at the time everybody was just kind of waving their hands and saying, oh, this is all simple. And frankly this isn't as simple as it seems. So just be cautious that if a vendor's portraying it to be real simple, it may not be. So again, you need to be defensive in your stack and you need to be thoughtful in your stack.
Dan Hood (21:01):
Excellent. Alright, very cool. One last thing I want to talk about because one thing we don't want people to think that you can set your tech stack and then forget it, right? It's not a set and forget it kind of thing. It's got to evolve just as software evolves and changes over time, are there any sort of rules of thumb, good rules of thumb or good approaches for keeping your tech stack up to date?
Randy Johnston (21:20):
Yeah, and I'm just thinking as you're asking that question, the Ronco guy is no more. I mean it's really a sad thing, isn't it?
Dan Hood (21:26):
Yes,
Randy Johnston (21:26):
Very sad. Set it and forget it does not work. And I'm going to be a little more aggressive on this point. All technology gets updated over time and any technology you are using that is more than 10 years old has to be reviewed. Now occasionally vendors will keep up with the times, but what I've discovered through these decades of following technology, a whole bunch of the vendors lose their way and they don't update their technology. So what you need to do is every tool in your tech stack, you need to have rotation where you look at it. I normally recommend that you review it annually and you keep in mind a substitute tool for everything that you've got. So here's the tool we're using today, here's my backup or here's my secondary tool in case this vendor goes away. But usually then I align my organizational strategy and tactics with my technology strategy and tactics and my tech stack, and I try to maintain a relationship between those strategies and tactics.
(22:34)
And I look at every tool and say, does this work? But never ever do you let a tool go more than 10 years and let's just take one that would fly in the face of this Microsoft office. A lot of you've been in office a long time, many of you're using the Google Workplace or Zoho one as your stack. But the fact of the matter is Microsoft had to rebuild their technology stack radically over the last 10 years if they wouldn't have done it. In fact, if they wouldn't have gotten smacked around a little bit by Google's workplace, they may never have built Office 365. I like competition. I like there to always be at least three providers in every category. And that means that there's three different choices because Dan, another way to talk about this is what's the difference between a Ford and a Chevy and oh, I don't know a Tesla,
Dan Hood (23:26):
I can make a long list.
Randy Johnston (23:29):
You got it. But there's a little bit of it. If you get simplistic about this, if transportation's good enough for you, it probably doesn't matter. But if you like the way A BMW door sounds when you close it or the way it feels when you drive at the experience, that's kind of what we're talking about here in these tech stacks. Some of these are yugos and some of these are BMWs,
Dan Hood (23:52):
Right? But I love that. Well, I love that idea of always starting having a backup in mind. And this goes to, we're a little bit more focused on accounting technology or accounting software here, but you talk about Will every year we'll get an email from someone in the middle of tax season saying, my tax software just collapsed. Do you know any good software? And part of it's because they've gone 10, 20 years with the same provider. It's comfortable, they're used to it. And it's only suddenly now, as you say, after 10 years it collapses and they have no backups, no possible backups. So having that as part of your just general sort of good hygiene for technology.
Randy Johnston (24:30):
And to your point on that, Dan, I understand that organizations have a devil of a time with change management and deploying new systems. And a lot of organizations change software as often as they change major world religions or physicians. And I understand the comfort level and there's a cost of changing and I hate the cost of changing, but the cost of not changing could be worse. So just be thoughtful about am I building a practice? Am I running a business that can run for a long time? Because it's a heck of a lot different if you're running the thing till the wheels fall off. And some people run their cars that way too. You've seen 'em on the roads and they're kind of smoky and beat up and so forth. Or are you leasing a new car every year? What's your strategy? And again, I'm not here to tell you one way or the other is better, but I can tell you there are a lot of soft costs in using old technology that doesn't work very well and you don't even understand how much time you're costing your team members in this labor short period by using old technology.
Dan Hood (25:41):
Absolutely. Excellent. I think we've given people a lot of things to think about in terms of how to manage the tech stack, how to build one, the general strategy around it, how to keep it up to date. Any final thoughts before we go?
Randy Johnston (25:52):
Yes. In this one, I would suggest that you have to think about this from your own perspective. It doesn't matter what your peers are doing, what the salespeople are telling you and so forth. You have to really say, what am I trying to do with my team? What am I trying to do for my clients or customers? And you got to be thoughtful about your research. The ratings that you'll see on various websites and so forth, they're often gained. But you need to be looking for places in your processes that are broken or clumsy. Remember, no accountant should be keen data in today's world. And so if you have any of your team members keen data, you got a broken process and you need to work on that. I just go back, whenever I talk about processes, think about Ray Croc in the McDonald's way. We may not like McDonald's burgers, but they're consistent. And that business was built around processes and that's what we're trying to get you to think about. Your tech stack should enable your processes to deliver excellent services.
Dan Hood (26:56):
There you go. I'm going to actually make the plug for McDonald's burgers, 11 McDonald's burger work there on my high school years tremendously and going to make a plug for the founder. Great movie, all about the founding of McDonald's. And it speaks all to the process thing you're talking about. Sorry, that's a topic's near and dear to me.
Randy Johnston (27:11):
If you didn't see, they just had a great quarter because of the grimace programs, people drinking. Yeah, I get it. And when I talk about errors that are made, and again, we could go down a whole nother rabbit hole here, Dan, together, every vendor that you work with will make short-term mistakes in their tech stacks, and I encourage you to be a little forgiving and work with them and report things that aren't working right, because most of them in good faith will try to fix them right away, but you can't just throw them under the bus when there's a problem.
Dan Hood (27:50):
Yeah, no, you have a certain amount of partnership there will go a long way, right? Because things, they may start paying attention to your wants as opposed to your needs, right? You say if you're the customer who's cool about a downtime period or a minor error and help them fix it later on when you say, Hey, this would be great. If you've got that partnership, you may be in a position to get that pushed up to queue a little bit.
Randy Johnston (28:10):
Absolutely. And in fact, it's been a pleasure through my career by working with so many of these vendors. They know I'm an old programmer and I'll make polite suggestions and I'll give them some space to solve things, but they also know I'm not very pretty when things are broken for a long period of time.
Dan Hood (28:30):
Excellent. On that slightly terrifying note, ready, Johnston of K two Enterprises, thank you so much for joining us. A lot of great things to think about, and I know the audience is going to be thinking about 'em for a long time, so thank you for joining us.
Randy Johnston (28:43):
We used to spend the time with you, Dan, and your listeners. We'll see you again.
Dan Hood (28:47):
Cheers. Excellent. Thank you all for listening. This episode of On the Air was produced by Accounting Today with audio production by Kevin Parise. Rate us or review us on your favorite podcast platform and see the rest of our content on accountingtoday.com. Thanks again to our guest and thank you for listening.