The end of single PLM database architecture is coming

August 5, 2014


The complexity of PLM implementations is growing. We have more data to manage. We need to process information faster. In addition to that, cloud solutions are changing the underlining technological landscape. PLM vendors are not building software to be distributed on CD-ROMs and installed by IT on corporate servers anymore. Vendors are moving towards different types of cloud (private and public) and selling subscriptions (not perpetual licenses). For vendors it means operating data centers, optimize data flow, cost and maintenance.

How to implement future cloud architecture? This question is coming to the focus and, obviously, raising lots of debates. Infoworld cloud computing article The right cloud for the job: multi-cloud database processing speaks about how cloud computing is influencing what is the core of every PDM and PLM system – database technology. Main message is to move towards distributed database architecture. What does it mean? I’m sure you are familiar with MapReduce approach. So, simply put, the opportunity of cloud infrastructure to bring multiple servers and run parallel queries is real these days. The following passage speaks about the idea of how to optimize data processing workload by leveraging cloud infrastructure:

In the emerging multicloud approach, the data-processing workloads run on the cloud services that best match the needs of the workload. That current push toward multicloud architectures provides the ability to place workloads on the public or private cloud services that best fit the needs of the workloads. This also provides the ability to run the workload on the cloud service that is most cost-efficient.

For example, when processing a query, the client that launches the database query may reside on a managed service provider. However, it may make the request to many server instances on the Amazon Web Services public cloud service. It could also manage a transactional database on the Microsoft Azure cloud. Moreover, it could store the results of the database request on a local OpenStack private cloud. You get the idea.

However, not so fast and not so simple. What works for web giants might not work for enterprise data management solutions. The absolute majority of PLM systems are leveraging single RDBMS architecture. This is fundamental underlining architectural approach. Most of these solutions are using "scale up" architecture to achieve data capacity and performance level. Horizontal scale of PLM solutions today is mostly limited to leverage database replication tech. PLM implementations are mission critical for many companies. To change that would be not so simple.

So, why PLM vendors might consider to make a change and to think about new database architectures? I can see few reasons – the amount of data is growing; companies are getting even more distributed; design anywhere, build anywhere philosophy comes into real life. The cost of infrastructure and data services becomes very important. In the same time for all companies performance is an absolute imperative – slow enterprise data management solutions is a thing in the past. To optimize workload and data processing is an opportunity for large PLM vendors as well as small startups.

What is my conclusion? Today, large PLM implementations are signaling about reaching technological and product limits. It means existing platforms are achieving a possible peak of complexity, scale and cost. To make the next leap, PLM vendors will have to re-think underlining architecture, to manage data differently and optimize cost of infrastructure. Data management architecture is the first to be considered. Which means end of existing "single database" architectures. Just my thoughts…

Best, Oleg

PLM Graph Alert

July 6, 2013

Graphs are fascinating. I think, we like graphs more and more these days. I like graphs a lot because in my view graphs are reflecting a variety of relationships we have in real life and computer applications. Design and manufacturing software has a lot of dependencies on graph data models. If you think about CAD models, product configurations, BOMs, and many other things – it all can be represented using graph model. At the same time, graph is complex thing. It requires lots of computing power to get value out data represented in such way.

For the last decade, web companies made significant investment in research and development of variety of graph oriented data processing solutions. Google, Amazon, LinkedIn, Twitter, Facebook… all big names are here. Lot of graph-related technologies are available as open source these days.

In one of my previous blogs I posted about PLM graphs and Facebook Graph search. Navigate here to refresh your memories. In my view, it something that certainly requires an additional attention as a technique to process data as well as user experience.

Earlier today, one of my friends shared with me GigaOM article – Graph make headway, but simplicity is still a few hops away. Article brings couple of good examples of how Twitter and Walmart are using graphs to provide smarter solutions for their customers.

