Addressing Interoperability | A Tech Conversation

In strXur - US by Michelle Wright

Interoperability—a hot topic that poses important questions: Can the business-critical technologies we rely on work together? And are tech leaders listening to the needs of their customers?

During her round table interview at AECX, Bluebeam VP Sasha Reed met the statement that hackathons exist because the tech industry doesn’t build the right solutions or create systems that “talk” to each other. Knowing that tech had a rebuttal, she invited technologists from Procore, Trimble, Fieldlens and Bluebeam, along with a common customer, to discuss the challenges software companies face while striving for interoperability, and how the tech and AEC industries may be more similar than meets the eye.

The transcript below is lightly edited for clarity from the video version above.

Sasha Reed, VP Strategic Development, Bluebeam

Doug Chambers, CEO, Fieldlens

Will Lehrmann, Director of Product Management, Procore

Marcel Broekmaat, Market Manager/Project Control, Trimble

Kris Lengieza, Director of VDC, Stiles Construction

Matthew Gotterer, Sr. Manager of Strategic Development, Bluebeam

Sasha [Voiceover]: Keeping up with a rapidly changing industry is the challenge facing the AEC community. The role technology plays is no different, and consistently serving the specialized needs of an entire industry is one of technology’s biggest obstacles. Behind the scenes at the 2016 Bluebeam eXtreme Conference, I invited technologists from Bluebeam, Procore, Fieldlens, and Trimble, along with the common customer to discuss the challenges tech companies face while trying to collaborate without losing their competitive edge.

[Roundtable interview begins]

Sasha: Thank you so much for sitting down here today! I really wanted to have you all here so that we could have a conversation about interoperability. I recently had a sit down conversation where I met with the founders of the AEC Hackathon and I asked them a question about why the AEC Hackathon was created. As I listened to their response, my first thought was that, as a technologist, I’m pretty sure there’s a rebuttal! Let’s listen to that:

[Cut to video clips of AECX panel with AEC Hackathon founders]

Damon Hernandez: The AEC Hackathon was started because of the miscommunication between tech people and the people from the built environment. How do you bring together these two groups to where the industry is really defining the bull’s eye for the technologist? Not just a direction [of], “I think it’s over here.” This is my pain point, solve this problem.

Paul Doherty: AECX and the AEC Hackathon would not exist if they [the tech industry] were doing it right. This is the watershed mark that we’re no longer just going to change our ways, or have to go to a university to figure out how to use a tool, right?

We’re talking about the real integration of process, technology, and the outputs. Whoever can figure that out; either on a job site, as an individual, or as a company— those are going to be the winners in this new world.

[Cut back to interview]

Sasha: As you hear the definition as to why AEC Hackathon was created, what were some of your ideas? Doug?

Doug: In the second quote I hear frustration, perhaps around the learning curve with respect to some of the technology out there. And I share that frustration! However, the quote around the bull’s eye… there is not a bullseye. There’s a lot of bullseyes. There’s not only one universal truth out there. We need a lot of different solutions to a lot of different problems.

When we hear our customers’ pain points, we don’t go build that exact thing to solve that pain point. We try to figure out how we can align a bunch of pain points together so that we can efficiently build something that solves all of them, or at least as many of them as we can get.

Will: I actually really liked, the sentiment about trying to solve problems. That’s the way we try to think. When you’re building product, there’s really two ways you can fail. One is that you don’t talk to your customers at all. You think you have the right answers. You think you can build the best solution. But without going out and understanding what you’re solving for and what you’re trying to achieve for your customers, that’s going to be a failure.

The other way you can fail is if you become an order taker as a company, and you only listen to this exact feature that they want, or hey, can you mimic this process digitally for us?
And those often become pretty bad products as well, and I think the answer really is what he said, is we have a problem. This is the bull’s eye and then, and as you mentioned, there, there’s many bull’s eyes, right? And we’re trying to find them all and prioritize them as best we can.

But at the end of the day, it’s really about solving the problem. That’s our responsibility as software vendors, to go out, talk to as many customers as we can, truly understand their problems, aggregate those together, and then try to do our best to solve them.

Marcel: There’s an interesting phrase in there as well— I watched the, the whole (video interview) earlier. But it says that you need to have no fear about process change. Well, that does not exist in reality. If you operate with a profit margin of 2-3%, on average, then you don’t want to dive in and change your entire process.

