Will GE give a birth to a new PLM company?

July 9, 2014

ge-datamanagement-initiative

Navigate back into histories of CAD and PLM companies. You can find significant involvement of large aerospace, automotive and industrial companies. Here are few examples – Dassault Systemes with Dassault Aviation, SDRC with US Steel, UGS with McDonnell Douglas. In addition to that, involvement of large corporation as strategic customers, made significant impact on development of many CAD/PLM systems for the past two decades. Do you think we can see something similar in the future?

Inc. article GE’s Grand Plan: Build the Next Generation of Data Startups made me think about some potential strategic involvement of large industrial companies in PLM software business. The following passage can give you an idea of how startups will be organized.

A team from GE Software and GE Ventures has launched an incubator program in partnership with venture capital firm Frost Data Capital to build 30 in-house startups during the next three years that will advance the "Industrial Internet," a term GE coined. The companies will be housed in Frost’s incubator facility in Southern California.

By nurturing startups that build analytical software for machines from jet engines to wind turbines, the program, called Frost I3, aims to dramatically improve the performance of industrial products in sectors from aviation to healthcare to oil and gas. Unlike most incubator programs, GE and Frost Data are creating the companies from scratch, providing funding and access to GE’s network of 5,000 research assistants and 8,000 software professionals. The program has already launched five startups in the past 60 days.

This story connects very well to GE vision and strategy for so called Industrial Internet. The following picture can provide you some explanations of what is the vision of GE industrial cloud.

industrial-internet-applications

What is my conclusion? Industrial companies are looking for new solutions and probably ready to invest into ideas and innovative development. Money is not a problem for these companies, but time is very important. Startups is a good way to accelerate development and come with fresh ideas of new PLM systems. Strategic partnership with large company can provide resources and data to make it happen. Just my thoughts…

Best, Oleg

Picture credit of GE report.


What PLM Architects and Developers Need to Know about NoSQL?

July 7, 2014

plm-no-sql-guide

People keep asking me questions about NoSQL. The buzzword "NoSQL" isn’t new. However, I found it still confusing, especially for developers mostly focusing on enterprise and business applications. For the last decade, database technology went from single decision to much higher level of diversity. Back in 1990s, the decision of PDM/PLM developers was more or less like following – "If something looks like document, use Excel and Office. Otherwise, use RDBMS". Not anymore. My quick summary of NoSQL was here – What PLM vendors need to know about NoSQL databases. You can go more deep in my presentation – PLM and Data Management in 21st century. If you feel more "geeky", and considering maybe summer development projects, I can recommend you the following book – 7 Database in 7 weeks.

John De Goes blog post The Rise (and Fall?) of NoSQL made me think how to explain the need of NoSQL for PLM implementers, architects and developers. In a nutshell, here is the way I’d explain that – NoSQL databases allow you to save variety of specific data in a much simple way, compared to SQL structured information. So, use right tool for the right job – key/value; document; graph, etc.

So, NoSQL is accelerating development of cloud and mobile apps. It became much faster since some specific NoSQL databases tuned for particular type of non-structured data:

With NoSQL: (1) Developers can stuff any kind of data into their database, not just flat, uniform, tabular data. When building apps, most developers actually use objects, which have nesting and allow non-uniform structure, and which can be stored natively in NoSQL databases. NoSQL databases fit the data model that developers already use to build applications. (2) Developers don’t have to spend months building a rigid data model that has to be carefully thought through, revised at massive cost, and deployed and maintained by a separate database team within ops.

However, everything comes with price. The important insight of the article is to point on how data can be reused for reporting and other purposes. The following passage summarizes the most visible part of what is missing in NoSQL:

It’s quite simple: analytics tooling for NoSQL databases is almost non-existent. Apps stuff a lot of data into these databases, but legacy analytics tooling based on relational technology can’t make any sense of it (because it’s not uniform, tabular data). So what usually happens is that companies extract, transform, normalize, and flatten their NoSQL data into an RDBMS, where they can slice and dice data and build reports.

