';

PLM License and Deployment Flexibility Puts PLM in Reach (eBook)

The PLM License and Deployment Flexibility Puts PLM in Reach eBook discusses how new software deployment and licensing approaches including cloud, SaaS, subscription, and others can put PLM in reach for more companies. The eBook reviews the ROI of PLM and dispels the myth that PLM implementations have to be … [ read more ]

Tech-Clarity-eBook-PLM-Deployment-thumb

Requirements and Validation Buyer’s Guide

Tech-Clarity's Requirements and Validation Engineering Buyer’s Guide helps manufacturers develop criteria to evaluate software solutions to support requirements management and validation engineering. Tech-Clarity’s Buyer’s Guides go beyond software functionality to provide a framework of requirements that … [ read more ]

Tech-Clarity_Requirements_and_Validation_Buyers_Guide_thumbnail

Shifting CTO Design and Validation Left (infographic)

This infographic explains how manufacturers can improve configure-to-order (CTO) profitability by shifting design and validation "left," earlier in the product lifecycle, to rapidly respond to requests with accurate quotes and quality products. For more information on 3D Design and Validation, download the … [ read more ]

Edit_Post_‹_Tech-Clarity_—_WordPress

Finding PLM to Fit Midsized Manufacturers eBook

Our Finding PLM to Fit Midsized Manufacturers eBook explains how smaller companies find themselves stuck between full-featured PLM systems that feel out of reach and less capable solutions including cloud-based file sharing or very basic data management applications. They know they can't afford the errors and … [ read more ]

Tech-Clarity-eBook-PLM-Midsize_pdf

SolidWorks Vision 2016+

SOLIDWORKS World 2016 was held in Dallas, TX earlier this year. At the event, SOLIDWORKS revealed much about their strategy for this coming year and beyond. This post outlines 5 takeaways about SOLIDWORKS’s strategy for 2016 and beyond. This post is part of our CAD and CAE strategy series which complements … [ read more ]

solidworks_logo
1

Aras PLM Vision 2014+

Share

aras-logoThis is the next post in my series on  Strategic Visions of the Major PLM Vendors 2104+. I admittedly stalled a little bit on my ambitious project to review the strategies of PLM vendors. I am back on it and next on the list is one of the most interesting PLM companies I follow, Aras. Let’s dive in.

History – The Functional View

Aras has a very complete PLM suite. While some might assume that a company that isn’t one of the largest in the market would have a PDM-centric solution or limited capabilities, that couldn’t be farther from the truth. Aras supports processes that even some of the largest vendors struggle with. Take Quality Management (QM) for example. Aras has invested heavily in quality processes including APQP that tend to be outside of the boundaries of most PLM solutions. There are other examples as well, including Requirements Management (RM), Stage-Gate, and advanced Configuration Management (CM) for complex products. From a functional perspective, Aras is up there with the big guys (see the graphic of their footprint).

Aras-Innovator

History – The Technical View (not just for technologists)

Aras caught my eye a long time ago because of their technology approach. Long before they started changing their business model to subscription-based or open source, they were already different. Why? Because Aras has a very unique technical architecture. Wait, don’t tune me out if you aren’t one of the type that gets excited about software infrastructure. The Aras architecture serves a very important purpose that has a tangible impact on everyone. Aras is made to be easily changed and maintained effectively over time due to something called a model-based architecture. This approach allows software to be designed and developed at a high level of abstraction. This makes software much less “brittle” and easier to change.  In fact, it makes functional enhancements and extensions much easier to maintain and migrate over time by leveraging modularity, reuse, abstraction, and automation (perhaps the same thing you are trying to do in your engineering?).

Where Architecture meets Strategy

So who cares that Aras is easy to develop, modify, and migrate? How does Aras make this technical advantage a market advantage? It’s a good question, and one they have leveraged in different ways.  First, it allowed them to develop a suite of solutions relatively quickly to capitalize on their PLM heritage and knowledge (Aras has a solid team of PLM veterans). It gave them the ability to sell as an open source solution with the confidence that they could keep the core solution intact. It has allowed non-Aras developers to add on entire new modules to Aras. All of these would be more difficult in traditional software architectures.

