Adoption of Software as a Service (SaaS) solutions, present a challenging and often overlooked decision point for the modernization of enterprise applications, a last chance conundrum after which there is no turning back. The point of contention: software updates and upgrades. As discussed previously in They’ve Gone to Upgrade, the common SaaS philosophy of incremental and continuous updates, so popular in the consumer landscape, is presumptively thrust upon an unsuspecting enterprise. The traditional model of infrequent, monolithic updates is fittingly viewed as the work of dinosaurs, to be supplanted by the clear superiority of evolved just-in-time software delivery. The question of software upgradeability is too often a choice between absolutes. Choose the blue pill and the story ends, you wake up next to your old on-premise server instance and believe whatever you want to believe. Or you take the red pill, you stay in SaaS wonderland, and fall right into a rabbit hole of continuous updates. It’s probably time to stop all this enthusiastic pill-popping. Continue reading
One of the central axioms of Product Lifecycle Management is information re-use. Re-use prevents re-invented wheels by capitalizing on product knowledge that predates your particular problem. Provided you find what you’re looking for, of course. That’s where the trouble starts. Most of us know that PLM search is often about as fun as a late afternoon dip in a Sarlac pit. It’s never long before someone begins to lament about the Googlization (that is so not a word) of PLM search, a passing thought usually birthed in the throes of an intense thirty-minute session unearthing the latest funny cat videos from the depths of the interwebs. Why can’t uncovering part information be as easy as finding your favorite quotes from Firefly? There have been many attempts to emulate just that, but they may be missing the point. These aren’t the search engines you’re looking for.
How we work is fundamentally changing, not just in engineering, but across all disciplines involving information management and collaboration. There’s an escalating revolution in enterprise software, where the grand unification dreams of the past are now being set aside. Spoiler alert: there really can’t be one system to rule them all. It’s not that we haven’t tried to forge the one system in the fires of Mount Doom. But in many cases we tried and failed. Instead of a single-vendor monolithic solution, there’s renewed emphasis on specialization within a larger heterogeneous mix of options. Tools in collaboration, communication, and analysis that aren’t bound to their masters like their monolithic precursors, but instead flourish in an alliance of interconnecting and distributed technology. And here we all stand, at the turn of the tide.
Out 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.
Last time we basked in the hypothetical bliss of CADtopia, imagining a Computer Aided Design (CAD) landscape devoid of today’s interoperability nightmare (and conveniently supervised by Jodie Foster). In that mental exercise, we were reminded that these bitter and largely inconvenient CAD realities persist due to seemingly insurmountable market forces. Whether it’s standardization efforts that can’t possibly keep pace with the explosion of modeling technologies and platforms, or vendors naturally resisting truly transparent interoperability on account of their own survival, we remain entrenched in old problems. It’s enough to make you seriously consider bolting some crudely designed exo-suit in to the back of your skull and going all Jason Bourne over everything in protest of interoperability injustice. Why can’t we all be citizens of CADtopia? So the question still remains, if the market cannot decide to change for reasons of self-preservation, can it possibly be coerced?
CADtopia must be a really nice place. All that endless storage, all those panoramic holographic displays, and not even a passing thought about CAD interoperability. Jodie Foster is probably on staff to ensure that all geometry and product structure information is passed along via a ubiquitous standard format. She remains ever watchful of unauthorized IGES use, or perhaps illegals translating data from one proprietary format to another. Violations result in revocation of citizenship, or in the case of illegals, the issue is efficiently resolved with armed robots, irritable mercenaries, or space missiles. Everything runs smoothly in CADtopia, and no one wastes any time re-examining translation chains or healing geometry. Then suddenly we wake up… Only to face the bitter reality: the persistent ridiculousness that is CAD interoperability today. CADtopia is but a dream.
Despite an endless ocean of advice on what to do (and not to do) in order to avoid enterprise implementation disaster, reality is often an imperfect one. Whether it’s a failure to understand the requirements, secure solid management support, evaluate the options, or install a Locutus equivalent to champion the transformation, mistakes get made. Some are recoverable with effort, others not so much. Ever wonder what happens if you happen to get it all wrong simultaneously, Titanic style? That kind of thing never happens, right? A Senate Committee on Homeland Security and Governmental Affairs has just proven otherwise and documented the truly horrific failure of the Air Force’s Expeditionary Combat Support System (ECSS) for the world to see. It’s subtitled “a cautionary tale” but it frankly reads with the same hopelessness as a squad of colonial marines holeing up against an entire colony of xenomorphs on LV-426.
There’s just a bit of hot-dogging going on in engineering these days and engineering change is right at the center of it all. Change is often regarded as the one guaranteed constant in engineering design. So it should come as no surprise that change is also central to cost and execution. Projects that execute well, handle change well. Those that struggle, often do so under the relentless weight of compounding change. As new Computer Aided Design (CAD) technologies continually accelerate the capability to change, pressure mounts to execute as fast as the technology will allow. Friction is growing as the simple ability to make a change increasingly outpaces the ability to manage change. They have a need. A need for speed.