PDM and PLM products are evolving these days from early stage of handling "records of metadata" about files towards something much more complicated – large amount of data, unstructured information, video, media, processes, mobile platforms, analytics. CAD/PLM vendors are pushing towards even more complicated cloud deployment. The last one is even more interesting. The need to rely on customer RDBMS and IT alignment is getting lest restrictive. So, the opportunity to choose right database technology (aka the right tool for a job) is getting more interesting.

What is my conclusion? Database technologies universe is much more complicated compared to what we had 10-15 years ago. You need to dig inside into data management needs, choose right technology or tool to be efficient. One size doesn’t fit all. If you want to develop an efficient application, you will find yourself using multiple data management technologies to handle data efficiently. Just my thoughts…

Best, Oleg


What metadata means in modern PDM/PLM systems

February 26, 2014

meta-data

Metadata is "data about data". If you stay long with PDM industry, you probably remember how earlier EDM/PDM software defined their role by managing of "data about CAD files" (metadata). However, it was long time ago. Wikipedia article defines two types of metadata – structural and descriptive. Here is a quote from the article:

The term is ambiguous, as it is used for two fundamentally different concepts (types). Structural metadata is about the design and specification of data structures and is more properly called "data about the containers of data"; descriptive metadata, on the other hand, is about individual instances of application data, the data content.

In my view, CAD/PDM/PLM is using both types. Since design is very structured and contains lots of rich semantic relations, metadata about CAD files stored in PDM system is structured. At the same time, descriptive metadata such as file attributes, information about people, project, organization can be applied to individual instance of CAD data (files) as well.

Since early EDM/PDM days, lots of changes happened in the definition and usage of a word metadata. Some of them are very confusing. The traditional use and definition of files (for example, in context of CAD files) is changing. Sometimes, we want to to keep "file" as a well-known abstraction, but underlining meaning is completely different and point more on "data" or "design" rather than actual files. Also, introduction of web based systems are changing physical use of files. The usage of file accessed via mobile application located in Dropbox is completely different. In many scenarios you will never get access to these physical files.

DBMS2 article Confusion about Metadata speaks about some additional aspects of metadata management that getting more relevant these days. It includes data about mobile devices usage (telephone metadata) and document data. Document data is getting more structured these days and often cannot be distinguished from structured RDBMS data. Here is interesting passage that describes the transformation of database and document based data.

[data about data structure] has a counter-intuitive consequence — all common terminology notwithstanding, relational data is less structured than document data. Reasons include: Relational databases usually just hold strings — or maybe numbers — with structural information being held elsewhere. Some document databases store structural metadata right with the document data itself. Some document databases store data in the form of (name, value) pairs. In some cases additional structure is imposed by naming conventions. Actual text documents carry the structure imposed by grammar and syntax.

Modern data management systems and especially noSQL data bases such as document and key-value databases can introduce new types of metadata or data. IoT (Internet of things) brings another level of complexity to data management. I can see many others to come.

What is my conclusion? I think, the term meta-data is getting outdated at least in the scope of design and engineering. Originally used a lot in EDM/PDM systems managing metadata about CAD files is not relevant anymore. Design data originally stored in CAD files becomes more transparent and connected to external to design world. The whole data paradigm is changing. Just my thoughts…

Best, Oleg


Tech Soft 3D TechTalk: PLM and Data Management in 21st Century

October 25, 2013

databases-300x225

Boston is one of the rare places where you meet many CAD and PLM people at the same time at the same place. You don’t need to guess a lot why so. MIT CAD Lab as well as many companies in this domain made Greater Boston a unique place for talents in CAD and PLM space.

Tech Soft 3D is well known technological outfit helping many companies in CAD and PLM domain to develop successful products. Besides that Tech Soft 3D is sponsoring a gathering of technological fellows in the CAD/PLM domain to come, network and share their experience – Tech Talk. Yesterday was my first time attending Tech Talk in downtown Boston. I missed one last year because of crazy travel schedule. This year I’ve been honored to get invited and make a short speak. I shared my experience and thoughts about database and data management technological trends. As part of my presentation I shared my thoughts about so called NoSQL trend, what it contains and how it can be useful for CAD, PDM/PLM. Below you can see a full slide deck of my presentation.

