When you look at the PLM market, the word “Platform” is used quite a bit. However, depending on what you are looking at, that word can take on a broad variety of meanings. On one hand, this could mean that all applications use a common data model, user interface, and data repository, while on the other hand, the term is used to refer to a range of disparate applications that are owned by a single vendor. So, how cohesive is your platform and why does it matter? The answer can be found in a rather unexpected place—the space that houses the building blocks that make up applications, or in Aras’ terms, platform services.
Who cares how applications are developed as long as they work? Well, there are several reasons that a unified platform, using Service Oriented Architecture (SOA), is ideal from a business perspective.
- Customization & Custom Applications – Aras’ Service Oriented Architecture not only enables our developers to reuse services to build applications, but it also empowers our customers to use these same building blocks to develop their own applications. For example, if you wanted to build an application to facilitate the unique way your organization responds to cost inquiries, you could leverage pre-existing security, workflow, visual collaboration, and reporting functionality and customize—versus coding it all yourself.
- Maintenance & Upgradability – When applications are architected in a common manner they are far easier to maintain, thus lowering the burden on IT. As the Aras platform undergoes rapid development, services are improved and new services are added. When it comes time to upgrade your platform, users of all applications on the platform gain the benefits of the upgraded services. The benefits of upgrading multiple applications with a single project will appeal to any IT department, particularly if it is included in your subscription price.
- Consistent User Interface – When all applications (including custom ones) are built with the same building blocks, they naturally have the same look and feel. The use of platform services ensures that visualization, searching, reporting, collaboration, and many other aspects of each application are identical. Commonality between applications also reduces the need for training and reduces the number of logins to one.
Reusing Services Enables Industrial Low-Code
The Aras library of services is broad and constantly developing to make the overall platform stronger and more versatile. While there are too many services to list here, they fall into certain functional groupings around access, collaboration, visualization, etc.
While these platform services can be as fundamental as authentication, workflow, versioning, or reporting they also can be called upon and reused to create more complex services such as Secure External Access, Visual Collaboration, or Dynamic Product Navigation.
This services upon services approach creates trickle up functionality for overall applications. For example, performance or functional improvements to the workflow platform service will ripple through applications, and every time improvements are made to search functionalities, larger services like Dynamic Product Navigation and Graph Navigation realize the benefits of these improvements.
Architecture Matters
At the end of the day, architecture matters. Service Oriented Architecture enables an open, flexible, scalable, and upgradable platform in ways that rigid, side-by-side applications simply cannot. In fact, in Mark Reisig’s blog on the subject he points out:
“I contend that more functionality in a given area is useless, if you do not have an open, flexible and sustainable platform that allows you to take advantage of it. If you cannot “plug and play” and seamlessly stream product data across your Digital Thread, then all you have done is added another disconnected island of functionality. These chunks of monolithic architectures “end up looking like pools of mud” (Simon Brown).”
If your “Engineering Platform” relies on applications that are built with different data models using different components and various methodologies, can it really be considered a “platform” at all? If your platform is not built on the same pieces—what you actually have is a bucket of tools.