Fields marked with a * are required


Granularity and Integration Aren’t Diametrically Opposed

References Cited

Mechanical Computer Aided Design (MCAD), Dassault Systèmes, PTC, Enterprise Business Platforms, Solutions and Apps, Product Lifecycle Management (PLM), Electrical Computer Aided Design (ECAD)

Who doesn’t like a little debate?

For some, I know, it’s uncomfortable. But honestly, it’s a good thing. It let’s you refine your logic, clarify your position and point out misinterpretations. Furthermore, it’s fun! Really, a little tête-à-tête keeps you sharp.

With all that in mind, I owe a thanks to Oleg Shilovitsky, because yesterday, he called me out. I’ll explain below. But remember, this is a good thing. Let’s dive in.

Conflicting Perspectives?

If you’re not familiar with Oleg and you care about technologies for product development, then you need to get to know him. On one hand, he’s a leader in the development organization at Autodesk, a provider of CAD and PLM software. But he is, and has been for quite some time, an avid and prolific blogger in the space. Beyond that, he’s quite a good guy as well. Check him out on his site: Beyond PLM.

Yesterday, he wrote a post titled CAD: Engineering Bundles vs. Granular Apps? I suggest you check it out. He brings in points and thoughts from a number of different posts. One of which is where he thinks I have a conflicting perspectives on Integrated Suites vs. Granular Apps. Here’s what he quoted from me in my post titled No More Excuses: It’s Time to Merge MCAD and ECAD.

Why are there two separate toolsets at all? And that’s where, despite the lack of enthusiasm and interest in the topic, I think there is potential for disruption and innovation. There shouldn’t be two toolsets. You should be able to conduct mechanical and electrical design in a single CAD application…. Call it Hardware CAD (HCAD). Call it Electro-Mechanical CAD (EMCAD). I don’t care. But don’t tell me such an offering wouldn’t be intriguing. In my eyes, there is no reason that a combined MCAD-ECAD application shouldn’t be available. Large existing software providers have their reasons for inaction. But that means there is a ripe opportunity for disruption from smaller companies.

And here he cites one of the Tech4PD episodes I hosted, titled CAD: Granularity vs. Integrated Suites.

Granular CAD applications enable many roles in the enterprise, expanding the use of the 3D asset company-wide. Granular apps are better at enabling individual roles.

I can see his point. These two stances seem to conflict. However, I have come to realize that Granularity and Integration are not diametrically opposed. In fact, some software providers are incorporating both of these key points at the core of their product strategy.

Granularity and Integration: Examples to Set the Stage

So what exactly do I mean by that? Let me give you a few examples.

First, let’s look at Dassault Systèmes. Their 3DEXPERIENCE strategy is twofold: First, they are taking their traditional brands and turning them into technology platforms, much like building blocks. Second, they are building apps that cobble together these technology platform building blocks to create granular apps. Soldiworks Mechanical Conceptual is a good example of that. It is a granular app, with sketching, kinematics and data management mixed in. However, the data is integrated in that it can be managed in the cloud by ENOVIA capabilities as part of a single database. This is granular and integrated.

Second, let’s look at PTC. Their Creo strategy is also twofold. First, they are creating granular and separable apps. Examples include Creo Direct, Creo Parametric, Creo View and so on. However, these Creo apps also all work against the same data underneath. Thus, they are also integrated. Like Dassault Systèmes, PTC’s product strategy for Creo is granular and integrated.

In contrast, let’s take a look at Transmagic. They offer a number of different granular tools mainly focused on CAD data translation. This toolset is granular in that it is fairly focused. It provides a specific set of functionality to do a specific thing. It is not, however, integrated. Tweaks, modifications and changes made in the Transmagic toolset will not change or update the design back in the original CAD application. This solution is granular but not integrated.

Also, let’s look at VCollab. It is very focused on visualizing simulation results in a lightweight and portable format. Much like Transmagic, this is a granular app in that it provides one set of capabilities for a specific job. You cannot, however, change the results set within this tool. You cannot change the model setup. It is granular but not integrated.

Granularity and Integration Are Not Diametrically Opposed

So, these two things, granularity and integration, are not diametrically opposed. But that doesn’t necessarily define the terms for us. So let me do that now.

Granular Apps offer a limited set of capabilities that are focused on a specific job. These apps are more accessible to different roles in the company because their limited set of functionality requires less training and retention in terms of how they work. They are valuable in the network of roles that participate because they are so accessible.

Data Integration means that multiple software applications work against a single set of data in a coordinated fashion. There can be value in this in propagating change and enabling collaboration across the network of roles that participate in overall product development.

In short, these two terms actually don’t necessarily have anything to do with one another.

Merging MCAD and ECAD: Where Granularity and Integration Fit In

So how does all this fit into my post the other day? Here are the capabilities I think are important.

  • Changes by a PCB designer or a mechanical designer should be automatically and associatively propagate between each other.
  • If the size of the board is modified or a larger board component takes the place of a smaller one, the mechanical engineer should see that change automatically.
  • If the PCB designer updates the ‘from-to’ information on the board diagram, it should pop up an notification in the 3D assembly.
  • If the mechanical engineer adds ventilation holes in the enclosure or uses a larger fan on the side of the enclosure, the PCB designer should see that as well.
  • Simulation analysts should also see these changes as well, updating their simulation model so they can easily re-run an analysis.