PLM and Data Management in 21st Century from Oleg Shilovitsky

On the following slide, you can see a simplified decision table that can help you to designate what noSQL databases can be useful for different type of solutions.

PLM-and-database-options

What is my conclusion? Database and data management technology is going through cambrian explosion of different options and flavors. It is a result of massive amount of development coming from open source, web and other places. Database is moving from “solution” into “toolbox” status. Single database (mostly RDBMS) is no longer a straightforward decision for all your development tasks. My hunch, CAD/PLM developers need to ramp up with with tools and knowledge to tackle with future database decisions. Just my thoughts…
Best, Oleg


PDM 101: Engineering Document Management Fallacy

August 30, 2013

We love new technologies and trends. However, from time to time, I want to get back to basic topics of engineering and manufacturing software. The topic I’d like to discuss today is Engineering Document Management (EDM). This post was triggered by DM vs. EDM article by Scott Cleveland on 2PLM letter. Here is the passage Scott use to explain the main difference:

Document management can be as simple as saving a document to a protected directory. It could be any of the document management software packages like SharePoint. Engineering document management is a different beast. Engineering document management follows some basic engineering rules. The concept is that of a vault.

Later in the article engineering rules are explained as access control, version control, process states (create, change, release) and audit trail.

I found myself a bit confused by this definition. There are many document management systems that will comply with rules described above. However, I’d not recommend to use these systems for engineering document management purposes. I took a look in wikipedia and here is what I found. Navigate to the following wikipedia link about Document Management System (DMS). The article is quite comprehensive. Here is a short passage that defines DMS:

A document management system (DMS) is a computer system (or set of computer programs) used to track and store electronic documents. It is usually also capable of keeping track of the different versions modified by different users (history tracking). The term has some overlap with the concepts of content management systems. It is often viewed as a component of enterprise content management (ECM) systems and related to digital asset management, document imaging, workflow systems and records management systems. Document management systems commonly provide storage, versioning, metadata, security, as well as indexing and retrieval capabilities.

Later in the article, I found a very useful table describing functions and components of document management. One of the them (very important) is Versioning:

Versioning is a process by which documents are checked in or out of the document management system, allowing users to retrieve previous versions and to continue work from a selected point. Versioning is useful for documents that change over time and require updating, but it may be necessary to go back to or reference a previous copy.

Now, let’s move forward and see what wikipedia states about Engineering Document Management (EDM). I didn’t find a separate EDM article. The most relevant one was Technical Data Management derived from Document Management System (DMS). I captured the following important passage:

A Technical Data Management System (TDMS) is essentially a Document management system (DMS) pertaining to the management of technical and engineering drawings and documents. Often the data are contained in ‘records’ of various forms, such on paper, microfilms or on digital media. Hence technical data management is also concerned with record management involving purely technical or techno-commercial or techno-legal information or data.

Wikipedia article compares TDMS and DMS in a following way:

TDMS functions are conceptually similar to that of conventional archive functions, except that the archived material in this case are essentially engineering drawings, survey maps, technical specifications, plant and equipment data sheets, feasibility reports, project reports, operation and maintenance manuals, standards, etc.

In my view, these days, most of people are associating Engineering Document Management directly with PDM. Navigate to wikipedia page EDM page and you find a confirmation to that (Engineering Data Management, also known as Product Data Management).

So, what is so special and different about Engineering Document Management that confuses many people? In my view, it comes down to the type of data system is managing. It is about CAD models, Drawings, Design, Simulation, etc. This data is semantically rich and contains lots of connections and constraints. To manage versions of Excel files is easy. Many document management systems can do so. However, to manage versions of SolidWorks or Inventor assemblies is not so simple. You need to track dependencies between parts, drawings and other elements of interconnected data.

What is my conclusion? Semantic complexity makes engineering document management complicated. It is all about connections and data dependencies. This is a specialty of engineering document management software. To manage revisions of interconnected files is complicated. It cannot be done on a level of single file and requires different approach. Engineering Document Management (today mostly known as PDM) is a special class of data management solutions used for this purposes. Just my thoughts…

