Software, services, and expertise for the business of shipbuilding.

        • Achieve a Quick ROI
        • Sliced implementations and our expertise means a benefit from day one, without a lengthy setup.

        • Integrate, Collaborate, Re-use
        • SSI’s Open Shipbuilding Platform gives you a future-proof source of truth for your shipbuilding projects.

        • Change Management
        • Get visibility into changes, understand the impacts, and have the right information at the right time to execute the change.

        • Adapt and Innovate
        • Create a local or virtualized shipbuilding environment for your global distributed workforce.

        • Changing from Another Solution
        • SSI makes it easy to switch from other platforms and keep your existing data.

        • Design
        • The most significant opportunities to impact the cost of building and operating a ship are found in the design and engineering phase.

          Initial Design  |  Basic Design  |  Detailed Design

        • Build
        • Even a smaller shipbuilding project is immense in scope and scale. Manage the challenges that are unique to ship construction.

          Prepare  |  Fabricate  |  Assemble

        • Maintain
        • With the majority of a ship’s life taking place after it’s been built, it’s crucial to ensure that the organization has a clear picture of the vessel at all times.

          Digital Twin  |  Repair / Refit  |  Operations

        • Nexus
        • SSI Nexus is a community for users, creators, & implementers of SSI software.

        • SSI Certified Training
        • SSI Certified Training allows SSI users to access detailed training exercises, materials, courses, and certifications.

        • SSI Blogs
        • The SSI blogs are your place to get insights from our CEO into the intersection of shipbuilding and technology, see how shipbuilding is moving forward, and keep up with SSI news.

          Lighthouse Waveform  |  Shipbuilding Solutions

        • ShipConstructor
        • A complete line of solutions for the design, engineering, and construction of ships and offshore projects.

        • EnterprisePlatform
        • Tools to connect and share data across every system in the shipyard and make information available.

        • ShipbuildingPLM
        • The only truly shipbuilding-specific product lifecycle management (PLM) platform.

        • Company
        • Learn more about SSI and our leadership.

        • Locations & Contact
        • You need a partner with a global presence.

        • News
        • The latest on SSI and shipbuilding.

        • Events
        • Join us at our next event, conference, or trade show.

        • Partners
        • Learn more about our Platform and Development Partners.

        • Clients
        • See the industry leaders who trust SSI.

        • Careers
        • Help us make the business of shipbuilding possible.

July 22, 2014
ShipConstructorTechnology

Fileless

Last week I was following #ENOVIAEverywhere on Twitter and was very intrigued by some comments mentioned about zero-file (file-less, data-driven) environments. There even was a panel focused on just this topic. Here are some of the tweets from some of the people I follow.

Fileless1
Fileless2
Fileless3

 Data-driven architecture is something I really believe will be the future of all modern software including CAD/CAM solutions. Files have been great and have served us very well but in today’s and tomorrow’s environments, they add a lot of unnecessary complexity. The use of files was a way we could capture information in a package which allows us to very basically categorize our work in consumable packages which help us organize our work as well as share it. However with today’s much more comprehensive applications which can do all that plus much much more, it is making files less useful and in some cases complicating our tasks.

The current reality

Projects are getting larger – Today’s projects are not only getting bigger, we are modeling and capturing more information per component. This results in many more relationships, associations and data which need to be consumed in manageable chunks. The days of providing extra information which may not be relevant (what I call noise) to a specific task is long gone. Files do not provide a comprehensive context of the information we need to consume to take action.

More collaborative and distributed environments – In today’s projects there is a higher need to work with teams which are not collocated. There also is a need to collaborate with all the stakeholders within a project. This might be within the organization or external. Files do not provide a great method to share and collaborate with other team members, especially when change is continuous and dynamic throughout the product development.

More concurrent engineering– This relates to the above two points; however, it itself deserves a mention on its own merit. There are many levels of concurrent engineering and on every project we try to squeeze the timeline, forcing each phase to overlap even more. This means we require better solutions and processes to support this ever increasing concurrent engineering. Files really impede concurrent engineering by only allowing one person to work on a single file. Files usually contain many more components than what is being modified by this single user. Therefore, the current user is blocking concurrent work by other users if changes are required in a portion of the file which is not being edited.

Product data model has many more relationships – Many of today’s software applications rely on parametric methods and/or associativity to improve propagating changes throughout the model. These relationship may or may not come from the authoring tool which can add to its complexity. Files do not always contain all the relationships of the components represented in the file, therefore contradicting the assumption that the file is the container of all the information for the components within it.

Finding information is difficult – This is a big issue and sucks up a lot of our very precious time. There have been many different types of solutions (PLM/PDM/etc.) for solving this challenge; however, the benefit comes from extracting the information from the files and making the information more available to the user. Files used to provide good-enough structure and categorization to our data. However, with the amount of files we generate today, files alone are no longer good enough and that is why there are many solutions that are just focused on file management.

What my crystal ball is telling me

crystal-ball

Disclaimer: I think my crystal ball has some bugs as it is not always correct.

In the short term I do not see purely file-less environments. However, we will start seeing more zero-file solutions. Files will continue to be a significant part of our life but there will be significant transitions away from files as the main source of storing content. Now this does not mean we will not use files per-se, it just means we will be using files in an abstracted intermediary paradigm.

The reason I think this will be the case is we currently have too many processes and tools which are file-focused. This will require some incremental steps to allow users to work in a similar environment but have the underlying technology abstracted from the user. So the user may think they are working with the same old file but the file will really only be a representation of what is in the product model and could be 100% recreated at will from the data in the product data model.

My crystal ball is really fuzzy on the future of the solutions focused on solving the problems we have with files without changing the definition of what a file is. If the above prediction is correct, then these file-centric solutions are solving a problem which will no longer be there without files. There is a possibility of them evolving with this new trend.

Closing remarks

I am sure we will continue to hear more and more about file-less solutions or information centric architectures. The push to the cloud will also drive this as how often do you deal with files in a cloud solution…very rarely. The reason is because we, the users, really do not care about files, we care about getting access to the information.

Files will continue to be part of our environment for the foreseeable future but will lean towards:

  1. Visualizing the model using current technology
  2. Integration and interfacing with other products
  3. Reduce  disruption of current workflows, processes and tools

Even with a file-less solution there is an opportunity for software providers to create a strategy that leverages all the current tools and more importantly skills of the users in our current environment. The change in strategy should not significantly affect end users since software providers should be looking at ways of abstracting the underlying technology.

If anyone has any information related to the Zero File panel discussion at the Enovia Community, I would love to hear about it.

 

Post Comments

  1. beyondplm says:

    Denis, I agree with your short time vision conclusion. People won’t move into fileless environment overnight. Just look on what happens between Office, Office365 and Google. At the same time, in long perspective, we will see more situations that not requires “file” based work. Some of my thoughts about that is here — CAD, PLM and Future Cloud File System (http://beyondplm.com/2013/04/07/cad-plm-and-future-cloud-file-systems-2/).

    1. Denis Morais says:

      Thanks for sharing your post, it was a good refresher for me.

      Disqus (the commenting platform I use) included the ‘)’ in Oleg’s link which makes it a dead link. I do recommend readers to checkout Oleg’s thoughts on this subject:
      http://beyondplm.com/2013/04/07/cad-plm-and-future-cloud-file-systems-2/

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The reCAPTCHA verification period has expired. Please reload the page.