How does granularity and integration work into this story? Here’s my take.

  • Granular apps seem pretty logical. There should be one for board layout, board design (in the full 3D assembly), mechanical design (with the full 3D board assembly) and simulation (with the same 3D assembly). Each role could have their focused, simple-as-possible design and analysis environment that let’s them be as efficient as possible without the burden of learning, or getting lost in, a big sprawling software application.
  • Data integration is very logical here as well. The associative updates I describe above could be enabled when all of those granular apps are working against the same data set. A change at any of them, not only in the 3D assembly but also in the ‘from-to’ connectivity information, should show up everywhere.


I think Oleg might unique in how much he tracks what everyone is writing. And that’s a great thing. Again, I think being challenged like this is very valuable. It leads to more clarity, definition and hopefully… innovation in the industry.

One last though. One software provider that I wrote about in my 2014 CAD landscape was unhappy with what I published (The Stalwarts, The Interlopers, The Upstarts) because they were not differentiated enough. My reply back? It’s not easy to differentiate yourself in a crowded market with screaming marketing departments. The merge of MCAD and ECAD, however, would be highly differentiated. The opportunity exists.

Oh… and one more last thing. Oleg, I owe you a drink.

Take care. Talk soon. Thanks for reading.


Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.

Like this post?

Sign up now to get more like it

Fields marked with a * are required


  • beyondplm

    Chad, Interesting thoughts indeed. It can be cool (for sure… for bloggers:)) if a MCAD vendor will buy a ECAD vendor. Knowing players, I’m not sure it is possible. At the same time, you’ve made me think more about granular apps and engineering bundles. More here –

    best, Oleg

    • Hey Oleg. Thanks.

      I’d say this would be more than cool for bloggers. Since I publish the original MCAD-ECAD post, I’ve gotten 3 emails and 2 comments / messages on LinkedIn from users. They all agree this would be a capability that would make them consider switching. So… I’d say there’s traction there as well.

      Pretty soon, I’ll be writing up a post on what mergers and acquisitions some of the software providers in this space should be making. The merge of MCAD and ECAD will be one of those topics.

      • beyondplm

        Look forward to next posts. There are not so many MCAD and ECAD players :). So, would be interesting to know what your crystal ball is saying about acquisitions.

  • Come guys were are the bruises and blood, this is what we all want to see from a blog war.

    I have to say I found your debate rewarding because now I think I am more uncertain than I was before I read both of your articles…which is good.

    First I do agree that granularity and integration are two separate topics which are not mutually exclusive or not diametrically opposed. When I first watched the Tech4PD video I interrupted it as a debate between granular apps and a unified/monolithic solution. I will have to re-watch it with my new found uncertainty.

    However some of your comments and examples of granular apps which are extensions of a platform got me to ask a specific question:
    When is a software solution actually implemented with a granular strategy with good integration and when is it just a unified or monolithic solution?

    Before this post I had thought a granular solution is mutually exclusive from a unified solution but now I think that was incorrect. I guess (still pondering) a unified solution can be implemented using a granular strategy, but this does remind me of what Jim was debating for which was supposedly to oppose granularity.

    This does refine my thinking to: An open platform which supports granular apps is where I would place my bet on the future.

    I do not have a specific question which I kind of hoped when I started writing this response it would pop out…unfortunately it did not.

    • Wow, with a solid 6 hrs of sleep I realized how much non-sense the above post really was. Thanks for allowing me the opportunity to make a fool of myself:).

      I still do think (even with a good night sleep) an open platform with granular apps is the current strategy for success.

      Your latest post articulated very well the strategy of granular apps based on a platform.

      • Denis, you have some valid questions in your first comment. In particular, I think this is a critical question.

        When is a software solution actually implemented with a granular strategy with good integration and when is it just a unified or monolithic solution?

        I think PTC’s Pro/ENGINEER Wildfire was a good example of a single broad CAD application that delivered a suite of functionality. So, for example, if a concept designer wanted to do their work in ProE, they were exposed to the whole application. That was too much capabilities to expose to the user.

        PTC’s Creo suite, however, is an example of a integrated set of granular CAD apps. That same concept designer would use Creo Sketch and perhaps Layout. The functionality is limited, not overwhelming that user, but also is integrated so all the apps are working off the same design model.

        You could walk through examples from many different software providers today.

  • Great stuff here, Chad.

    Not sure any MCAD vendor will buy an ECAD vendor or vice versa, they tend to be peers and one may be too much for the other to digest. A joint venture might be interesting, but a more likely probability is one of the PLM vendors adds ECAD to their suite with integration through their PLM platform. Not what you’re asking for, I know. But I’d argue there are reasons we don’t see true granularity. More here:

  • ernoj

    Very old post but my first time seeing it.

    In my mind granularity is arguably the most important and first step. It is what enables what I call the “3 c’s”
    1. Configuration: Big blobs of binary cannot be configured into different forms. They need to be cloned-and-owned. Breaking into pieces with the right data model enables different configurations with on/off switches (applicability or effectivity as some say)
    2. Connection: Hard to get data in blobs. Need parsers or worse APIs and custom code to do so. Relates to configuration as well as duplicates in one place means duplication THEN connection with parsing/APIs in another. :-(
    3. Collaboration: This was my first interest as my main interest historically has been CAD. Binaries need to be taken turns on, not real collaboration.