Kris: You know, we need to do a better job as, as customers communicating to the technology companies, of, “What are we really trying to solve? What are our real big problems?” And not necessarily, “What are the features that we need?”

Sasha: As we talk to customers, what we’re hearing, and I’d like to from you as well is,

“How come you [technology companies] don’t speak to each other?”

Which brings up the idea of interoperability. How would you answer that?

Doug: We do. (LAUGHS) Actually, Chris is kind of the fire starter there, the customer saying, “Hey guys, talk to each other.”

But I think most modern companies are talking to one another. And those that aren’t, they don’t get it.

Will: The customers are really driving this a lot, as well. They’re really getting tired of point solutions and having to not only manage their projects across 10 different pieces of software, but they also have to train people across 10 different pieces of software. And what they want is a single solution. Now there’s never going to be a product that does everything they ever want. So what we need to do as a community is come together, focusing again on the problems that they’re trying to solve and present them with a solution.

Marcel: I think there is a willingness from all of us to, to have open APIs, Application Programming Interfaces, but that doesn’t solve it. You can open the doors, but how do you know where to walk when the doors are open?

Will: Good point.

Marcel: Standards are needed to make that easier for us. If I’m calling an RFI with a certain set of attributes, then I’d like to send that over to Bluebeam without having to translate it.

Kris: [It’s] that data dictionary, that common language. You know, so much of what we’ve talked about is us being able to communicate as customers to the technology vendors and being able to kind of speak the same language, and we don’t. But I think we’re a lot closer than we actually realize we are, because you guys are dealing with a lot of “owners,” as I would call them, or a lot of customers. And we hate jobs when we have 10 owners making 10 different decisions! And you guys hate developing software when you have to have 25 different people telling you what to do. So we have the same frustrations, but we just don’t necessarily always communicate them well.

And what’s interesting is that you said that we’re looking for the one solution, and I don’t know if that’s necessarily true with all the customers. Cause I’ve come to realize there’s never going to be one solution that’s going to do everything I want, right? So that’s why I am a customer of every single one of you, because each one of you does something unique that is good.

Matthew: The motivation is here, and the tools are catching up to be able to execute on the motivation I think that we’ve all had. In concert with end users, I think it’s an exciting future for all of us, really. We don’t have to do anything in isolation; we can really solve the solutions for the community collectively.

Sasha: As much as we’re friendly, we’re frenemies in some ways, because there is that business case for competition. How do you discipline yourselves internally and in order to not fall to FOMO

or fear of missing out? How do you discipline yourselves internally to know what to focus on and what to leave?

Matthew: It’s a new paradigm for the software and tech industry to be able to invite those we saw as true competitors to the table.

So, the more we can be honest and up front and transparent with the process to all parties involved, I think that starts to break down the walls and helps us create those solutions collectively.

Marcel: I think that all of us want to focus on our strengths, but we’re often asked to do the contrary, because you have to include adjacent areas as well, in order to make it a smooth experience for the customers.

Kris: Yeah, you do this great, but we’d love to see you do this.

Marcel: Yes, yes.

Matthew: I think we have to be honest with our capabilities. We’ve all said we can’t build it all. So on that point, we call in the right people for the job. They sort of create the solutions for the end users at the end of the day.

Sasha: Will, out of everyone on this panel, you’re the true technologist, meaning you didn’t necessarily come from the AEC industry into technology. You’ve been in technology this whole time, and probably you’re very much aware of FOMO, and how do you help with Procore and their focus?

Will: Well, I think

first and foremost, you have to be really disciplined about what your company does.

What’s the value of your product and what problems are you trying to solve, first and foremost?

Focus there. If you try to do it all, you’re going to end up having a lot of solutions that don’t really solve the problem, that weren’t really well thought out and that don’t make your customers happy, and you’re going to lose. And then the other piece is,

yes okay, so maybe they’re a competitor. Maybe they’re a partner. There’s that blurred line that we experience here as we try to work together. But I think at the end of the day, you’re probably going to have a bigger chance of losing as a company if you don’t work with the others in our industry,

because at the end of the day we’re all trying to solve the same problem. If you’re the one that takes your ball and goes home and says, you know what, I’m not going to participate cause they’re my competitor and they’re my competitor, then the customer doesn’t win. And if the customer doesn’t win, definitely the software vendor doesn’t win.

