THE PLM STATE

The PLM State TBT: If we're not in Kansas anymore, why is everyone talking about silos?

Welcome to this week’s TBT blog. Since Tuesday’s post,
PLM Tech Tips: Encryption, Repositories, and SQL Oh My!,
has a nod to the Wizard of Oz, I couldn’t resist sharing this post from 2010.

tornado_nguyen_bigGiven the Wizard of Oz theme, I knew eventually I would have to pull out the "we are not in Kansas anymore" line. I just didn't expect it so soon. Last night at the keynote for Oracle OpenWorld, we got two very different visions from Ann Livermore from HP and Larry Ellison, obviously from Oracle. Interestingly enough, they both talked about silos but had very different ideas about what to do with them. Silos are very prominent throughout the farmlands of the Midwest and everywhere else we have other silos. Silos of information exist throughout the IT landscape and most hardware and software solutions advocate blasting these silos like a F5 Tornado. HP's Ann Livermore's discussion followed this traditional message. She was advocating using HP's latest offerings to consolidate and modernize companies’ IT infrastructure and to "eliminate silos of information". This is fairly standard stuff. In fact, I myself have been known to utter condemnation of silos from time to time in my Product Lifecycle Management (PLM) presentations. The idea of a single source of truth and one giant centralized system appeals to many executives and particularly CIO's in companies both large and small. So, I found it very interesting when Larry Ellison shared a different vision on this topic. Larry, or as I like to call him, the "Wizard of Redwood City" (Cupertino would be more accurate but Redwood City sounds more like Emerald City), was discussing the merits of Oracle's new toy the Sun Exadata Server and how these systems can be deployed throughout a company's infrastructure and link silos of information rather than consolidate them. The idea was to minimize the trauma of consolidation and distribute load throughout the company yet present a federated and united environment. This Goose gander.jpggot me thinking about, of course, what else? PLM. To use another farm analogy, "what is good for the goose is good for the gander." If a federated data structure with united silos is a good idea for data servers (and I think it is) then why wouldn't the same principal apply to PLM solutions? This blog will explore this topic and highlight the potential pitfalls of the one-giant-system and why a more pragmatic approach will yield most if not all the same benefits without the risks inherent in the giant PLM/IT undertaking.

Mr. Ellison's target for the most part was IBM in this portion of his presentation. He singled out the giant do-it-all servers from IBM as "useful in their day" but basically obsolete in the modern climate. Larry sited the InfiniBand architecture and the ability to deploy the Sun systems locally to tailor the needs for each location and ensure performance was optimized based on need. Instead of over provisioning for worse case scenarios companies can deploy exactly what they need at each site and use the hardware's features to tie it into the other systems. Setting up a consistent architecture throughout the company is the key and this gives you the benefit of being able to minimize upkeep. The virtualization model Ellison conveyed is right on in that his servers allow "guest" OS's to reside on top of a virtualization layer. You can either use Solaris or Linux. I guess hoping for a Microsoft option would be too much to hope for. Not everyone is ready to cast off the shackles of Microsoft but the vision he shared is sound. Use the same hardware throughout your company linked by high bandwidth networking tools and leverage virtualization to maximize flexibility when it comes to your servers and you gain the benefit of a unified architecture without the overhead of massive eggs basket.jpeghardware. Sticking to the farm theme, your eggs are not all in one basket. Moreover, deploying something like this is much easier to do given the fact that most companies already have a "sprawl" when it comes to data and systems. It would be much easier to use this approach than to try and completely overhaul your current environment. While I am sure Oracle would prefer you leverage their hardware and software solutions to employ this strategy, you could effectively accomplish the same thing using Intel-based hardware and VMWare or Xen. You may not get the performance the Sun hardware offers since there are some nice features built around flash utilization, network optimization and disk architecture but you would have a robust, flexible and sustainable environment going forward.

This contrasts with having giant centralized wracks of hardware all connected via a LAN or WAN, one big data center for everyone in the company. I know the idea around this can be attractive. Not having to distribute you IT resources throughout your company is definitely a plus. Not having to duplicate servers through a multi-site company is nice, but as Ellison pointed out, in the end it is more affordable to buy a bunch of small servers than one big one. Another point he made is that you distribute points of failure and their impact. I was reading a story in a book called Groundswell by Charlene Li and Josh Bernoff from Forrester. Christmas time 2006, Linksys experienced a catastrophic phone failure when an earthquake cut off access to their main support center. Fortunately, they had developed alternative means of support via the web that alleviated the impact of the failure. The take away from this is that if you centralize everything in one place then you become vulnerable to some sort of failure. These things happen all the time, but if you are centralized, the impact can soar. Having your data centers distributed spreads the risk over a larger area and minimizes the impact.

Another issue with the giant server approach is one size does not fit all. Most companies have diverse needs throughout departments. Accounting's requirements versus engineering's varies greatly. Accounting might have a large number of small files and might be pushing large numbers of transactions whereas engineering might have larger files but not as many users. The same applies to PLM. Configuration Management, Accounting, Manufacturing and Engineering and many other departments need to be involved in new product development and change management but their requirements differ greatly. Putting one system in place that tries to meet all of their needs is very challenging. Often you are saddling one part of the organization with functionality and complexity they don't need or dumbing down the system to where it lacks the features it needs to effectively perform. Beyond this you are forcing companies to implement system using a big bang approach that is very costly and difficult to accomplish. The PLM and ERP landscape are littered with cautionary tales of companies who have attempted to "boil the ocean". Given the natural evolution of most companies you end up with "pockets of automation" that function pretty effectively by themselves. Unfortunately, the overall enterprise lacks visibility and consistency which hinders their ability to effectively utilize resources over multiple facilities and departments and prevents companies from effectively collaborating on product development. When companies try to address this issue by bringing in a new solution they often create more issues by mandating the new system. What they are after is better communication throughout their organization what they get is a giant consulting bill and very unhappy employees.

Why not apply Ellison's principle for data servers to PLM? Instead of trying to deploy a massive single system for everyone, look at each group's needs and deploy applications that can link together like the Exadata Servers. This way you can deploy the appropriate functionality in each organization and not force feed them something that is a better fit elsewhere. You eliminate the need for giant PLM and data migration projects and you still address the base requirement. Oracle already does this to a certain extent with their overall application strategy. They have different platforms for CRM, Analytics, PLM and ERP and numerous others that all tie together via their Fusion integration backbone. They also offer numerous integration points to other third party solutions so you can pick and choose you applications based on need. Other vendors should adopt this approach and open their platforms to allow companies to selectively choose aspects of their technology based on its technical merit and how it meets their specific requirements. Trying to force your customers into an "all or nothing" approach is ill advised and will ultimately fail for both the vendor and the client. The technology exists today to seamlessly tie multiple systems together just like it does to unite hardware. A shift in emphasis would allow companies to deploy solutions in a more logical and sound manner and lessen the risk for failure. This would accelerate the adoption of process improvement and automation solutions and increase their effectiveness across the enterprise.

Day one at Oracle and Larry has taught a valuable lesson. Instead of viewing silos of automation as bad things that should be eradicated linking them together is the sound approach. Putting giant PLM systems in place is like closing the barn door after the cows get out. Breaking up PLM into manageable chunks and selecting solutions based on their fit for specific parts of the organization can minimize the trauma of implementation, increase user adoption and ultimately make the difference between success and failure. Today will be a busy day learning more about Agile PLM's plans for the future. Thanks for reading and please comment below – agree or disagree?

[Edit: repost from 2010]

 Request Recording 

Subscribe to the ZWS Blog

Recent Posts

Request