Part 3 of 5 in a series of posts focused on the Infor Product Strategy
In the last post, we talked about the complexities of adding features to a core ERP, using a dice analogy. As you add features in this way, it exponentially increases complexity.
As Infor adds new functionality, we can reduce the complexity by externalizing functionality into separate autonomous pieces.
We’re doing it through a component-based strategy. That means software components, built on modern technologies, which are delivered in a SOA-based framework. We are moving in this direction to solve the complexity problem, but also because this is how customers want their software.
What I mean by this is that no customer has ever come to me and said, “I want you to improve the core kernel of our ERP system.” They come to us to add functionality to specific modules. For instance, the controller asks for improvements to the general ledger or the VP of sales wants more flexibility for different types of pricing in the pricing module.
Unfortunately, as I discussed in previous posts, ERP system modules are so tightly coupled that it’s difficult to upgrade one module without impacting the whole system. That creates business disruption that we must avoid.
The solution is software components. While the difference between a module and a component may seem like wordplay, they are fundamentally different.
A module is tightly coupled at the business process and database layers, essentially part of the core application. It’s separate only in the sense that the vendor licenses it separately but it’s still part of the core ERP. You can’t mix and match modules.
A component is self-contained and autonomous, but can be attached to an ERP system or other solutions to extend or upgrade or create a new business process. The component architecture is based on SOA, which provides the loosely-coupled interoperability and ultimately delivers the flexibility to independently manage and upgrade your systems in a way that hard-coded modules can’t approach.
We’ll refer to how this entire environment interoperates and coexists in a later post. SOA now allows us to operate in a distributed framework, eliminating the interdependencies and complexities that arise from putting all our eggs in one ERP basket, but still maintain that holistic view and business control.
One of the advantages of the component approach is that, because they are autonomous, they can be leveraged across multiple business-specific ERP platforms. Some people have pointed out that this is an advantage for Infor, a way to rationalize development for our multiple ERP systems.
They are exactly right – but that’s not the whole story.
It’s a tremendous advantage for our customers as well, who want value for maintenance, which they will get it when we can focus all the resources of global development teams into specific software components that are designed to benefit our entire product portfolio as well as those of other vendors. It’s inherently open.
These components will have the best intellectual property from across our product lines built-in. For instance, we can take the pricing expertise from across our entire global development team and build the best pricing component available – and one which all of our new and existing customers can use. Customers will benefit from a hugely expanded list of business-specific features or simply turn off the ones they don’t need or that aren’t relevant.
Next week, we’ll talk about how we are focusing in on the components to develop, through what we call the “Six Pillars of an Enterprise.”
Posted by Bruce Gordon, CTO