Sasha: Doug, [you’re] kind of the newbie on the block here. You recently made some pretty hard decisions, changed course a little bit and streamlined the interface [of Fieldlens]. Tell us a little bit about what caused you to make that decision.

Doug: Simplicity is everything. It’s essential for the set of problems that we are trying to solve and for the types of people that we’re trying to solve them for. It’s really got to be a very simple solution, so we simplified the application. We took away features. Kris yelled at us. Other people yelled at us.

Kris: But my users have given feedback that it’s much nicer and much easier to use.

Doug: It goes with what was said earlier, which is if frenemies didn’t exist, if platforms that handled the more traditional project management flows didn’t exist, then my customers would be asking me to build them and demanding that we do. They wouldn’t have those solutions available to them, which means that I’d fail at what I believe is the fundamental problem that Fieldlens exists to solve. I think the word discipline was used earlier. That’s how I feel about this problem. You have to be incredibly disciplined.

The best thing you can do as a software vendor in this space, just like the best thing a contractor can do in some scenarios, is say no. “No, Mr. Owner, we can’t do that because if we do that it’s going to screw up your schedule, or your cost, [etc.].” And if you can say no to people and you build that relationship with them, there’s a lot of respect that ensues, and you get a better product for that, and you get happier customers.

Sasha: The correlation between the software developer and the general contractor, there’s a lot of parallels that can be drawn there.

Much like we had after the 2008/2009 financial crisis, joint ventures were all the rage all of a sudden. I saw trailer jobsite banners with two names side-by-side that I never thought I’d see side-by-side. And it was this great agitation or this great depression kind of idea that caused this integration— these joint ventures that showed, hey, we have better value together.

It’s the same, for the technology companies sitting up here.

Another parallel is, it’s almost like a general contractor who takes an owner into a BIM CAVE and says, “Hey, here’s your building, here’s how the sun’s going to track over that building. Here are all your finishes. Doesn’t this look fantastic? Let’s go out to the job site!”

And the owner stands in front of a dirt hole in the ground. And they’re like, “Where’s my building?” Well, okay, well first we have to dig a hole. Then we have to put some rebar down and then we pour concrete, and, oh yeah, that takes 30 to 32 days, depending on the weather. And once that cures, then we can start building.

[It’s] very much the same for technology companies. There is a process.

Marcel: Supply chain.

Sasha: (LAUGHS) Yes, exactly, very similar! So

how do you see the similarities between our customers and ourselves as technologists?

How do you see that similarity really helping us to solve some of these really complex challenges better together?

Kris: Well, it’s interesting, another parallel is that we share an industry certification. There’s an industry certification out there called the PMP, which started, really, on the software and the technology side. But then it started to get adopted by the construction industry because we realized it aligned. So we’re literally going through the same process of how to procure, how to price, how to schedule, how to build. You were talking about schedules earlier, getting things done. And very similar to a construction product, you got to have a schedule to get it done. Otherwise it won’t get done—it just keeps getting kicked down the road.

So I think the sooner that we as contractors, subcontractors, construction industry folks, start to realize that we really do speak the same language—it may be different words, it may be different acronyms, you know, LEAN, AGILE, they’re the same thing. We just need to get together and go, “Holy crap, we’re talking the same language here.” Let’s just slow down a little bit and see if we can align it and kind of make the road together.

Doug: You don’t build a feature in reaction to a customer saying, “I need that thing, I need that thing!” You build the feature in reaction to, “Hey, Kris, what’s the type of problem you’re trying to solve here,” and then 10 more conversations [about] “What’s the type of problem you’re trying to solve here?”

So the idea that Kris and I kicked around like a week ago was,

imagine if before you bid a project on a construction site, you had a conversation with the owner about their goals for the building, as opposed to plans and specs. Because if we built to plans and specs that were provided to us by our customers, I’m sorry, but the apps would be terrible.

Right? And yet, in the construction industry, that’s what we do, right? We build buildings based on plan and spec.

Sasha: When we talk to technologists and software companies and we talk about the future, we talk about lofty, big goals. Each of you sitting here, though, are very actively involved in the development of the technology. So you’re seeing very close up the challenges of pushing the technology forward, and I’m sure for each of us, a very jam-packed roadmap! So

what should our customers be looking for in the future from us as far as us speaking to each other or working together?

Marcel: I think

data structures

are going to be the most important. Applications are how users will interact with those data structures, but it doesn’t matter that much anymore, because if we get our data structures to work together, then you can build any subset of functionality on top of that.

