Had a great time catching up with everyone, and meeting new
people this year. Autodesk University (@autodesku) continues to grow and add value to the
attendees, and it’s the best run event I attend every year. This was actually a
light year from me from a teaching standpoint, but the feature class on
Managing BIM Projects without Going CrAzY was a blast to teach this time. Even
with a couple of minor technical hiccups on my part, the online portion seemed
to go off without a hitch (with all 6 users watching…grin). It gives me good
vibes about the Virtual events for the future, and I think these can easily be
expanded…provided the conference location can handle the bandwidth. That was
the only real hiccup this year – with so many online applications, and users
pinging the AU app like mad, we did bring the whole network down at least once.
A couple of observations – the crowd varies from year to
year, and while last year’s event seemed to have more entry level users, there
was definitely a more forward thinking and sophisticated user mindset at this
event. And Autodesk leaders, including CEO Carl Bass, and CTO Jeff Kowalski,
played to the future visions of the users pretty well in the opening keynote.
One item that made me think a little harder was a comment
made by Jeff, about how, at some point, our creations need to learn how to work
more naturally (is that right?) towards each other, instead of being “dead”
creations that symbolize a static point in time. He made his point by talking
about how he wants his clothes washer to communicate with the dryer, and know
when the wash is finished, so the dryer can pick up the task from there.
It’s a great idea to have this type of vision moving
forward, but here’s where the “but” comes in. We, the users, can’t help Autodesk
move this vision forward if they can’t get their current products to
communicate, much less coordinate, with each other now. There’s a million
examples, but the discussion came up in an Expert Elite luncheon on Thursday.
One of the users asked Jeff when he could expect to see the same passion for
the civil products that he was demonstrating in his explanation about 3D
printing, and how computers can handle the tasks of designing structures and
parts best.
At that point, I attempted to rephrase the question, by
stating that you can’t get to appliances talking to each other if you can’t
accomplish the goal of having a Revit pipe recognize and connect to a Civil 3D
pipe on their own now. That’s where the technology is now, but it’s doesn’t
work in the Autodesk product line.
Part of the problem is the wide variety of solutions
Autodesk offers, and the fact that the different divisions within the company
now, such as buildings, infrastructure, manufacturing, etc. are still very “silo”
based. Here’s a simple example: Right now, in AutoCAD MEP, if you want to
associate information from a light fixture to be associated with a space
object, you simply add an anchor object. This creates the relationship between
the parts, and allows you to link shared information between the parts.
In Revit, mechanical equipment can only recognize limited
data that’s embedded into the programming – for example, the circuit name and
number is automatically associated with the equipment, but that’s it. You can’t
easily tie other electrical data – such as the section number that associated
with an electrical circuit for a motor control center – back to the equipment.
Other examples include horsepower, circuit ampacity or wiring in an associated
conduit that’s connected to the equipment.
It’s not that Autodesk can’t develop, or even have that kind
of programming available. It’s the fact that it’s not there is where the problem exists. And with the new Dynamo
programming language available, we’re still a long ways off from having the
tools we need to get to this level of optimization – whether it’s Autodesk, third
party developers, or our own in-house personnel developing the code.
Almost every company I’ve worked for – including ours –
still struggles with overcoming these silos, and being able to address the
needs of their partners in design without having to take a lot of extra steps.
But the fact that Autodesk recognizes the fact that these interconnecting relationships
are key to their future is important. It’s just a matter of the company’s
leadership to develop and push these goals back to the development teams.
And it’s not for want – Jeff’s key comment back to the crowd
was that he was simply a visionist, who was on our side and pushed the same
ideas back. At some point, you have to get the roadblocks out of the way, and
get the communication and goals directly tied to each other – and develop the
features in the products we need day in and day out, at the based product line
level.
A360, BIM 360, Field 360, Simulation 360, and other cloud
based products represent the cloud-based tools to help make the more complex
communications possible. But Autodesk should not get too involved in the
development of these present and future applications at the expense of their
core product line.
In other words – don’t look past the sliding glass door so
far that you break your nose trying to get out of it.
Back to AU – it was one of the best events I’ve been to with
Autodesk in a while, and the opportunity to meet Carl and Jeff was definitely a
high point (sorry, guys, if I drooled on your foot). But it was just as
important to me to meet the people that came into my classes, and participated
in the topics that I’m passionate about. It was great share that passion, and
hopefully I could help them overcome some of their fears, discover relevance,
and change their methods to get the message out (thank you, Mike Lee for those
words and ideas – be the change!).
Next year – super excited about being back at the Venetian
and Sands Convention Center, my favorite venue. The crowds will be large, and
the people motivated – let’s see how far we can get in the next 50 weeks…
Merry Christmas!
David B.