Twitter’s Who to Follow tool is a fine example of a product benefiting from a graph model for data. Who to Follow depends on the FlockDB graph database and the Cassovary in-memory graph-processing engine Twitter constructed in-house and then released to everyone under an Apache License. The product mines existing connections among users, shared interests and other data in order to makes its recommendations with data in a graph that can run inside the memory of a single server.

Lei Tang, a data scientist at @WalmartLabs, talked about how he’s been working on drawing on lots of data sources to recommend products to website users that they might actually want to buy. A smart recommendation system ought to shift in response to incoming data on, say, a user’s page views and purchases, he said. This is where clustering of products can be wise. So while a user might view a bunch of televisions before ultimately buying one, the cluster of television products within the larger set of products the system can recommend should be set aside as soon as the purchase happens.

The problem today is that most of graph solutions are complicated for engineering and required lots of effort to be used for the development of mainstream applications. The simplicity is a key – this is a conclusion for tech developers promoting graph based solutions.

What is my conclusion? Graphs are still in an infancy in terms of the ability to provide a mainstream solutions to every developer. However, not paying enough attention to graph processing can cost future efficiency and competitive advantages to current CAD/PLM providers. The biggest challenge for these companies will be to integrate existing solutions and algorithms with graph models. However, growing amount of data and customer demands to scalable data processing technologies can be an interesting challenge to solve. Just my thoughts…

Best, Oleg

Why New Database Technology Won’t Solve PLM Problems?

March 18, 2013

Disruptive technologies and solutions. This is beloved topic by bloggers, analysts and vendors. We like to talk about how disruption will happen. For very long period of time, database technology was a stable element in the overall PDM/PLM technological architecture. The decision about usage of relational database was only about how to choose between Microsoft SQL, Oracle DB and IBM. However, recently, I started to hear voices about changes that might happen in the world of databases. I’m sure you’ve heard about noSQL. If not, you can catch up via this link – What PLM vendors need to know about noSQL databases? The question about the ability of noSQL or other alternative to SQL solution to disrupt PLM development and products is an interesting one. Yoann Maingon of Minerva is asking this question in his blog post – New database system for future of MDM. Yoann declares database as one of the inhibiting factors preventing users to move from one PLM solutions to another. Here is an interesting passage –

I hope the actual economy environnement will convince more people to invest time for helping the product development initiatives by solving Product Lifecycle Management related pending issues. Today’s article is about my thought on why it is always so complicated to move from a PLM solution to another, why are we changing tons of things and settings to in fact change a software cost or an interface. On of the reason is that all these elements are strictly related and the elements in a PLM solution can’t be dissociate. You can’t just keep you data and change the interface. From my previous experiences of migration, I’ve realized that I was moving data from a system to another with transformations but the data would still mean the same thing it is just that the software would handle it differently. Then speaking of standards would there be a standard for data management in PLM and should this define a technology or at least should it drive database system editors to push for one?

I’m in a bit disagreement with Yoann. In my view, all SQL, noSQL, XML and many other database flavors are providing an infrastructure that can be used in different ways. Yes, there are differences between noSQL and SQL databases. However, if we speak about building applications, the way application created will provide a much more significant factor on the efficiency and behavior of your application. Earlier this year, I’ve seen an interesting article, which focus on this specific question – NoSQL or Traditional Databases: Not Much Difference. Take you time and read it. You find it very educational. I absolutely liked the following passage –

I have spent considerable time tuning SQL statements and indexes, but in the end the best optimizations have always been those on the application and how the application uses the database. SQL Tuning almost always adds complexity and often is a workaround over bad application or data structure design. In the NoSQL world “SQL statement” tuning for the most part is a task of the past, but Data Structure Design has retained its importance! At the same time logic that traditionally resided in the database is now in the application layer, making application design even more important than before. So while some things have shifted, from an Application Performance Engineering Perspective I have to say: nothing really changed, it’s still about the application. Now more than ever!

What is my conclusion? No surprises. It is all about your application – logic, tuning, performance, mistakes and ability to create a reliable and efficient solution. Yes, different database techniques are requiring different technical skills. But if you have them, your ability to build PLM system on any of these platform will be almost identical. Just my thoughts…

