architechure

Archive for May, 2011|Monthly archive page

Time is Money

In Time | Money | RTC North America on May 31, 2011 at 11:48 am

NewImage

How’s that rollout of Revit 2012 going?

Figured out Revit Server?

How about all the other stuff in the 2012 release?

  • New Features?
  • New Functionality?
  • Best Practices?
  • Latest and Greatest BIM-centric Technologies?

Well, there’s at least two options:

First, you read everything you can get your hands on (after hours of course) and dig around AUGI and other forums. Make sure that you get up to speed on any idiosyncrasies and gotchas. Then when you’re really sure you’re sure of how things work – or don’t – you start to roll out Revit 2012. And let’s suppose you’re managing an office of 30 Revit users and your trial and error process takes about 3 months.

30 Revit users. 30 billable hours a week. 12 weeks. $100 a billable hour. That’s about $1million dollars.

Or?

Second, you register for RTC North America and get up to speed NOW. Learn from those already using it (many of them since before it was in beta). Ask a lot of questions. Get a lot of answers. Then go back to your office and start rolling out Revit 2012 ASAP – confidently – not accidentally.

And because time is money, your attendance at RTC North America is going to set the office back about $3k (registration, flights, etc) and two business days (Wednesday night through Saturday night) of concentrated effort.

So let’s put this into perspective. For an investment of $3k you can have a positive impact on $1million in billable work over the next three months (or longer). In other words, 0.2% (that’s right – two-tenths of one percent) of three months billable work as an investment to increase productivity.

$3,000 out of $1,000,000.

So register today. And if your manager still isn’t convinced that you should attend and keeps telling you there’s “no budget”, well there’s always option number three: pay your own way.

And when you get there – pass along your resume to the office leaders and technology managers that are running their businesses so well that they insist their BIM managers attend RTC North America. Because time is money. And success isn’t an accident.

And those guys are hiring.

Hasa Diga Eebowai!

In Book of Mormon | Broadway | South Park on May 20, 2011 at 10:25 am

Check out the insightful Terry Gross / NPR interview with Matt Parker and Trey Stone (of South Park fame) on their creative process while developing Broadway’s “Book of Mormon“. In contrast to taking about a week to completely write, animate and produce an episode of South Park, their Broadway production took the better part of the last 7 years.

Most surprisingly?  It’s not two cynical hours of bashing either religion (broadly) or Mormonism (specifically).

Leave it to Parker and Stone to so successfully swim against the mainstream cultural current. The show isn’t about “religion”. It’s about having the faith to be illogically optimistic and hopeful in spite of all apparent realities. So I guess it is about religion. Or teenagers. 🙂 

I’ve downloaded the original cast recording on iTunes. Great stuff. On the down side? Justine is probably going to insist I start watching “Glee“.

http://www.npr.org/v2/?i=136142322&m=136436932&t=audio

Imaginaaaaaaation

In Monster Engine | Art | Comics | Imagination on May 20, 2011 at 8:33 am

What if you could travel back to a time where you had no limits on your imagination?

Like when you were a kid. And you drew like this:

Screen shot 2011 05 20 at 9 40 48 AM

But then you grew up and spent the better part of your life learning to draw like this:

Tp cad

But what if when you grew up, you kept going? Like this:

Screen shot 2011 05 20 at 9 40 10 AM

If you haven’t heard about “The Monster Engine” stop what you doing and check it out:

Really wonderful stuff about the power of imagination.

Or as Sponge Bob says, “Imaginaaaaaaation“.

So are you going to keep staring at your cream colored cubicle walls or what?

Sloppy Seconds

In Apple | Microsoft | Skype | Viber on May 10, 2011 at 12:55 pm

Hype logo

Wasn’t I just saying how it’d be interesting if Apple bought Viber and how established companies frequently grow through acquisition rather than innovation?

And today there’s this: Microsoft buys Skype for $8.5 billion.

My advice? Put down the keyboard and slowly, quietly step back and move away from Microsoft stock.

Microsoft Market Cap: $215 billion. On the surface they only paid about 25 times their market cap for Skype. And I really like Skype. Use it all the time. I’m one of of 663 million Skype users. Out of 663 million users? 145-170 million use it monthly. How many are paying customers? 8.8 million.

