Too Much Sand in My Granularity

DuneGranularityOut on the internets, in the fertile lands of the engineering blogosphere, a really fascinating debate has emerged about application granularity versus integration, specifically related to the Computer Aided Design (CAD) and Product Lifecycle Management (PLM). Are they diametrically opposed or are they complimentary? Initially sparked by Chad Jackson’s intriguing concept for a truly integrated MCAD/ECAD application which was then subsequently subjected to Oleg Shilovitsky’s unfailing eidetic memory, igniting debate over prior videos on integration and granularity. Chad’s thoughtful response explored the concept that integration can coexist simultaneously with granularity, and Oleg followed up with a second article, PLM Tools, Bundles, and Platforms. It’s all good stuff; having just caught up on this myself you’re now reading this as a consequence. Or maybe you’re doing it all backwards and started here.  Either way, let’s talk granularity in the year 10,191.

Chad Jackson defines granularity in his posting:

“Granular Apps offer a limited set of capabilities that are focused on a specific job. These apps are more accessible to different roles in the company because their limited set of functionality requires less training and retention in terms of how they work. They are valuable in the network of roles that participate because they are so accessible.”

There’s a key element missing in this definition, which I will get to soon enough. But when it comes to discussions of granularity all I can think about is sand, and how it gets into everything. Especially on desert planets. But here’s the deal about sand – if you bring it up to high enough temperatures you can make glass out of it, which is rather integrated in nature. But I digress. The main point is that software granularity is undoubtedly the future of engineering software. The monolithic dreams of the 90’s can finally be put to rest, to achieve goals in accessibility and specificity. The right tool for the right job. Cloud is the catalyst, but you don’t have to take my word for it, Oleg has a similar view:

“I  see a very strong potential in unbundling of existing large product suites. Take a piece of functionality, re-invent it, provide bigger value to a customer. Cloud technologies and future focus on data will be an imperative to make it successful. Vendors’ focus is shifting towards services. It is about how to satisfy customers each day. Selling of expensive bundles can be a thing in the past.”

True granularity is such a dramatic shift from the status quo it might as well be the wierding way. So holding your breath is not recommended. Can granularity coexist with integration? Sure, but not like you’re probably thinking. All the currently cited examples of granularity like 3DEXPERIENCE (you left your caps lock on, Dassault) or Creo isn’t granularity at all. But how can this be? Real granularity allows you to mix disparate solutions of your choosing, not whatever happens to be the default tool for that job on that specific platform. What we are seeing in today’s platforms is nothing more than:

(Integration + Granularity)^Same Vendor = Modularization.

Whether the tool is a separate app or truly a module in a larger app is nothing more than semantics. So what’s the missing piece of the granularity definition? It’s the elephant in the room, and that’s data openness. Truly unfettered data freedom, that exists for its own sake such that it can be interpreted and transformed by every granular app that deems it important, regardless of its origin. To be able to do this requires a massively parallel environment so different from today’s centralized one-at-a-time models that it’s not even funny. In the long term, it requires data and metadata decimation on a scale not yet realized as Al Dean described in his article Why Granularity Will Rock Your Future.

Let’s get real, however.   We’re probably deep in a Mountain-Dew induced hallucination (happens all the time) if we think a truly open and effective platform will just rise out of nowhere. It’s more likely to rain on Dune. No one wants to give up their platform. That’s where the money is made. Get a customer on a platform by way of one modular app, necessarily marry them to the rest. It’s ingenious, effective, and profitable. The platform is like the spice mélange. He who controls the platform, controls the universe.

A real opportunity exists in building an agnostic platform, where individual apps compete on their own merits in a truly egalitarian marketplace. Easier said than done, this is a monumentally difficult task and virtually impossible if the vendors behind the current tools aren’t interested. Compelling efforts like Cloudwork seem to indicate this is at least possible given a certain limited scope. There may be room to accomplish the reverse however, in relatively short order. Rather than wait for the mythical platform, innovative apps can instead try to bind to multiple popular platforms, displacing very specific pieces of functionality without disrupting the overall platform. While requiring extra groundwork up front, this is the ideal bottoms-up play – but usually ends in vendor acquisition rendering the whole exercise moot from a customer’s perspective.

Perhaps Chad is on to something in focusing on marrying ECAD and MCAD. Perhaps there’s room for a platform to let the two meet, but likely file format obstacles are just too difficult to overcome. An integrated ECAD/MCAD application might be a interesting exercise, but I don’t think it will change the world. I think we would have seen it by now if that were the case. Find a way, however, to allow a truly granular approach to this problem and you just might be the kwisatz haderach. Granularity is where we need to go, but we’re not there just yet.

  • Ryan

    So, is the platform the poison and the apps the cat?

    • Yes, kinda like that. Sting’s trying to push for more licenses.

  • Ross Bernheim

    We’ve seen this play out before many times with other classes of software. Two things mitigate against the integration of modular programs.

    Competition centers on exclusive features which don’t play well with others and provide a lock-in. This race bodes ill for interoperability between programs.

    The other is trying to monetize small applications with a limited customer base due to a lack of a full integration with other apps and the reluctance of users to leave their current platforms and have to learn a new program.

    The best we can hope for now is to have a list of features that can be exported and moved between programs and try to get the users to stick to those. (Lots of luck!)