Best, Oleg

Is SAP HANA the future of PLM databases

February 7, 2013

I’m on the road in Europe this week. Europe met me with snow in Zurich and not very reliable internet connection later in Germany. On the plane, I was reading about future investments of SAP in HANA (new in-memory database) that suppose to revolutionize enterprise software industry. Navigate to the following link and have a read – SAP’s HANA Deployment Leapfrogs Oracle, IBM And Microsoft. I found the following passage very interesting.

What SAP has done is to provide one database that can perform both business analysis and transactions, something its rivals are able to provide only by using two databases, according to Gartner analyst Donald Feinberg. “It’s the only in-memory DBMS (database management system) that can do data warehousing and transactions in the same database. That’s where it’s unique.”

Databases is a fascinating topic. At the end of the day, the enterprise software industry (and not only) is solely relies on database for most of the applications. The days PDM apps were running on proprietary databases and filesystems gone completely. The last one I knew was PDM workgroup. In my view, SolidWorks is still running bunch of customers using this solution, but nobody is taking database-less solution seriously these days. Most of PDM and PLM applications are running on MS SQL and Oracle databases. Despite PLM power of IBM, I haven’t seen any significant usage if DB2 for PDM/PLM. Another interesting quote, I found about HANA is related to competition. According to author it will take few more years until Microsoft and Oracle will be able to catchup.

SAP has taken a big step ahead of rivals IBM, Microsoft and Oracle with the announcement on Thursday that its in-memory database called HANA is now ready to power the German software maker’s business applications. The pronouncement is sure to darken the mood of competitors, who one analyst says will need several years to match what SAP has accomplished.

I’ve been writing about HANA and applications before on my blog. Take a look here. Also, you can find lots of interesting resources online here. Applications of HANA database are interesting and when it comes to analyzes of massive amount of data makes a lot of sense in context of product development and manufacturing.

For SAP customers, HANA-powered applications can speed up the sales process dramatically. For example, today when salespeople for a large manufacturer takes a large order from a customer, they may not be to say on the spot exactly when the order will be fulfilled. That information often comes hours later after the numbers are run separately through forecasting applications.

What is my conclusion? Customers are interested in real solutions that can save money to them. Technology is less relevant in that case. Ability to answer practical questions is more important. SAP has money and customers. Many years, SAP is using database solution from main competitors – Oracle and Microsoft. Will SAP be able to pull new technology to revolutionize this market? Will Microsoft, Oracle and open source databases will be able to catch up this game? An interesting question to ask these days… Just my thoughts.

Best Oleg

PLM: from EGOsystem to ECOsystem

December 1, 2012

I just came back AU2012 in Las Vegas. Among many meetings, I had during AU, I attended Innovation Forum – The Reality of the cloud. The reality of events these days that you can attend actively by participating in social networking via Twitter. One of the tweets during the cloud presentation was Chad Jackson’s: – Think about data as an eco-system.

"Think about data as an ecosystem" from the #Cloud #Innovation forum at #AU2012…

— Chad Jackson (@ChadKJackson) November 29, 2012

It made me think about PLM as data eco-system. Watch Gerd Leonhard presentation- The future of the internet (SoLoMo) futuristic presentation with strange title – Big Data, Big Mobile, Big Social. I found it is interesting. Navigate here to take a look.

Few slides caught my special attention in the context of PLM and Data Ecosystem discussion. One of them is related to Paul Baran research back in 1960 (way before the internet and even early PLM systems). He was pioneering some of early work related to computer networks. Navigate to the following link to read more. Here is an interesting passage:

The pioneering research of Paul Baran in the 1960s, who envisioned a communications network that would survive a major enemy attacked. The sketch shows three different network topologies described in his RAND Memorandum. The distributed network structure offered the best survivability.

Another slide that sticks in my memory was the comparison of Egosystem and Ecosystem. That slide made me laugh. Especially when I put it next to one of my previous post about PLM Egoism. Think about PLM system transformation. A year ago, during AU2011, I was talking about transformation from Database to Networks. This slide is representing the way how ego-centric PLMs need to be transformed into reliable and modern PLM eco systems.