So Microsoft paid nearly $1000 per paying Skype customer.

But Skype had $860 million in revenue last year. Minus expenses? Profit of $264 million. Minus Skype’s $866 million in debt? Skype is still $422 million in the hole.

So suppose that Skype had continued on and in another two years, doubled their customer base and paid off their debt and generated and annual profit of $500 million dollars by the start of year three (not an unreasonable scenario). And suppose in three years time Microsoft paid $8.5 billion for Skype, a company (hypothetically) generating a clear annual profit of $500 million?

Then Microsoft paid 17x times Skype’s annual earnings for Skype. And even if Microsoft is able to double Skype’s annual revenue every year for the next 7 years, they’ll have just begun to pay off this acquisition.

And 7 years in internet-years is a really, really long time. 7 years ago, Microsoft’s market cap was over $300 billion. Now it’s about 2/3 that amount.

So why do I think this doesn’t bode well for MSFT? Because Microsoft would pay $8.5 billion of their hard earned cash (well, yours – if you’re a stockholder) to acquire Skype rather than innovate on their own. In other words, they’re now paying a premium to push the pedal down and try to catch up.

Apple introduced the iPhone in 2007 – after having designed the iOS, hardware, and App Store ecosystem.

Microsoft?

  • Didn’t have a “Plan A”
  • Doesn’t have the culture to innovate in the VOIP / mobile phone space
  • Conclusion: Unlikely to have the force of will to implement this acquisition

Pull up a chair. When existing companies consciously decide that there’s is going to be a culture of acquisition of expensive, established and unprofitable technologies in order to stay “competitive”, the future gets foggy really fast. Because it’s not about acquisition, or innovation. It’s about something even more important. Companies can acquire technology. They can even hire away great talent at a premium.

But you can’t buy relevance.

Please Give Me Another Chance! I Can Change!

In XYZ | ABC | 123 on May 9, 2011 at 4:37 pm

The last post resulted in quite a few well reasoned comments and even three phone calls (one international). It seems that I’ve struck a chord. Three questions repeatedly arose:

  1. What are you working on?
  2. Why makes you think existing software company X/Y/Z isn’t working on a disruptive solution to collaborate across domains?
  3. What about standards across platforms?

Thoughts:

First: I didn’t claim to be working on anything. But if I was, it’d have to meet the following criteria:

  • It wouldn’t be another Revit. Revit’s amazing. What’s the point?
  • It’d have to be about something unique, significant and as meaningful as Revit is to the design space
  • It have to be fun. Like the latest Flat Tires show (shameless plug).

Screen shot 2011 05 05 at 10 09 07 AM

Second: Because existing software company X/Y/Z creates evolutionary, not revolutionary technology. Why? Because Distribution trumps Disruption.

I can see you’re confused. You think it’s a conspiracy. Software company X/Y/Z have unlimited resources. Millions of monkeys. Shiny typewriters. Barrels of beer.

Well, you’re wrong (and you like conspiracy theories). Please allow me to explain.

Imagine you’re the CEO of successful software company with a few thousand employees. That means you’ve got thousands of mouths too feed, mortgages to make and braces to insure. And then there’s shareholders. Shareholders are worse than customers. Because if you miss a quarterly market projection by a even a few cents (over or under – they don’t care) and millions of dollars in shareholder value is going to disappear. Customers are stuck  – it’s hard to transition to new software. But share holders can sell your stock and buy another in a day. Which makes the share price go down even further. And it can all happen before lunch.

It’s also incredibly likely that your imaginary company has a few flagship products, and even a stable of applications based on that those products. And if you’ve been around a while (10 years or more), there’s probably a developer network that further increases the value and market share of your flagship product.

But in software years, a decade is a really long time. And after a decade, what your flagship products do is going to being overshadowed by what they don’t. Cracks are going to appear. And the rest of technology has evolved to the point that the questions your software once answered (successfully) have now created new questions – which your software can’t answer. It’s now become obvious that something else is necessary.

This is called an “Inflection Point”. Decision time. What do you do? Jettison the past and embrace the future or duct tape the present and hold on for a few more years? Do you put all your geniuses together and figure out how to create the “Next Big Thing (TM)” or hog tie the tiller and ride out the coming storm?

Here’s some real-world possibilities:

