Understanding Enterprise Application Architecture

In this post, I will highlight the typical portfolio of Enterprise Application requirements, and touch on an architecture that is better aligned towards leveraging the benefits of an off-the-shelf software application, while continuing to pursue the customization’s required to have the final solution align with the unique business processes and user experiences of each unique organisation.

A Typical Company,

• Buys (Raw Materials or Products to Trade)
• Makes (Saleable products and/or manages inventory
• Sells (Sells Finished Products and/or Consulting Services)
• Hires and Pays Employees

To support these core functions, the typical company invests in a Business Application like an ERP system from SAP, or products as basic as QuickBooks, which allows them to automate the core regulatory and compliance functions around:

• Buying – Accounts Payables or AP, to manage purchasing and paying vendors
• Manufacturing – Costing, Production Planning, Warehouse Management (MRP)
• Selling – Accounts Receivables or AR, to capture and process orders, and track collections
• Hires and Pays Employees – Automating payroll, salary disbursement and expense reimbursement

While almost every company has the same needs in relation to the core software modules from a regulatory or compliance standpoint, the challenges arise in extending the collaborative features touching each of the core functions, to align with the unique way in which the processes have been defined within the organization. Every organization needs to have the software application work a certain way, to meet the practical process requirements and user experiences required, to ensure the application can be used effectively by its employees.

As an example, we will look closer at the Purchase Management function which is illustrative of why the need for customization of off- the- shelf Accounting packages arises.  The basics of issuing a PO and tracking the payments to the vendor are handled routinely by the likes of QuickBooks or SAP.  They do an excellent job of handling the regulatory and compliance requirements around tracking of payments, as well as the calculation and disbursement of taxes.

The challenge for every organization is in the collaborative side of the Purchase Management function, which usually is unique to the operational processes defined within each organization. These unique processes create the need to ‘customize’ the off the shelf software products, and are the cause of most of the pain related to maintaining and using these software packages.

In this Purchase Order example, once a PO is finalized, it is simply an entry into the Accounts Payable Ledger, for a purchase of goods and/or services made with a vendor. The areas where organizations get into unique scenarios around the purchase process are highlighted below,

• Purchase Requisition Workflow – Companies want to have a requisition process, where the requirement for any product/service is requested by an Employee or Department, after which it is reviewed and approved by different stakeholders, prior to a Purchase Order being created.
• Cost Allocation – While the accounting entry is a Purchase Order entry resulting in an Accounts Payable record, each PO may need to be mapped to the accounting Cost Center, to decide which department or from which approved budget code, the specific PO needs to be applied. So approving a Requisition may require to see how it impacts the budgets allocated for a specific cost center or project, prior to having a PO issued.
• Vendor Quote Management – Some companies may want to receive multiple Vendor Quotes, before finalizing a Purchase Order with a specific vendor. In such scenarios, the requisition that is approved, results in submission of the requisition or an RFQ to multiple vendors, against which the vendors submit quotes. The quotes are evaluated internally, after which a decision is made on which vendor to issue the PO to.
• Purchase Consolidation – In some scenarios, requisitions may arise from different departments for the same product. E.g. New Laptop computers, where different departments want to procure new laptops. In such scenarios, the purchase department may want to consolidate the different requisitions into a single requisition that is then sent to the vendors for quotes. Since an increase in purchase quantities qualify for vendor discounts, such consolidation allows the company to save on purchase costs.

The more efficiently a company handles their processes, the more competitive they become.   Enterprise Applications were not created for agility, they were created to enforce a pure vanilla, ‘best practices’ way of doing things, which is why unique ways in which the Purchasing Process may need to be setup as highlighted above, are required to be achieved. The question then is whether such custom requirements should be achieved by ‘Customizing’ the ERP system itself, or whether there are any other more practical and efficient options.

While customizing the ERP is the default thought process within most organizations, i have highlighted below, some of the challenges and issues that arise out of customizing these monolithic programs:

• Implementation Lead Time – While an off-the-shelf product can be installed and setup relatively quickly, it is the customization requirements that delay the implementation to take months if not years for completion.
• Additional Costs – There is significant cost incurred in executing customization’s, as proprietary skills on a specific product are required, and the hourly technical consulting rates can be exorbitant.
• Significant Cost to upgrade – If no customization’s are implemented, most ERP vendors support upgrading their products to the latest version very easily, with the upgrade supported with tooling provided by the ERP vendors themselves. But when you have customization’s implemented, then upgrades can get quite complex, with the need to first migrate the customization’s, and then re-test the migration with all historic data migrated, which is time consuming, expensive and complex.
• Product Support – For many migration projects, by the time the migration is ready to go into production, the vendor has released at least one, if not several additional upgrades to the product version. So the newly migrated version itself is outdated when it goes live. If the client chooses to avoid a migration, as they can manage with the functionality of the existing legacy version, they are eventually forced to migrate when the Product Vendor retires support for the version that they are on.

So is there an alternative to meeting Enterprise Application customization requirements?

The following steps offer a way to realize the off the shelf benefits from commercial ERP or Accounting products, as well as an approach towards tailoring  the processes around them to meet the specific business requirements of each organization:

Step 1 – Avoid Customizing the ERP system like SAP, Oracle or QuickBooks.

Step 2 – Ensure the API (Application Programming Interface) Module license is procured with the prepackaged off-the-shelf application licensing, which ensures support to integrate with the ERP functionality and data.

Step 3 – Deploy a ‘No-code’ Application Development platform, to be the platform on which customization’s would be conducted.

Step 4 – Create all customization’s for the collaborative processes in a ‘No-code’ application layer, while integrating with the core ERP system through the API, or through read-only access to the ERP’s data layer for direct data access.

There are many ‘No-code’ platforms in the marketplace today, that support such a capability, and the ClaySys AppForms platform is one of the leading products in this space. By following the approach above, the core ERP can always be upgraded, as no customization’s are done on it, and so upgrades can be conducted easily using the tooling provided by the ERP Vendor.

Since all customization’s are done in the No-code Application Development platform, it is easy to achieve the customization’s required, in a fraction of the time, as the traditional software development life cycle is circumvented by the no code configuration paradigm that is significantly more productive.  Conservatively speaking, there is an 8x to 10x productivity gain, in comparison to hiring expensive specialists to hard code the customization’s within the ERP itself. Since the no-code platform integrates with the ERP using the API module, the customization’s are not limited, and full read/write access to the core ERP functionality can be managed through the API.

Since the API layer does not change significantly during the version upgrades of the ERP, carrying forward the customization’s done using the no-code layer to support the newer ERP Versions are possible and quite feasible, and significantly faster and less expensive than the migration of customization’s done within the ERP itself.

The no-code platform itself is futureproof, which means every update to the no-code platform can be done by carrying forward all functionality created with any earlier version of the no-code platform, so there is no upgrade related pain point in this layer.

Security is also enhanced, in that customizations on the no-code platform do not require each form to be inoculated against the 60+ known vulnerabilities compromising web forms. The no- code forms are presented to the users via a rendering engine or application browser, which becomes the one place to keep the web form security up to date with blocks against all the known vulnerabilities, which are then inherited by every form created with the platform. The same principle is used by the browser vendors, as they constantly update their offerings as new vulnerabilities are identified, but all HTML or HTML5 websites still render just fine.

The concept of letting the monolithic systems of record like ERP do what they are good at doing, and using an agile no code platform to handle the customization’s required over and above what the ERP system offers, in a fraction of the time and cost, makes perfect sense. The business will get the customization’s much faster, and IT will avoid the need for time consuming, and expensive upgrades.

The ClaySys AppForms platform was envisioned, designed and developed to address exactly the kind of scenarios that i have highlighted in this post.