The Aras strategy for 2014+ has taken another shift that takes full advantage of their underlying architecture. Aras has turned their sights to solving the age-old conundrum of getting trapped on old software by customization. Companies traditionally have had two choices when implementing PLM (or other enterprise applications for that matter):

  • Live with the functionality in the base package and get an efficient implementation with a clean upgrade process. This is frequently highlighted as a best practice to help implementations move quickly and allow manufacturers to get more value from their PLM foundation over time.
  • Extend and enhance the solution to get a better fit, but suffer difficult upgrades and get trapped on old releases.

The Aras Strategy

Aras has decided to break the rules. They aim to become the PLM company that defies the conundrum, allowing manufacturers to customize their software and still upgrade to future releases without major disruption. They can do this because customers can update the data schema, business rules, workflows, and forms without jeopardizing the integrity of the system. How does this work? Aras’ XML-based, model-oriented approach coupled with their willingness to provide customers with the business flexibility and tools to make it feasible.  Aras has effectively morphed themselves into a PLM Platform with solid core functionality with a built in ability to be extended by customers and partners. To put this strategy into action, they have told me they are “putting their money where their mouth is.” They now include upgrade services as a part of their subscription service. I haven’t seen that from anyone else anywhere, particularly while encouraging people to enhance and modify the package. This is a clear differentiator and makes Aras unique in the PLM market.

The Bottom Line

Even if you don’t care about the architecture, you should care about what it allows you to do. Aras promises to allow you to make your software fit your business without creating a dead end for upgrades. They want you to modify the solution and advantage of enhancements and entire new modules others have developed.

Beyond architecture, Aras has innovated on the way PLM is purchased. Aras has a “no license fee” approach that allows manufacturers to extend PLM to more people without major increases to their software costs. It also lets them get started more quickly and with lower risk. All in all, it makes Aras really easy to work with now and in the future. And for anybody that questions the performance of the model-based approach, ask Aras to share some of their independent scalability benchmarks. You will not be disappointed.

Related Posts

See other posts in our on PLM Strategies of the Major PLM Vendors 2015+ series:

Dassault Systèmes PLM Vision 2015+

Synergis Software PLM Vision 2015+

See more in our Strategic Visions of the Major PLM Vendors 2014+ series including:

Arena Solutions Vision 2014+

Autodesk PLM Vision 2014+

Dassault Systèmes PLM Vision 2014+

Infor PLM Vision 2014+

Oracle’s Vision for Agile 2014+

PTC PLM Vision 2014+

Also, don’t miss our The Strategic Visions of CAD/CAE Vendors 2014+