—————–

Possibility #1: You’re a smart CEO and you’ve already planned ahead. Knowing this day would eventually come, you’ve got another bigger, better, faster solution in the wings. For the past few years, a team of developers (quietly and outside of the public eye) has been working on the NBT (Next Big Thing) which you’re ready to unveil at the appropriate time.

What could possibly go wrong?

Doing this is really, really expensive. It means funding a team of people to develop, test and maintain software that the market is not going to be able to use for a long time. But you can’t let this new solution get too finished because if it’s too “done” it’ll be very complex. And without important customer input your new solution can evolve in a very wrong direction.

Note: it does (very, very rarely). One recent example was when Apple admitted OSX had been long ago ported to Intel hardware. But even this this was an evolution of their existing operating system (OSX). Not another OS entirely (like the transition from OS9 to OSX).

You’ve pissed off your customers. You need customer input to develop this stealth product. But word will get out; customers will talk. Whispers of this really cool thing that is being worked on. Way better than what you can get on the street. Customers will ask (a few will beg and ply you with alcohol) to help test it – but you won’t be able to let them. Because those customers will inevitably tell your other customers. And so on. Until you need a team of people to support customers you shouldn’t have using a tool that doesn’t exist and they’re not paying to use.

No developers want to work on it. Not the best and the brightest anyway. It won’t have any customers. It’s not generating revenue. It sucks resources from existing successful (even if technically “inferior”) products that the best and brightest do want to work on. In other words, the developing team that works on this NBT are leeches. And the moment the market takes a downturn, all those developers are going to be on the chopping block. What will you do? You’ll put the code on a shelf, tell HR to tell the developing team to pack their desks and go home. Maybe you’ll get back to their efforts when the market improves.

And what about those recently laid off developers? The last entry at the top of their collective resume is a product that no one has heard of, never got to market, has no customers and generated no revenue. Lovely.

Conclusion: You’ve spent a bunch of shareholder money on an expensive “what if” insurance policy that’s likely never to be successful. Start polishing your resume. Being a CEO is a bit like being captain on the bridge of a Klingon destroyer. If someone “kills” you (by creating uncertainty in your leadership) they get your old office chair while it’s still warm and covered in blood.

—————–

Possibility #2: You see the writing on the wall. Duct taping an existing flagship tool together for more than the next few years isn’t viable. And if you wait much longer, your competitor (existing software company Y or Z) might come to market with a compellingly better product. So after numerous (as in months) of internal meetings and hand wringing you decide to take the plunge and signal to the market that your presently available solution is old and busted, and a new solution is being developed that is nice and shiny. Old and busted vs. nice and shiny.

What could possibly go wrong?

Stop reading this and head over to Wikipedia. You need to learn about something called the “Osborne Effect“.

Re-read Possibility #1. You’re still certain that this time it’ll be different?

Start to build a team to build the Next Big Thing (TM). Let’s see, who are you going to put on the short list to staff the NBT? You want the best and brightest, right? Except they don’t all work on one team. They’re a bit spread out and work for different project managers. And those project managers really like having their “hypo” team members on their teams (“hypo” for “high preforming”). So you’re going to upset quite a few project managers to build this new team (as well as upset their existing projects). Okay – so why not hire from the outside? Turns out this is really difficult as well:

  • This new team will take weeks (if not months) to get up to speed, get over their quirks and become productive.
  • If they’re already productive, happy hypos – they’re already busy. Some of them are working at existing software company Y or Z. But some are living off previous winnings (through acquisitions). Neither hypo have to do anything they’re not interested in. So if you’re going to hire them away it will come at a premium (at least 30%) to get them to agree to let go of their present good thing to (hopefully) land on their feet at your new NBT. So you give them a way above market offer. And they submit their tell their boss they’re going to resign and immediately get an increase in salary above what you’re offering them to stay put. So you’ll have to offer more.
  • When you hire from the outside at a premium, word will get out and it’ll build resentment among your existing employees. You know – your existing hypos who’ve been busting their arses  for years for $X and along comes shiny new guy at $X+.

And then there’s sales. Your new product is going to build resentment within your existing sales channels because it’s adding friction to their sales efforts. Your NBT is intentionally meant to create obsolescence of a successful, flagship product. Now your efforts to create the NBT is making the difficult and stressful jobs of hundreds of sales people (and channel partners) even more difficult.