Best, Oleg


PLM: Data vs Process – Wrong Dilemma?

August 7, 2013

Recent debate on Tech4PD brought back one of my favorite topics in PLM – data vs. process. The topic isn’t new, but it is not diminishing the importance. I found first appearance of my debates with Jim going to back in 2009. Navigate to the following link and read my old blog – PDM vs. PLM: Is it about the process? Another perspective on data vs. process in PLM was presented in my blog post – PLM: controversy about process vs. data managemen. The last one was inspired by Bell Helicopter presentation made during Dassault Customer Conference back in 2011.

Take a moment of time and watch the debate. I gave my vote to Jim. I like his broad perspective on setting organization on the right path with their working procedures. Jim also "packaged" his process opinion together with "file management", which made me assume that engineers will be able to identify right versions of a specific file/design. What made me feel sad a bit with regards to Chad’s position is his wiliness to focus on how to control all data in PLM – something I have hard time to believe as needed and even possible. To me PLM cannot control all data, but should rely on technologies to make data available for decision (and not only) processes.

The debate made me think about why Data vs. Process is probably a wrong dilemma in the context of PLM. In my view, the right focus should be on "lifecycle" as a core value proposition of PLM and ability of PLM to support product development. In a nutshell, product development is about how to move product definition (in a broad sense of this word) from initial requirements and design to engineering and manufacturing. If I go future, next stages of product definition will be related to maintenance and disposal. To define what represent product on every stage together with what is required to move product from one stage to another is a core value of product lifecycle and PLM.

What is my conclusion? After many years of debates about data vs. processes, I think time came to get to the next mature level of understanding how to get PLM work for companies. The focus on product definition for every stage of product lifecycle bundled together with procedures or requirements needed in order to move between stages can be a new way to define what PLM is about. Just my thoughts…

Best, Oleg


How Amazon helps cloud PLM to connect to enterprise data?

April 16, 2013

Face it, even cloud is trending and growing fast, on enterprise premise systems are representing a major part of engineering and manufacturing systems in organizations. It includes ERP, CRM, PDM, PLM systems as well as zillions of Excels and CAD files. I’ve been thinking how to optimize cloud/on-premise data co-existance. My attention was caught by the news about Amazon Storage Gateway. Amazon, in its push to draw more enterprise customers, had to make sure the Amazon Storage Gateway will run in Microsoft Hyper-v virtualized shops. Which expands the ability of Amazon to synchronize data between cloud and on premise environment.

For those of you not familiar with ASG (Amazon Storage Gateway), navigate to the following link to learn more. The AWS Storage Gateway supports two configurations:

1/ Gateway-Cached Volumes: You can store your primary data in Amazon S3, and retain your frequently accessed data locally. Gateway-Cached volumes provide substantial cost savings on primary storage, minimize the need to scale your storage on-premises, and retain low-latency access to your frequently accessed data.

2/ Gateway-Stored Volumes: In the event you need low-latency access to your entire data set, you can configure your on-premises gateway to store your primary data locally, and asynchronously back up point-in-time snapshots of this data to Amazon S3. Gateway-Stored volumes provide durable and inexpensive off-site backups that you can recover locally or from Amazon EC2 if, for example, you need replacement capacity for disaster recovery.

The two options are representing an interesting option on how enterprise data can co-exist between cloud and on-premise environments. I can see mid-size companies are doing it to optimize their file storages. Larger companies can use it for extended value chain communication.

What is my conclusion? As cloud systems will expand in organizations, the demand for hybrid environment will grow as well. Companies won’t be able to migrate enterprise data assets outside of organizations fast, therefore cloud PLM solutions that will be able to communicate and co-exist in hybrid deployments will grow. The ability to connect existing enterprise data assets and cloud apps is a key to make future cloud expansion. Just my thoughts…

Best, Oleg


Follow

Get every new post delivered to your Inbox.

Join 250 other followers