Friday, March 17, 2006

The Right Mix of Features

More from OneTeamConference... A story of Product Management.

It's probably not appropriate for me to expose too much of the discussion here - but there was an interesting discussion I was involved with at OneTeam, and I think it is emblematic of the challenges all software manufacturers face when they have different "levels" of a product.

In this case, it was Vault (free, Data Management Software) and Productstream (real money, Vault + Release/Change Management, BOM, ERP integration, etc). They're down to the wire on the next release, and they're still not sure if certain features are going to be made available in Vault, or only in Productstream.

Why is it important? Well - the tough calls are when the features in question could potentially remove or reduce the compelling reasons for people to move from the (inexpensive/free) product to the more complete product.

For example, you can add a feature in Vault which is a great feature - but a side effect is that some people may use this feature in a way that allows them to implement limited change management - thus removing one of the compelling reasons to move up to Productstream.

Why would users do that? Well - users are fundamentally thrifty (my nice word for cheap) in many cases... They try to completely exhaust what is possible in the inexpensive product before moving up to a more expensive product. In fact, I've seen many cases where users invest far more in making something free work (often working badly) than it would have cost them to invest in the more advanced technology... Is it everyone? no - but in the SMB engineering space it's a very measurable percentage of the population.

In a kind of funny twist - I've been accused of doing that in the past with our Vault Access product (that is to say, the manufacturer getting miffed at a channel partner)... removing a compelling reason to upgrade by providing visualization and printing capabilities within Vault...

Maybe my views have changed a little over time, but here's my thoughts in the end:

  • Segment your markets - understand if some people just won't need the higher functions, and accept that.
  • Depending on your segmentation, you only owe so much to the "free customer"
  • If customers will reasonably make a "stop" on the free version before moving up, then make sure that there's enough there so that they can work (if going to Vault first is a step that it's acceptable to take - don't prevent them from going to Vault).

This has another potential wrinkle, late in the game... Because Vault/Productstream clients actually use the same API that developers have available - Autodesk will need to be careful not to just "turn off the buttons" in their client... Or else some developer is going to write something that implements this "hack" of release management.

I'm not sure if it was clear from this post - but I'm actually supportive of them pulling this feature back - so that it's only in the higher-end Productstream... If customers were going to this length to implement this poor release management - then they ought to be really addressing release management with Productstream - and Autodesk and the channel ought to be doing a better job of these Vault Power Users to convince them of that.

Back from Autodesk One Team

I just spent the better part of this week at the Autodesk OneTeam conference in Las Vegas...
And I'm trying to gather my thoughts that are relevant to this blog - but I think I have to expand a little bit...

Revit Building Systems
This is the first time that I had seen the new Revit Building Systems... And it's very, very, very impressive (at least to a non-building engineer like myself). Revit is really shaping up to be the hot package for the entire building design process. For those of you who aren't in the space, the term "Building Systems" refers to MEP - Mechanical (HVAC), Electrical and Plumbing. The "systems" that architects generally do their best to hide from your view - but that ultimately have a big impact.

Of course, from an API perspective - it still has a ways to go... we keep running smack into the edge of the envelope when we've been involved in prototypes - but it will get there.

As a side note on an API for the Revit Building Systems (RBS), while I'm pretty sure that there's no API - I can tell you that there are what seems like 1000 exposed parameters relating to RBS in the API... Things like RBS_PIPE_STATIC_PRESSURE... So that makes me think that at least the energy analysis applications will have enough to work with.

Friday, March 03, 2006

The New Productstream 5.0 API

While we're speaking of new APIs, the new Autodesk Vault/Productstream 5.0 API is out in beta... and I've had a preliminary look. (They do a nice job in this group with documenting the changes between releases, so they make it easy for me).

Vault and Migration of Apps
The Vault portion of the API has stayed generally the same, with only a couple very minor exceptions (a couple of additional parameters for whether to pull hidden files, some additional methods relating to the new security model)... Pretty easy to migrate any existing application forward.

Speaking of migration - if you're like us and you like writing apps that work across multiple versions of Vault/Productstream - you'll like the new InformationService webservice... It will query a server and tell you which version of Vault is running there, as well as whether Productstream is there or not (we could do that before, but only with .NET HTTPRequest tricks, because the Web Services used for the API were release-specific - so you got nasty SOAP errors when you tried to connect to the wrong version of Vault/ProductStream).

Security
The big thing in this release is the security model (that there is one - beyond your login)... Administrators can now define groups, as well as permissions at the folder level on groups or individuals). So the Admin and Security Service have been updated to reflect that.


Productstream
For Productstream, this is the release where they promise to start "settling down" - and not changing the API so much from release-to-release.... As with Vault 3 to Vault 4, they've renamed many (like 100+) of the methods and properties associated with Productstream.

They've also added support for some of the new Productstream features like Watermarking - and some nice utility functions for finding ReleasedItems associated with a given ItemMaster...

All in all, it looks nice (other than the massive rename) and I look forward to using it on this year's projects.

RevitDbg

I'd like to compliment Fenton Web over at Autodesk Developer Network for introducing a tool to help understand the Revit API: RevitDbg...

Similar tools have been developed on the AutoCAD and ADT side for some time - but this is the first time that it's been done for Revit... Fenton also gets style points for using Reflection in .NET - which lets the application look back at itself and tell you what it sees - very handy for explaining all of the datastructures associated with Revit (although perhaps a little slow when running against a gazillion possible parameters on every element - and I only jest a little).

The tool works by scanning the entire model (bad idea - it's on the slow side) or by scanning the selected elements and telling you all of the information associated with each element (down sometimes 10 levels in a tree).

It's simple but good - and it's the kind of thing that will make all the difference in whether people pick up the API and try projects - by letting them easily see if the information that they need is "in there".

New Revit API

While much of our day-to-day business is in the manufacturing world, we've been watching with interest the ongoing development of Autodesk Revit - which really brings the architecture and construction market into the modern age of CAD systems (after spending the 90s entirely in the manufacturing side, with pervasive 3D solid modeling, parametrics, associativity - it's been hard to look at where the AEC side of the world was).

In any case, Revit introduced a real .NET API in 8.0, and built on it in 8.1 - last summer. Autodesk is preparing to release Revit 9.0, which takes the API to a new level.

In Revit 8.1, the API was pretty minimalist - while you could query everything and update some things, you could create very little...

What you can do with the Revit 8.1 API:

  • Search Elements, Parameters and Data (and EVERYTHING in Revit is a Parameter)
  • Modify/Create parameters
  • Extract Geometry
  • Load/Place/Move/Rotate Family Instances
  • Create/Update Structural Elements
  • Access Room Data

What you can do with the Revit 9.0 API:

Create/Update:

  • Walls, Floors, Grids, Levels, 3D Views, Sheets, Drafting Views, Sections and Dimensions

(there's other odds and ends - and while it doesn't seem like much, this may be all we need to get some interesting automation projects going with it).

And what's more, Revit 9 API requires Visual Studio 2005 (Wahoo that's fun! but only because I've already purchased it - I'd be a bit mad if I hadn't yet).

Throwing my hat into the ring...

I'm not sure where that expression comes from, but I figured that I should probably start my blog before I'm the last person on the planet that doesn't have one....

In all seriousness, I've long been inpsired by the blogs of Seth Godin and Lawrence Lessig - and I've seen the growing amount of CAD blogs. I'd bet that I have the occasional interesting thing to say on the topics of Computer-Aided Design, and developing software that works with CAD, PLM, etc.

But you'll be the judge of that, won't you?