Customization is a core part of the Aras Innovator platform because we know that the unique problems of your business cannot be solved by a one-size-fits-all PLM system. If you've followed along with our Aras Fundamentals series, you've seen that almost every piece of the data model can be configured and extended to fit your use cases. This can be both a blessing and a curse.

This blog post will cover some common design principles that are not unique to Aras and explore how you can apply them to your Innovator instance. These principles are best considered from the very start of the design process, but they can also be a helpful guide if you're looking to refactor an existing Innovator instance as well. Following good design patterns can have a number of benefits from improved performance to easier maintenance to happier users.

Do Keep It Stupid Simple (KISS)

This principle argues that systems work best when they are kept simple and avoid unnecessary complexity. When given the freedom to fully customize a data model, it can be easy for things to grow beyond their original scope very quickly. The Aras platform respects its users with the power that it gives them, but it also asks for the same respect in return. We can apply this concept to a number of places in our Innovator instance.

Don't Use "Boss" ItemTypes

One common design problem I've seen is when one ItemType is responsible for a ton of different things. These are ItemTypes that have hundreds of custom properties and Workflows that seem to branch on forever. This can be a nightmare for users since even just trying to run a search means sifting through hundreds of columns most of which are off screen at any given time. This can also be a pain for administrators who are trying to add functionality or just perform routine maintenance.

Instead, it's better to try to limit ItemTypes to a singular purpose. If you notice one ItemType getting too large, consider if it would make sense to split some of the properties or responsibilities into a new ItemType entirely. As an example, let's consider a situation where we want to track where our Parts are being manufactured. We could add properties like city, state, and country onto our Part ItemType. What happens when we want to shift production of a Part to a new location or indicate that a Part can be made at multiple locations? At this point, it might make more sense to create a whole new Plant ItemType and link the Part directly to a Plant instead.

Don't Use Overly Complex Maps

It is just as easy for Workflow Maps or Life Cycle Maps to also suffer from the same problem of having too much complexity. Similar to ItemTypes, Workflows with hundreds of activities will be a burden on both users and administrators. If you notice a very large Workflow, consider options like adding a subflow or even having two different Workflows that are assigned to an item based on some criteria.

Don't Repeat Yourself (DRY)

This software design principle argues that redundancy should be avoided wherever possible. If a snippet of code is used in five different locations, it should instead be abstracted into a function so that when changes need to be made, they only need to be made to a single location. We can apply this same logic to our Innovator instances as well.

Do Use ItemTypes for Common Data

Good design tends to solve multiple problems at once. Let's go back to our previous example of storing information about where our Parts are being manufactured. It might also be beneficial to track this information in our Change Management process, so we know which Plant made the change request. If we were still using properties for city, state, and country to track this information, we would need to add each of these three properties to all of our Change Management documents and also populate each of these properties when a new one was started.

Instead, we've already wrapped all of that information into a Plant ItemType, so we only need to add one property to each of our Change Management documents. As an added benefit, if we want to track more information about the Plant, we only have to add a property to the Plant ItemType instead of to each and every Change Management ItemType.

If you have the same pieces of information stored across several ItemTypes, it might benefit you to extract those out into a single new ItemType which makes adding new functionality easier.

Do Use Poly Items

As another example, we can take a closer look at the Change Management documents in a standard Innovator database to see this principle in work. A Problem Report (PR) can be created to report a problem with a Part, a Document, or a CAD Document, and stores this item inside of an Item property. Since Item properties can only link to a single ItemType, the straightforward approach would be to create three different properties: affected_part, affected_document, and affected_cad. While we might be able to make this work, what happens when we want to allow PRs to be created for a new ItemType or for five new ItemTypes? Adding a new property for each new ItemType is cumbersome and bloats the PR ItemType with a bunch of additional properties that will not be used most of the time.

Instead, an approach that avoids this kind of repetition is to use a single Poly ItemType, and in fact, the PR in a standard database has a single affected_item property that points to the Change Controlled Item Poly ItemType. If we want to configure PRs to support one or more new ItemTypes, we would just need to add them as Poly Sources of the Change Controlled Item ItemType.

You can check out our blog post on Poly ItemTypes for some more information.

Don't Reinvent The Wheel

(The industry is still working on turning this one into a nice acronym.)

This principle argues that you should not spend time or resources writing functionality that already exists. This has the benefit of keeping the system small and allowing more development time for other problems. There is a number of common use cases that can be achieved on the Aras Innovator platform through configuration alone with no additional code.

Do Data Validation

One common use case is to ensure that the data users enter follows a specific format. Depending on the exact use case, this can achieved a few different ways. Filter Lists can be used to limit the selections of a dropdown to a subset based on some other value on the Item. If you're comfortable with it, you can also use a Regular Expression to match a property value with a pattern before it can be saved. 

Do Use Notifications

Aras Innovator also supports a number of built-in options for notifying users of work or changes to the system. EMail notifications can be configured as part of a Workflow or Life Cycle so that when a specific activity or state is reached, a user is emailed. 

In-app notifications can also be configured using the Message ItemType. These kinds of notifications are most commonly used to report system downtime for maintenance.

Do Restrict Access

There are a number of options to configure access control within Aras Innvoator. For more information on this, check out our blogs on the standard permission model and our extended forms of access control. 

Conclusion

While this blog post can help provide a strong foundation for new administrators, these design principles are not unique to Aras. The web is full of resources on how to design systems and code bases, and we encourage you to continue your design adventure past this blog post. If you have other design principles you follow for your Innovator instance, please share them in the comments below.