What is my conclusion? Today’s PLM EGOsystems are not sustainable. The centralized approach made PLM implementation weak and not able to survive long term lifecycle, evolution and business changes. The result is heavy PLM systems that require propriety maintenance. Change management of these systems is either expensive or impossible. It is a time to think about data networks and networked system models. Just my thoughts…

Best, Oleg

pictures courtesy of gleonhard presentation

PLM customization and the role of SQL Data Schema

September 25, 2012

The business of PDM and PLM systems are tightly connected to data. In the early days of EDM (Engineering Data Management) and PDM, developers used variety of data-management technologies – text files for meta-data, proprietary data bases and lately relational databases (RDMBS). RDBMS became a mainstream for enterprise software 15-20 years ago and since then everybody developing some kind of data systems (PDM and PLM clearly counted in) are tightly connected to RDBMS and SQL (Structured Query Language). SQL became a mainstream in many applications – developers and application engineers are familiar with the language and use it in variety of implementations – customizing a data schema, building reports, and optimizing application for performance and workload.

Object Model Abstraction

The complexity of product and engineering applications such as PDM and PLM is related to the complexity of data. Engineering, product and lifecycle data is very semantically rich and as a result makes the development of solution complex and dependent on different factors related to customer needs. Therefore, PDM and PLM systems in late 90s and early 2000s developed object models that created logical mapping between SQL data tables and conceptual (logical) model of data. Such type of models is used almost in every PDM /PLM system. Depends on the complexity of the system and functional needs vendors created object models with a different level of complexity and flexibility.

I’ve been reading Aras blog few days ago on the topic of SQL data modeling. The name of the post has some marketing flavor – Get the Inside Scoop: CEO on Architecture Benefits. Despite that fact, the post itself is interesting and speak about flexibility of PLM solutions, data models and the mapping of object models to SQL tables. Here is the passage that speaks about the problem of object modeler and abstractions in enterprise systems and PDM/PLM systems:

Essentially, it’s been too difficult [and/or costly] to modify the software to fit your processes. It’s been even more difficult to modify that software again six months from now because your processes have evolved. And, assuming you’re able to modify the software and get it into production, with all that modification it’s now close to impossible to upgrade it. This is because legacy enterprise software technology allows customization through very "clever" abstractions of the object model vs. the relational database design. The more you customize and the larger the data set, the more these abstractions create scalability and performance issues. It’s a huge problem.

Certainly, to create an efficient abstraction level is important. I will leave the advantages of a specific vendor(s) out of this blog. I’m sure almost all PLM systems today on the market made an effort to develop an efficient abstraction level. Some of them succeeded more and some less. However, let me speak more about what future holds, in my view.

Data Web Applications and Service Abstraction

Development of object model and data abstraction is not something, specifically unique for PDM and PLM systems. Fundamentally, any software created data abstraction and uses it for application / implementation needs. As far technology develops for the last 10 years, we’ve seen many examples of data abstractions developed for web applications. The main difference is that architecture of these systems is not allowing easy exposition of database to end users and applications’ developers. As a result, most of these systems developed service oriented model that used to customize data as well as make changes. Because of web nature of application, the requirement to run it with high availability is a natural per-requisite. At the same time, it allows to engineers to hide and optimize data schema for many of these applications. It was done by many web systems started from web giants like Google, Amazon, Facebook, LinkedIn and going down to many smaller web apps.

What is my conclusion? Data and data efficiency remains of the key topics on the table when it comes to the development of PDM and PLM applications. To make it simple and stable to updates and system customization is a priority task. I think, SQL data schema is a technique that uses by almost all PDM/PLM systems. Thinking about the future, I can see systems are moving towards something more efficient, exposing less SQL outside and keep web oriented tools to maintain data customization.

Best, Oleg



Get every new post delivered to your Inbox.

Join 288 other followers