Collaboration is vital to any engineering process, but the actual mechanics of such collaboration can vary widely both in theory and in practice. Not helping at all is the fact that the term itself has been long hijacked as a piece of technical vocabulary, serving to push new products and features in a protracted marketing war including PDM, PLM, ERP, and ECM, and now CAD. When we throw “real time” in there, confusion mounts as to what exactly that is supposed to imply. More specifically what does that mean for engineering? Do engineers want it? Will it work? Morpheus might say that collaboration is everywhere. It is all around us, even now in this very room. You can see it when you look out your window or when you turn on your television. You can feel it when you go to work, when you go to church, when you pay your taxes. For purely creative and/or artistic ventures collaboration can be organic, boundless. For engineering however, collaboration must necessarily be coupled with a critically important concept: change management.
Pop quiz, hotshot. There’s PLM data on a bus. Once more than 5 people interact with that data it becomes important. But if that data isn’t integrated properly, it blows up. What do you do? What do you do? We’ve long lamented about PLM complexity as a limiting factor to adoption, including the requisite wrangling to get product data moving efficiently across an enterprise in a loose federation of heterogeneous IT systems. For the most part, this has been the sole domain of data architects and development teams, wrangling robust SOA services onto ESB highways among a bewildering hodgepodge of enterprise data platforms, APIs, and disparate data models. But hopefully things get easier from here. One of the more interesting promises of moving PLM technology forward and into the cloud is handing over the integration data modeling keys to the nontechnical business side. Let’s try to get through this without shooting any hostages.
On this cold winter morning, the first day of January in the year of our Email twenty-two, we stop for a collective moment to think. By common reckoning it is the year 2015, a time once thought to be so far away that email would have been little more than a memory, long supplanted by superior communications technologies wrought by the steady, unrelenting march of progress. After all, we’ve been hearing the condemnation for quite some time: email is dead some say. Or perhaps it should be dead, crushed under a wave of new socially-oriented collaboration tools. Except it’s not. Twenty two years since we started calling email by its proper name, it thrives. It is one of the few things that everyone with access to technology interacts with on a daily basis. Email is everywhere. Email is King. Kneel before email.
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
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.
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.