Will: And it’s super important that we continue to involve the customer in these integrations.

It used to be unheard of that you’d have two software vendors on the call with the same customer talking about how those two companies can work together to solve their problem,

and I think we need to do more of that. We’re seeing a lot of the platforms being opened up, open APIs. And I think that’s a great start because it means we’re all headed that direction.
But the actual, tangible things that we build and the solutions that we build, like you said, we have packed roadmaps. Time is very important. We need to get together everybody involved; from the customer, to the vendors, to all the different roles from the customer side; and really truly understand the issues, and then go out and build something that solves for it.

Matthew: It’s really quieting the noise of technology to a certain degree. I mean, I think we’re all motivated for success for the end user. And the end user has to focus on what they do, not the technology itself. So if it’s you’re building a building, you’re able to engineer your submittals, you’re able to answer your RFI much faster, so you can keep on schedule and you can have a happy owner at the end of the day.

We’re now putting those parts and pieces together as an industry to really see that come to fruition.

I think this is a really exciting time.

Doug: We’re seeing customers build it themselves. And I think that construction companies, as they hire more and more young people coming out of school that have technology backgrounds, even if they’re not full-time technologists. I think you’ll be shocked to see what will be hacked together at these construction companies between the different softwares that are up here andmany others that are out there. I absolutely think we’re going to see it. We are seeing it.

Will: Yeah, I love that point. If we can enable our customers and other vendors to do the work themselves, you’d be surprised. Small startups will come and start building on your platform. Your customers will come and start building on your platform and sometimes you’ll come across that one particular piece of work they’re doing where you say, “Why aren’t we doing that?” (LAUGHTER) But in general I think it’s pretty encouraging that the industry’s going that direction.

I’d say part of it, too, is that

the construction industry in general’s been kind of underserved from a technology standpoint over the past decade.

And now that it’s really starting to get an influx of new technology and new companies popping up, the customers are starting to realize that, “Hey, there’s options out there! We’re really in control.” Which should be the case, and has been the case in many other industries. And now I think they’re starting to understand that, and it’s now up to us to really bring that truth and start building stuff that actually solves their problems.

Kris: Well, the problem is we underpay.

We don’t pay enough.

We don’t spend enough money on the technology.


Will: You heard it here first!

Kris: Yeah, listen, I’m that guy. I said it.

Let me turn the tables and just ask one question. Sasha asked what you need from the customer, or what can you [technology companies] do. But let me ask what more can we give you?

You said we’re starting to do some of the developing on our own. And I’ve hacked together some things and I can get it to work, one item one time. But that’s not a solution. But I’d hope that I’d take that to one of you guys and go, “Here’s the proof of concept that I want. Make it so that somebody won’t laugh at the code.” And go from there. What more can we [the customers] give you in a more meaningful way?

Doug: I think one of the things that we experience quite often is just the industry’s fear of trying something new. Don’t be afraid to try something new. It’s okay. Give it a try. If it doesn’t work for you, try something different and you’ll figure out what the right solution is for you. That will help us, because hopefully through that process you’ll give us feedback.

Matthew: Keep bringing it to the table. Keep listening. There is a constant continuous improvement with this process. So if we abandon that, we’re all going to lose. So the more we stay engaged both ways, we’re going to come up with solutions.

Kris: It’s funny you say that, cause I was in a meeting this morning and somebody made a point to bring up that a feature that I’d asked for a year and a half ago was coming out in a new release. You have to stick with it. You can’t just walk away after a short period of time and go, “Well, they don’t listen.”

Sasha: We are more alike than we are dissimilar.

That relationship you build with an owner you hope has longevity to it so you get more projects and you build that long-term relationship. So over time, you learn to know each other and your businesses very well, and you know exactly what to expect from that. There’s a certain amount of trust that comes with a really good partnership.

Marcel: Exciting times.

Sasha: Absolutely, so thank you so much. Appreciate it very much.

Will: Let’s go build some integrations, huh? (LAUGHTER)

Sasha [V/O]: By the end of our conversation, it struck me that we had come full circle. The tech industry needs the feedback from the field, just as much as the field needs specialized solutions from the tech industry. Only through dialog between the field and technologists can the evolving challenges of the industry truly be met.


The post Addressing Interoperability | A Tech Conversation appeared first on StrXur by Bluebeam.

Source: StrXur

Addressing Interoperability | A Tech Conversation