One last thing: you’ve just upset the vast majority of your existing customers. What?! Yup. That right. Because while a small percentage of your existing customers might be really excited about this new/amazing/incredible project being developed – a lot of people (including outside developers that make a living building tools that work with your existing product) have spent a life time mastering your present technology. They’ve built up status and expertise and careers in the process. And now your new efforts will level the playing field.

Conclusion: Creating obsolescence is practically untenable within an established company. You’re disrupting lives across your organization. You’re building friction in your sales engine. You’re upsetting your customers. And possibly your share holders.

Note: it does rarely happen. Steve Jobs did it with the original Macintosh. He sucked away the best and brightest and lots of resources from other successful products to develop a new personal computer. He flew a pirate flag (literally) and loved it. But had the Macintosh not been successful, the pejorative term “Macintosh” would have ended up a Wikipedia entry along the lines of “Osborne Effect”.

But in the back of your mind you also know that if you don’t create the NBT your company won’t survive in the long term, which will really piss of everybody…especially share holders. If only there were another way!

—————–

Possibility #3: Growth through acquisition. Although incredibly difficult, Developing disruptive technologies (see #1 and #2) is actually the easy part (just not within an established organization like existing software company X/Y/Z). There’s no shortage of great ideas. You know what’s really tough? Distribution:

  • Planning
  • Engineering
  • Testing
  • Support
  • Sales
  • Consulting
  • Marketing
  • Education
  • Legal
  • Human Resources
  • And on and on an on.

Startups are lean and mean. They’re not big teams. Big teams add friction. But since startups are small and agile, covering that list above is really hard. But we’ve already established that you’re running a successful software company. You’ve got already got the Distribution part in place! You offer the market stability. You’ve been around a decade or more – so you’ve earned the market’s respect and seal of approval. You’ve got what every lean and agile startup envies: and entire sales and marketing engine of resources ready to completely overwhelm the market with the NBT.

So you wait. And you put away a giant nest egg of cash and stock options built up over the years from selling your flagship products. Then you wait a bit more.

Eventually the NBT will come along. A team of scrappy entrepreneurs, eking a living out of a bit of venture capital, working 80+ hours a week will introduce something that is incredibly and overwhelmingly elegant in concept and use (even if a bit rough around the edges). The scrappy developers seldom see their families. They’re full of energy, focus and know that if they’re not successful – there’s no safety net. There’s none of, “it’s ok…try harder next time now go home and have a nice weekend and I’ll see you on Monday morning.” It’s do or die. For this team, every new customer success story is a cause for celebration because it represents their survival! So when their product – a demonstrably and compellingly better one – comes along, you wait a bit to see how the market responds. And you’re careful to watch the mindshare as well as market share:

  • Are their customers enthusiastic about this new technology?
  • Is the product overwhelmingly compellingly better? Is it unique?
  • Are you getting tired of hearing about this product during conference calls?
  • Is this new product starting to gain mindshare and create buzz?
  • Are you actually starting to lose market share?

If so, position yourself to acquire this new technology. Pull out the checkbook. Done. This solves the hiring process and getting new teams to gel together issue (they’ve likely been together for years). Yes, it’ll piss off some of your existing employees. But an acquisition is fast and quick; what’s done is done. As wounds go – it’ll heal nicely. Your existing employees will eventually get over it (many have come through acquisitions themselves). And a few will even position themselves to manage the new hires and teams.

And why will Scrappy Startup (TM) allow themselves to be acquired?

Because while they’ll have have developed a great new tool, they’ll have limited resources in with regard to the distributive aspects of creating a business. They’ve got an uphill battle. You’ve got market access and seal of approval.

Conclusion: This is not cynical. This is not conspiratorial. It’s math. How much will it cost to develop a new disruptive platform inside an existing organization? Millions of dollars – easily. Just to fly 12 people to a third location for a week long meeting can cost $30k! If you’re not careful you’ll spend a $1million / year in meetings alone!

The cost of developing a new technology in a cushy, established company? Figure $1million per year for 5 employees working on a new product in an existing company (salary and overhead).