Comments

  1. Denis Morais says:

    Very interesting post as usual.

    I am definitely the type of person who thinks knowing the software architecture is very important in understanding the benefits of a product.

    I do share ARAS’s philosophy of creating more of a platform which supports at its core, heavy configuring and customizing. The horror stories we hear about customization gone horribly wrong usually stem from connecting systems which architecture does not support easy expansion. I actually just wrote a blog post about this the other week.

    Not all customizations are equal. There are definitely solutions like ARAS which support customization and therefore I think we can embrace the idea of tailoring it. However, there are products which was not initially architected to be extended and these are the ones we should refrain (as much as possible) from customizing.

    It will be interesting to hear what others have to say.

    • broepke says:

      Denis

      I think you’re spot on. However avoiding customization is really really really hard. I bet there aren’t too many people using one of the older PLM systems for anything business process related (exclude CAD data management – this is easy OOTB) without it being customized.

      However – I think this is really a remnant of the past. If you look at where these horror stories are it’s all the old enterprise architectures that are deployed on premises. If you take a more modern system (I can vouch for Autodesk PLM 360) you simply don’t have this. We did a release per month last year and we don’t have any issues with migration or anything you see around customizations. People use PLM 360 quite tailored to their workflows and process and we just don’t have that issue.

      I relate it back to something that the older systems do. One enterprise customer of ours was using one of these early PLM systems and they talked about how they would actually MODIFY the source code to insert their customizations. The actual JSP (Java Server Pages) files on the that contain the original source code from the vendor to accomplish what they wanted to. So when it came to an upgrade you had to use developer class code merging tools to do an upgrade all while reconciling the changes in the recent release vs. your customizations.

      OF COURSE you get locked in to an old version when that happens!!!

      • Denis Morais says:

        Brian,

        Interesting story about the user customizing their PLM product by changing the source code…I think it is obvious, at least from an external standpoint, that it is a bad strategy:)

        After reading your comment it reminded me (not for any particular reason) of another thought I have. I think a solution/product which was built with customization in mind should not require customization by the user to get it working. It should have complete OOTB implementation which can provide value to the user with no modifications. The customizations should be to expand, extend, tailor the solution, not build core functionality.

        • broepke says:

          Believe me – that story isn’t unique. That’s how you customize those solutions.

          You’re right – it should be very complete OOTB. I don’t think a lot of solutions these days ship without some sort of best practice as a starting point. I think PTC moved away from the toolkit in the early 2000’s with the “link” solutions, not sure when matrix did but they had their “centrals”… It’s a great idea to get people close and let them tailor from there.

          But it better be easy to do that…

          • Brian,
            Good point. But no OOTB best practice will fit 100%.

            The question is how those best practices are implemented in the system. In the old days (back when I slung code) the majority of the changes were down in the application code. Then, when bug fixes come or new releases come out we get into the “source compare” investigation… (read this as “a project that takes time and resources” and often results in something being missed).

            There are other options such as procedural workarounds and building solutions alongside the core package that don’t impact the core code as well. Those can be good implementation best practices to prevent modifications. But when push comes to shove, architecture makes a big difference.

            Thanks for the comments!

          • broepke says:

            Agree Jim. Like I said in my original comment – PLM 360 just doesn’t have this problem because it was designed to not have it… and the proof is our constant releases and having every single customer on the same exact release of code (this is mandatory with cloud solutions as you know)…

            Great conversation!

          • Denis Morais says:

            I agree that no OOTB best practice will fit 100% but I do struggle with when is it good enough?

            What is your experience of using OOTB best practices with just configurations and no customizations for at least the first production phase?

            As you mentioned in your previous comment, there is no standard interpretation of what “configuration or “customization” means so I guess I will have to specify a simple one only for the purpose to make sure everyone is on the same page.

            Configuration: Options, workflows, settings, etc. which are modifiable by the products GUI
            Customization: Options, workflows, settings, etc. which are modifiable by not using the products native GUI

            Disclaimer: I make no claim that my definitions above are correct or complete, I just simply want to have a baseline for this question. If you want to clarify the definition, all power to you.

        • Changing source code is all too common. The line has blurred a little bit since the “old days” where everything an application did was embedded in the code versus configuration, but I would bet that if you ask a dozen consultants to define “modification versus customization versus configuration” would get (at least) a dozen answers. The proof is in what it takes to make a change the first time and what it takes to maintain it over time, what some people call the “long tail.” It might be interesting to look at some of the top packages and compare a hypothetical change and what it would cost over the lifecycle of the solution (and whether you would get stuck on the old release).

  2. furius says:

    Hi all, I’m developing an Aras demo project for my company (in the manufacturing industry) and I’m really liking the Aras approach, system architecture and administrator features. About the customization vs configuration discussion, I think that no one OOTB solution is really powerful to let you use only standard functions … it’s impossible you don’t have specific needs that requires a script to execute some operation on a status item change or some fields on the Item form that requires to be managed on some user action on the same form … the important thing is that switching from major releases of the software your script keeps working … for example switching from Aras 9.4 to latest Aras 10, which is rewritten in HTML5 and dojo, the form objects must be managed the same way, without requiring code adjustments or rewriting … this is what Aras is promising and I think it’s a great plus.
    What I don’t completely understand on Aras philosophy is why they chose to not develop CAD connectors on their own, as I think that in most industry sectors the PLM project starts most of the time from tech department and item/bom management needs … I will appreciate any comment on that.
    Thanks for this interesting article!
    Matteo

    • Thanks for sharing your experience with Aras, it’s very helpful.

      As far as CAD connectors are concerned, they are important for most manufacturing industries (including the majority that Aras supports). Are you questioning how well Aras support CAD data management or whether they develop the capabilities on their own? Truth be told, most PLM vendors don’t develop their own. They typically resell / OEM 3rd party products. They just bundle this into their cost. For Aras they added the costs on more openly due to the open source model.

      I hope that helps,
      Jim

      • furius says:

        Thanks Jim for your answer. I’m not questioning about Aras CAD support, I’m asking whether this is a winning business model or if it’s a risk for both Aras itself and the customers: i.e. we need a SolidWorks connector, so we need to implement Aras and select between the 3 Solidworks connectors available today … Well who can assure me that this connectors will be developed and maintained in the next few years? I would be probably more comfortable if Aras were my unique interlocutor … More: usually CAD connector and Aras have different GUI and user experience … Not sure it’s the best solution … I would like to know your opinion on this topic …

        • marclind says:

          Hi furius – I’m w/ Aras and maybe I can help you out. As Jim pointed out all PLM providers rely on outside parties for their CAD connectors, they just typically rebrand & resell. It’s a kind of highly specialized industry and there are a handful of firms around the world that have this expertise.

          That said the reason Aras has multiple connectors for different CAD systems is that the firms that work w/ the other major PLM providers are enabling their
          technology for Aras. So, they have multiple rev streams which makes their business more profitable for development they’ve done.

          Regarding different connector use cases, what we’ve seen is that there are numerous different workflows that designers from different industries and different companies have. The different connector approaches are optimized for specific scenarios and that makes it far better than one-size-fits-all force fit.

          The down side is that it can feel like looking at the soft
          drink shelf in a super market, there are lots of choices and you’ve got to understand your own process to pick.

          If you would like someone to assist specifically, just get in touch w/ us and we can help.

          Hope that helps explain.

          Take care,

          MarcL
          http://www.aras.com

        • Thanks for clarifying your question. I can see why it would make you less comfortable but perhaps you are just seeing behind the curtain a bit more clearly with Aras than with others? There is a lot to be said for continuity and consistency, those are legitimate needs that I would raise with Aras to make sure you are comfortable with their answers.

      • Steve says:

        Sorry but you just don’t know what you are talking about. You are referring to the large vendors versions of 10 years ago. You do realise that all the large vendors have very rapid development going on and your comments are way out of date. ARAS doesn’t develop cad connectors because that is the hard bit technically and commercially. They stay out of it and leave that complexity yo the customer or others to sort out. Get up to date before you put yourself out there as a guru.

        • Jim Brown says:

          Steve,
          Thanks for sharing, but I don’t understand where your feedback is coming from.

          The comment about the connectors wasn’t mine, and was primarily responded to by Marc from Aras. I don’t have any issue with Aras using 3rd party connectors. Lots of people use 3rd parties, including the large vendors.

          As far as the architecture is concerned, I’m not intimately involved in every system but I’m not aware of anyone that has a model-based environment similar to what Aras uses. Please feel free to educate me. I’m happy to bring some of my friends that are more in the know into the conversation if that helps.

          Have a great holiday season,
          Jim

  3. Scott says:

    If i recall from awhile back, it seemed that Aras had some SharePoint requirments?? or was it just integrated to SharePoint? If so, how will it work with 360?

Speak Your Mind

*