🎙️Transcript: The Great Debate - Infraday California
Infraday California (Los Angeles)
"The Great Debate: Build vs. Buy"
Keith Kajiya (Safework), Nicholas Johnson (Kahua), Ralph Barsi (Kahua)
April 25, 2024
đź“ş View on YouTube
Summary
This spirited debate, moderated by Keith Kajiya (President of SafeWork), features Nicholas Johnson and Ralph Barsi discussing the eternal technology question facing construction and infrastructure organizations: should you build custom software or buy commercial off-the-shelf solutions?
The debate takes place at what appears to be an industry conference focused on infrastructure and construction technology. Both debaters bring decades of experience to the discussion, with Johnson representing five decades in the industry and his involvement in creating Constructware (the first internet-based project management tool), while Barsi brings over two decades of SaaS expertise.
Kajiya himself adds credibility as someone who has both built custom software for a $2 billion wastewater program and implemented commercial solutions across $40 billion worth of delivered projects.
The debate follows a similar trajectory to many real-world discussions on this topic, starting with passionate arguments for each side before revealing that the optimal solution isn't an either/or decision.
The speakers ultimately converge on Platform as a Service (PaaS) and low-code/no-code solutions as the ideal middle ground, offering the reliability and immediate functionality of commercial software while providing the flexibility to customize and extend capabilities based on specific organizational needs.
The discussion includes practical visual demonstrations using smartphones as analogies for platforms, detailed explanations of how partner ecosystems can extend functionality, and critical insights about security certifications like FedRAMP and StateRAMP that are becoming increasingly important in government and infrastructure projects.
BIG Takeaways
• The Smartphone Analogy Perfectly Illustrates Platform as a Service – Nicholas Johnson's demonstration using his Android phone (and acknowledgment of iOS) provides a brilliant metaphor for understanding PaaS in construction technology.
Just as Google and Apple provide core functionality (phone, text, camera) while allowing third parties to build specialized apps (Delta Airlines, Hilton Hotels, LinkedIn), construction platforms should focus on core capabilities like cost management and document control while enabling users and partners to build industry-specific or company-specific applications.
This ecosystem approach means you're not limited to what one vendor thinks you need, nor are you responsible for building everything from scratch.
• The Hidden Human Cost of Custom Development Often Exceeds Software Costs – Building custom software requires creating an entire support infrastructure that organizations often underestimate. As Johnson points out, you need to create your own manuals, videos, training tools, and maintain a help desk.
You need permanent staff to handle ongoing maintenance, updates, and user support. The question "Do you know what a user interface is supposed to look like?" highlights that construction companies excel at building physical infrastructure but may lack the specialized expertise needed for software development, making the human resource burden particularly challenging.
• Industry-Specific Packages Can Provide 90% Solutions as Starting Points – Keith Kajiya's experience at SafeWork demonstrates that with the right platform, you can create industry-specific templates that provide 90% of needed functionality for specific sectors (K-12 education, transportation, healthcare, P3 projects).
These pre-built packages, often developed by partner companies with deep domain expertise, dramatically reduce implementation time while still allowing for the remaining 10% customization that makes each organization unique. This approach has enabled SafeWork to quickly pivot between different client types without starting from scratch each time.
• The 2,200-Item Wishlist Problem Illustrates Traditional SaaS Limitations – Johnson's revelation that Constructware had accumulated 2,200 unimplemented feature requests when sold to Autodesk perfectly captures the bottleneck problem of traditional SaaS.
When only the vendor can modify the software, even good ideas that would benefit the industry get stuck in an endless queue. With PaaS and low-code platforms, this wishlist shrinks to just a few items because users can implement their own features or hire partners to do so, eliminating the dependency on a single vendor's development priorities and timeline.
• "We've Always Done It That Way" Is Both the Problem and the Solution – The debate highlights a fundamental tension: Barsi argues that custom processes provide competitive advantage ("our secret sauce"), while Johnson counters that this phrase represents dangerous business thinking.
The resolution lies in recognizing that while core construction processes are largely standardized (contracts, RFIs, submittals, drawings), the 20% that differs can still be accommodated through platform customization.
Organizations need to honestly evaluate which processes truly provide competitive advantage versus those that benefit from industry standardization.
• Security Certifications Have Become Table Stakes for Government and Infrastructure Work – The emphasis on FedRAMP authorization, StateRAMP compliance, SOC 2 Type II certification, and GSA schedule inclusion reflects a new reality in construction technology.
These certifications, particularly important for FEMA disaster recovery work and government projects, require significant investment and expertise to achieve and maintain.
As Ralph Barsi notes, partnering with platforms that have already done this "heavy lifting" provides immediate compliance benefits that would be nearly impossible for individual organizations to achieve through custom development.
• Future-Proofing Requires Modular Architecture, Not Predictive Planning – Johnson's Lego system analogy explains how modern platforms differ from traditional software built on fixed foundations 20-25 years ago.
Just as you can't add five stories to a building with a five-story foundation, traditional software can't easily adapt to new technologies. Modern PaaS solutions allow components to be pulled out and replaced with newer technology, enabling adaptation to changes in funding, regulations, and project requirements.
This architectural flexibility is more valuable than trying to predict specific future needs, especially given the rapid pace of change in construction technology and the varying requirements across different jurisdictions and project types.
Transcript
Keith Kajiya (00:07):
Good morning. Apologies for my delay getting here. I'm Keith Kajiya, the president of SafeWork, and we're a program and construction management firm based out of here in Southern California. In fact, you have two Californians here with myself and Ralph, and I don't know where you're from, Nicholas.
Nicholas Johnson: I'm a Georgia boy.
Keith Kajiya: Oh, okay. I'm sorry, but we're thrilled to be here today. SafeWork is a PM/CM firm. We're largely in the transportation space, in the vertical markets and municipal markets as well. I think one of the other things that we do is we're part of a homeland security initiative, so we do FEMA disaster recovery work. That's a little bit different for the firm, but we're based right here out of Anaheim in California. We have an office right here in Los Angeles, but I'm thrilled to be here today to talk about the great debate about software.
Keith Kajiya (01:02):
This is kind of close to me because I've implemented a few systems in the past. I've done this for decades now and I've been involved in actually writing software for a client for a $2 billion wastewater program, although that was like 20-some-odd years ago before we had kind of an evolution of technology. I've also implemented off-the-shelf software as well.
And so I know as an underpinning of every successful program throughout my career - I've delivered over $40 billion of work - one of the underpinnings of those successful programs, frankly, is selecting that right kind of PMIS solution, whether it's off the shelf or homegrown or something else. And so today is a great debate about which one might be better.
So let me introduce our illustrious panel here. From Georgia, Nicholas Johnson, who's a veteran of the construction software space. He was an integral part of the first cloud construction technology service offering. With him is Ralph Barsi, also a fellow Californian, although from the Bay Area. So welcome Ralph.
Ralph Barsi (02:12):
Thank you.
Keith Kajiya (02:13):
He's no stranger to technology himself. He spent more than two decades helping grow software-as-a-service companies. So basically Nicholas will be representing the argument of buying commercial software off the shelf, and Ralph will take the argument of why you should build your own software platform.
So take your gloves off, get ready. The bell is now ringing. Ding, ding! And Nicholas, let's go with you first to kind of represent why should someone consider buying software off the shelf?
Nicholas Johnson (02:49):
Thank you, Keith. I appreciate it. I am now actually in my fifth decade in this industry.
Keith Kajiya: Oh, you're older than me then.
Nicholas Johnson: I am older than you. I'm probably older than everybody in this room. Well, we'll see. We can compare notes afterwards.
In those years I've had a lot of conversations. I've done a lot of work in the software space, had literally thousands of conversations with hundreds of owners and I'm completely convinced that buying software off the shelf is the way to go. And that's what I'm here to argue for today.
Nicholas Johnson (03:53):
First of all, digital solutions off the shelf are ready. You can get started right away. There's not a lot of waiting period. Turn it on, go. That's why they call it off the shelf. It's ready for you to go so you can have an immediate impact on your projects.
There's so many good reasons I had to take some notes here. If you buy something off the shelf, there is extensive legwork that's been done on your behalf - work that you don't have to do that's required to build a good system, a good project management information system.
Those companies that develop these softwares have done that research for you. They've spent the money that you don't have to spend as a construction builder or a construction owner. You guys don't have to worry about those things.
Instead, you have the opportunity to tap into industry best practices that have been proven out. The moment you say go, on top of that, you're working with software that is out of the box and built on those best practices.
It's intuitive and it's easy for people to learn and for people to use. It's been used over and over again. It's been refined, and that expense is often forgotten when you think about creating custom software and about the training that goes with creating custom software.
Nicholas Johnson (04:47):
If you use something off the shelf, there's a market of people that are ready to use it for you. But if you do it yourself, you're going to have to create your own manuals, your own videos, your own tools. You're going to have to have a help desk. Are you prepared to do all those things?
Not to mention that you'll need a permanent staff to take care of this. You talk about the expensive software - think about the human cost that comes with keeping that up and keeping your team on board with that.
Finally - maybe not finally, but one other really important point - what you buy off the shelf is scalable and it's maintained for you. These systems that we talk about have been on the largest projects in the world. They're proven, they've stood the pressure of the job site over and over again.
The cycles of technology are growing and evolving with the times whether or not you're able to keep up with that kind of innovation in-house. So while my colleague here would like to lock up your precious company resources in years of development, you can clearly see the obvious benefits of buying one of these solutions in lieu of building it yourself.
Ralph Barsi (05:49):
Look, come on. I'll start by saying obviously Nicholas is a warm, kind, sharp individual, but when it comes to building versus buying, the guy's wrong. I mean, there's a host of benefits and advantages to building custom software in-house. I could talk through a handful of them in an attempt to quiet Mr. Nicholas over here. But the bottom line of building it yourself is to stay in control of your operation.
So quick story. My teams are in the business of driving large-scale capital projects and building magnificent infrastructures. We've bought off-the-shelf or out-of-the-box ERP offerings for project management before and it was a nightmare.
Couple things. Number one, we were promised features and functionality, Nicholas, that simply wasn't there when we implemented it.
Nicholas Johnson (06:55):
So you're calling me a liar.
Ralph Barsi (06:56):
I might be. Here's an example. We looked through some of the industry best practices that it supposedly included and discovered it lacked basic Construction 101 bells and whistles. So it couldn't tell the difference between a change order and a back charge. The requirements were initially framed up by us and they were already outdated and depreciating, and on and on.
So we began to take ownership and build what we needed in-house. The immediate benefit that we saw was that things fell into place the way we wanted because we've always done it that way.
Nicholas Johnson (07:40):
Those might be some of the most dangerous words in the business world: "We've always done it that way."
Ralph Barsi (07:46):
Hey, you know what? Let me finish. That makes it a good reason.
Nicholas Johnson: Let me finish.
Ralph Barsi (07:48):
Doing it ourselves has always given us a competitive edge. It's been our secret sauce.
Nicholas Johnson (07:56):
I think your secret sauce is a little overrated. I've tried it. It's not that good. I mean, the truth is we talk about the secret sauce of your company and you do things so differently from everybody else, but you know what? Ralph, contracts are contracts. An RFI is an RFI. Submittals are submittals. A drawing's a drawing. It's all pretty much the same.
We don't really do things that much differently. We haven't done things that much differently for a long, long time. I think this idea that you have some great secret sauce that gives you a competitive advantage is just really overplayed.
Ralph Barsi (08:37):
What do you think about this, Keith? You want me to give you a little bit of insight into why I think this?
Keith Kajiya (08:46):
I'm trying to track where you guys are now because you gave me this five minutes ago.
Ralph Barsi (08:51):
Well, hey, I'm going to give you some insight, Keith, and everybody here in the room into why this guy's wrong. Alright, so first things first. If you want to drive cost efficiency and effectiveness in your organization, you've got to build it yourself.
Typically, as those who've bought software before know, contracts come with a very small licensing fee, but monstrous implementation fees, services fees, support fees. Now I'm not sure about you, but if I try on anything that is one size fits all, it never fits.
Nicholas Johnson (09:27):
Listen, peep squeak. I know a little bit about one size fits all, and all those things you just rattled off - those are things that you're going to have to pay for. Your company's going to have to create resources that you do not have today in order to do those things you just talked about. Do you have those people on staff today?
Ralph Barsi (09:46):
We might.
Nicholas Johnson (09:47):
Are they going to be free when you have to hire them?
Ralph Barsi (09:50):
They might be.
Nicholas Johnson (09:51):
Yeah.
Ralph Barsi (09:52):
Look, say you've got a feature request...
Nicholas Johnson (09:54):
Well done, Junior.
Ralph Barsi (09:55):
Let's say you've got a feature request for the software company that you've just bought from. Any idea how it's received or prioritized or addressed or how quickly all of it's done? Me neither. It goes into the abyss. Look, on top of that, it takes forever to implement.
Nicholas Johnson (10:12):
And you're telling me it's not going to take forever for you to build it yourself from scratch? Is that going to be a quick process? And by the way, once you've built it, you are going to have to implement it.
And by the way, those little changes that you ask for - most off-the-shelf products give you the ability to tweak the software to kind of make those minor improvements that you want off the shelf. Doesn't mean you have to use it exactly the way it is.
Ralph Barsi (10:41):
Well, look, to us off the shelf is like grabbing a book off the shelf. It contains the same words for everyone. Sure, there are benefits to standardization and sure, it might expedite your ROI and streamline some processes, but you still don't get what you want. You get what they give you. Look, there's nothing standard...
Keith Kajiya (11:08):
Okay, I think that's enough because I've actually found where I am in the script right now. Well, Nicholas, would you care to respond to Ralph's diatribe there?
Nicholas Johnson (11:21):
I'm not sure I care to, but I guess I'm going to have to. Listen, it's just not rocket science, Ralph. You're in the business of building great things. You build ports and transportation projects and healthcare facilities. You don't build software. You don't know how to do that.
You know which way a door is supposed to swing open for egress, but do you know what a user interface is supposed to look like? Do you have people that can help make really good software? Are you just going to throw something up on the computer and then have your folks suffer through it, continually be training them?
Keith works with clients that have thousands of users on their projects. How are you going to continually train them if you're doing this yourself and you have no documentation, you got no staff to do that? You're just wrong about this.
Ralph Barsi (12:15):
You create it yourself, Nicholas.
Nicholas Johnson (12:19):
All right? Again, who on your team's going to do this creating?
Ralph Barsi (12:22):
Nobody knows your operation better than you do and better than your people do. Straight up.
Nicholas Johnson (12:34):
Keith, you're going to have to help me here. I just can't get this through to him.
Keith Kajiya (12:38):
You guys are changing the script again, aren't you?
Nicholas Johnson (12:44):
Ralph, I think it's like this. If you try to build it yourself, you're going to fail. So what you need to do is buy it off the shelf and then be able to massage it the way you need to so that it can mimic the processes that your company does, rather than have your company mimic the process that the software did.
Ralph Barsi (13:11):
To do that, you've got to be constantly tweaking and updating your user training and guidelines.
Nicholas Johnson (13:16):
That's what I said.
Ralph Barsi (13:17):
Well, there would need to be certain core aspects of the system that didn't change, like a common user experience and an intuitive interface.
Nicholas Johnson (13:27):
Well, if you're trying to find the common thing, it's not going to fit your company's business process. So I think you pretty much have to do those things yourself.
Ralph Barsi (13:37):
Yeah, Nicholas, as you can clearly see the correct solution to the problem of digital transformation and construction is to buy a system that is off the shelf and build around industry best practices.
Nicholas Johnson (13:49):
You're absolutely wrong. You've got to build it yourself.
Ralph Barsi (13:53):
No, I'm serious. It decreases time to ROI. It's easy to use. It can scale with your business.
Nicholas Johnson (13:58):
It'll never work the way we do business.
Keith Kajiya (14:01):
Did you guys just switch positions? Now I'm really confused where we are.
Ralph Barsi (14:06):
Oh man. Oh yeah. I guess we did. Help us, Keith.
Keith Kajiya (14:09):
Well, since you guys can't seem to hold your own ground and I'm totally kind of lost in my script here, I'm going to switch gears with the audience and talk about the approach that we've had at SafeWork.
There was a point in time when we were somewhat system agnostic - whatever the client was wanting, we could adapt to that. We can certainly do that, but a lot of clients wanted us to provide guidance on what that solution should frankly be. And as we looked at the market, and as I have said, I built systems, I've run systems that are off the shelf.
I think both of them - because they were flip-flopping - it's because there are good things and bad things about each. But what if you could have both and combine both of those aspects where you could buy something off the shelf but still had flexibility to adapt to your own specific workflows for your own specific needs? Track the color of money if that's an issue, all those things that are custom to each type of program and project for each type of owner.
Keith Kajiya (15:28):
What if you had a platform that could do that? And as I looked at the market for what those solutions would be, the idea of a platform as a service - or is it PaaS - with that low-code application platform? This is very technical jargon that you've given me.
Nicholas Johnson: It is kind of technical stuff.
Keith Kajiya (15:31):
But the bottom line is to get the best of both worlds, right?
Nicholas Johnson (15:33):
Exactly.
Keith Kajiya (15:34):
Is to have the flexibility, the platform where you're not full-blown having to hire programmers to develop things from scratch, but still have the flexibility to adapt it to your own workflows.
And so from a company perspective, as the president of the company, I thought that kind of flexibility was key for us to be able to pivot to different types of clients, different types of owners, to provide different types of solutions without having that heavy spend of a full-blown custom system. But at the same time, having that flexibility to roll something out.
That also enabled us as a firm where we had clients say if it's an educational client, a transportation client, a water client - where each of those separate markets are distinctly different in the types of things they might be tracking - we could customize our own solution for those clients from a company perspective. And when we repeat business for an education client, for example, 90% of our solution is prebuilt for an education client basically, right? That's kind of what we've seen as the advantage.
Nicholas Johnson (16:31):
Keith, let me use... I've got a visual aid I want to share with everybody. As a matter of fact, I think everybody in the room has a visual aid. This is a platform as a service. Okay, mine's from Google. It's called Android, and Google created this platform that other people can write on.
So they focus on the most important things that the platform has. So they built a few apps on it. They built the phone app - I expect this thing to have a phone app. They built the text app, the camera app, and a few more. I'm sure I don't even know what all they built on here, but I have like 250 apps on this thing.
Nicholas Johnson (17:11):
And Google didn't build the Delta Airlines app that brought me here, or the Hilton Hotels app that helped me stay here. They didn't build the LinkedIn app that's going to help me connect to all you folks afterwards. They didn't build the solitaire game that I play when I'm waiting on the bus somewhere.
They built a platform that others can build on, and that's the same that a platform-as-a-service offering for a project tool does. They focus on the platform itself and those core apps - cost management, document control - focus on those things and then allow the users to either extend those applications or to create brand new ones. So that's really what we're talking about here when we talk about platform as a service or low-code application platforms.
Keith Kajiya (17:48):
Thank you for that technical explanation. I'm an iPhone user though.
Nicholas Johnson: It's a platform called iOS.
Keith Kajiya: Perfect. Well let's talk about then, Nicholas, having no development bottleneck.
Nicholas Johnson (18:04):
Alright, so with a platform like this, because the end user can actually modify the application itself or you can create a new application or you can hire an ecosystem of people to create new applications, you don't have the problem that traditional software-as-a-service companies have.
It was one of the things when we founded our company - we researched for five and a half years before we decided how we would build our technology stack. It was important because we'd done this before at a company called Constructware. Again, the first internet-based project management tool that was revolutionary, changed how we did business.
Nicholas Johnson (18:54):
We'd done this before, and when we sold Constructware to Autodesk, our wishlist of client improvements - things that people like you had brought to us and said, "This is an idea that will help our company" - and we would review that and think, "Yeah, that's a good idea. That could help the industry. We'll put that on the list."
But with software as a service, the software author is the only company that can edit the software, add to it, change it, enhance it. So we were the only people in the world that could enhance Constructware. Therefore, when we sold it to Autodesk, our wishlist was 2,200 items. 2,200 things that we wanted to do that you all had asked us to do.
With a platform as a service, the platform company can focus on the core applications and allow the rest of the world to create what other specialty apps or differentiating apps that you want. So our wishlist always now is just a few items because if it makes sense financially, you'll do it yourself or you'll hire some partner to do it, and you'll have it in short order.
It's called low-code, no-code software. So we have interns that write apps in our house. Really easy to do. Don't want to overstate that, but it's not hardcore coding as we think of software development. So it pretty much eliminates this bottleneck of development.
Keith Kajiya (19:57):
As far as these apps though, you have some that are prebuilt if you will. So if I am a transportation or a water client or an education client or a hospital client, there's set tools that you built initially that maybe address a number of my needs. From a company perspective, we've done that to tailor those to our clients. But I know you've offered that.
Nicholas Johnson (20:12):
It's a great example, Keith. Yeah, we do have the ability to create these kind of defined packages. So think of them as off-the-shelf packages. We have them - we built, with our California clients here, we built a K-12 package specifically for K-12 schools. We've built one for transportation.
I say we built one for transportation - actually it was a partner company that built it. So we can't know everything about everything and we can't hire all the smart people. So we have a partner, a smaller company that knows transportation. They built a suite of apps just for transportation projects that include things like right-of-way acquisition.
We have a suite for healthcare, for hospital projects. Another partner company, a different company that knows healthcare construction, built that out. We got a suite of P3 applications for a P3 project - two dozen different applications specifically for the governance of a P3 project. Again, we weren't the expert in P3, but we had a partner company that was. They developed a suite of apps. Didn't have to wait on us to do that. The industry created it because there was a need for it. That's what the platform as a service allows us to do.
Keith Kajiya (21:30):
Enhanced security. Why is that important, Ralph? Why do I need all the security?
Ralph Barsi (21:34):
Well, as Nicholas was showing off his Android, which I would argue is an antiquated phone versus the iPhone. But anyway...
Nicholas Johnson (21:42):
Wrong again, Ralph.
Ralph Barsi (21:44):
So you get the benefit...
Nicholas Johnson (21:45):
They're both California companies though, aren't they?
Ralph Barsi (21:47):
Absolutely they are. I'm kind of teasing you. But you get the benefit when you've got a platform, for example, that's FedRAMP certified, making progress earning StateRAMP certifications, might be involved in the GSA schedule, might have SOC 2 security compliance in place.
By using a platform that has all this at its foundation, you as the user get the benefit of a lot of the heavy lifting that was done to earn these certifications. So that's just one or two benefits.
Nicholas Johnson (22:23):
It's a good point. It leads us into this next topic of conversation that we've built a platform different from... again, five and a half years of research before we actually had a product in our company at Kahua. That was important because we wanted to solve some problems that had not been solved before.
Our platform is built like a Lego system. It allows us - back to the security issues and other technology issues - it allows us to actually pull pieces out and replace them. Again, the problem with traditional software as a service is it is like your construction project. It was built on a foundation, and most of the offerings in the market today were built on a foundation 20 to 25 years ago.
Nicholas Johnson (23:11):
And we all know if you put a foundation in for a five-story building, you can't come back later and add five more stories on top of that. Your foundation won't support it. It is hard. It is fixed.
With a platform-as-a-service offering, you're actually able to pull components out and replace them with newer technology. That's allowed us to be the first FedRAMP-authorized project management information system with the full suite of tools for both cost control and document management. We're the first one in the industry.
We're also StateRAMP. That's becoming more and more important here in California. StateRAMP is a cloud computing security standard that state agencies are beginning to require, and even cities and counties are doing that here. This county and city of Sacramento are both using the StateRAMP. So again, it's that base technology that allows us to quickly and easily interchange those parts.
Ralph Barsi (23:56):
I would add one more thing with respect to future proofing because it's the slide we're looking at. We've heard a lot just in the first half of this day about doing things to prepare for in perpetuity, to plan for the future.
Obviously we kicked things off this morning talking about the Los Angeles Olympics in 2028, which will be here before we know it. We heard about the infrastructure plans with EV vehicles, and it's all planning ahead, planning ahead, planning ahead.
So it's really important that you realize there's an ecosystem of partners out there that have done a lot of this heavy lifting or might know some of the nuances that your organization might not. So having a future-proof platform gives you access and exposure to that ecosystem and then can serve as an extension of what your future planning looks like.
Nicholas Johnson (24:48):
We have had a lot of conversation about the future here this morning, and we've had some conversation about what it looked like in the past as well. And the way we do business today is not how we did it 10 years ago, and it's not how we will do it three years from now.
Things will change. Funding will change things. Regulations will change things. Some of your companies - some of you are owners and you represent a fixed property, a fixed location. Others of you are service industries, contractors and designers, and you go where the projects are. And that means the projects are in different venues with different regulations and different requirements. So you have to be able to be that kind of nimble and flexible that your technology needs to support your decision to do that.
Ralph Barsi (25:34):
So you've all been generous with your time. Thanks for having us today. Have a good rest of the day.
Nicholas Johnson (25:39):
Thank you. Thank you, Keith. Great job.