50 people = $10million / year. They ploddingly work on the product for a few years and you bring it to market. And what if it flops? Or underwhelms?  Or get’s eclipsed by the agile efforts of a Scrappy Startup? And in the process, you’ve had years of endless meetings, diverted resources from successful flagship products, disrupted your business and pissed off your existing customers (and shareholders).

Remember that bit about Klingon space captains?

And that’s today’s lesson: Big things eat little things.

But every once in a while, fast things eat slow things. 😉

==========

Third? Up Next: Standards? We Don’t Need No Stinking Standards

Why Can’t We Be Friends?

In Blue Skies | Blue Oceans | Kind of Blue on May 3, 2011 at 2:30 pm

Carl

Hi. Glad you’re home. Long day? Sorry to hear. You may want to sit down for the next bit. I’ve poured you a cold one. Take off your shoes. Relax. You said some things and I said some things which is really difficult for both of us to talk about. And we need to talk. It’s not you, it’s me. It’s not that we’ve grown apart. It’s not that I’ve been thinking about seeing someone else. Well, sort of. And I really want to be friends. We can be friends, right? Take another sip and I’ll explain. There’s something I need to confess…

When Revit was released over 10 years ago – it wasn’t the best at anything. More than 10 years later, it’s still not the best at anything. But again, this really isn’t the point. Revit isn’t supposed to be the best at anything.

When I demonstrated Revit during sales presentations, people were very quick to raise the numerous objections:

  • 3DMax was a better tool for modeling
  • VIZ was a better tool for rendering
  • AutoCAD was a better for detailing and documentation
  • Excel was a better for creating spreadsheets and schedules

And you know what? They were right. And they still right. Compared feature to feature, Revit can’t compete with those kinds of tools. And even though Revit has evolved a lot in terms of functionality – those other tools have evolved as well.

But what many failed (or didn’t want) to understand was the value proposition of Revit was about the sum being greater than the parts. So while, over the last 10 years, Revit has significantly evolved from a feature comparison point of view, none of those individually superior tools could (or has) become an integrated design solution.

This difference can’t be overstated: what Revit afforded was not a superior set of individual features. Rather, Revit offered:

  • Overwhelming simplification of choice
  • Ease of use over complexity
  • Integration over fragmentation
  • Compelling advantage of concurrent information

10 years later, Revit remains the gold standard for integrating design to documentation. Yes, there are some rumblings at Bentley and Graphisoft…even Dassault. But a decade later, no one has yet managed a close second. Which is why (full disclosure) I remain a very bullish Autodesk investor. Because if you want to build a building, and you’ve hired someone to design it, you’d better hope that Revit is a significant part of the toolset.

So why the cold beer, slippered feet and relaxing iTunes? Well, I’m trying to let you down gently. Like I said, it’s not you. It’s me. I’ll continue…

Revit has integrated the process of design to documentation. But BIM is a much larger ecosystem. And although Revit represents the integration of design, the ecosystem of BIM; the processes between designer, manufacturer, builder and owner – remains incredibly fragmented. Of course the individual tools used in those domains have evolved over the last 10 years; meaningful and valuable functionality at the application level has been created.

But as we’ve all observed with the success of Revit, it’s not merely about the features or functionality of individual applications – it’s about ease of use and integration. It’s the integration between domains that has yet to be addressed. Here are a just a few of the the present challenges:

  • Exported and decoupled data
  • Distinct tools for designers, manufacturers, builders and owners
  • Lack of collaborative, concurrent access to project information
  • Bridging Intent (Design) with Content (Fabrication)

In other worlds, while individual tools may be sufficient, their combined use is untenable in terms of integration. Applications create silos. Exported data means that the everyone is working in separate versions of the truth; empirical information differs from emotive visualization. Efforts to analyze and resolve construction is distinct from ongoing design iteration. And by the time someone gets the “right” answer they’re usually exactly wrong because the design has moved on to a new idea.

Collaboration and Integration – the real promise of BIM – remains elusive and little more than a concept.

So what’s to be done? Pick one tool (many have suggested Revit) and evolve it into an all encompassing Design, Manufacturing, Construction and Owner toolset? I don’t think so. None of the tools that surpassed Revit in functionality could have evolved into Revit. Or had any one of them evolved, their evolution would have been indistinguishable from simply (if only it were that “simple”) starting over.

So I don’t believe that Revit is capable of evolving beyond it’s designed intent as a tool to resolve coordinated documentation. Yes – Revit creates valuable data which is useful outside of the Revit ecosystem. And other data can be brought into Revit (usually geometric context). But Revit isn’t the center of this ecosystem of geometry and data; it seems to orbit other applications (Navis, ProjectWise, etc) that in turn attempt to integrate data across domains.

Those of us that have worked on some of the largest and most complex BIM projects in the world know the challenges of trying to integrate design across multiple BIM platforms, applications and domains that presently exist. What to do if you’re using Revit for the Architectural design, but the best curtain wall consultant in the world uses Catia? What if the structural engineer uses Tekla but the MEP engineer is well-versed Mechanical Desktop? What if the best Interiors consultant is incredibly lyrical with ArchiCAD? Should we realistically expect everyone to stop thinking in their language of expertise and speak one language?

So what is really at the center of this BIM universe? Should we honestly expect real collaboration and integration across domains? Is it reasonable to expect our software and technology partners to create collaborating and integrating “best of breed” solutions?

I’m convinced that it can be done. But the challenges to discovering, developing, selling, marketing and implementing such a solution isn’t merely technical. There are deeply dividing cultural barriers.

And this is why we’ve grown apart. And I’ve noticed you’re on your third beer and getting a bit sleepy. And it’s not you. It’s me. Let me tuck this blanket around your feet. That’s better…

After 10 years, I think we can admit that it’s unlikely to ever expect all the world’s designers (and more) to agree use a single design tool. But at the same time it seem even more unlikely to expect any of our existing technology partners (Autodesk, Bentley, etc.) to create a unifying process or platform which, at a minimum allows:

  • Agnostic Aggregation
  • Multi-user / Multi-platform / Multi-OS
  • Concurrent Information – both Geometry and Data
  • Compute Intensive

The standards are settling; the technologies exist. So what challenges remain for our established technology partners? Only the challenge of dedicating the resources (money, people and time) to create a new, unifying technology which will eventually perceived as undermining and starving their successful, existing products. And if such a technology existed, it would also allow their customers to be able look over the fence and consider other platforms (present and future) made useful by such a development.

Christensen called it “The Innovators Dilemma“.

Or as someone once explained to me:

“It’s culturally untenable for an existing company to develop disruptive technology.”

In other words, while it takes an incredible force of will to deliberately make successful technologies obsolete, it’s even more difficult to do so from within the company that created the technologies you’re trying to make obsolete. Not to mention that the first efforts at integrating technologies may not even complete feature for feature with the individual technologies being replaced!

But once again, Revit usurped Max, Viz and AutoCAD not because it was the best at anything, but because was the best at everything. Sum vs. Parts.

So if we’re we’re ever to help realize the promise of BIM – the collaboration and integration across multiple platforms and domains, I’m convinced we’d better plan on getting started somewhere…else.

Sleep. Dream sweet dreams…

=====

Up next: Give Me A Second Chance! I Can Change!!!

Pencil’s Down

In BIM | BAM | BOOM on May 2, 2011 at 6:15 am

01 misaligned bridge 503

“Talk about unhealthy communication: a hospital uses GE call systems for patients, Philips Emergin as an electronic interface for notifications, Cisco wireless to connect communications devices within the hospital and Siemens for its main phone system.

Enter an iPhone pilot program for nurses, which helps them monitor patients and communicate with each other quickly across all of those platforms.”

So starts a brief article over at Cult of Mac that discusses a pilot program to integrate the fragmentation that has evolved in the medical space.

It’s a scenerio that we’re all very familiar with in the AEC industry. Revit remains the de facto standard for integrating much of the design. But the overall process seems uncomfortably fragmented. We still have to get the right information to the contractor – and then again to the owner. Along the way, we use one platform to design, another to render, others to provide critical analysis, followed by more tools to resolve construction, and then I suppose something else entirely to help manage the completed building.

Starting this week, I’ll begin a series of blog posts (about one or two per week) to discuss some of the challenges we all still face after a decade of BIM. Should we really expect to overcome the fragmentation that has evolved in the AEC space? What happens if we do?

Pros? Cons?

Hopes? Fears?

Comments? Suggestions?