One cyber world story that captivated me as a youth was the character of “Ultron,” as depicted in comic books and in the movie adaptation of The Avengers. The character was a breed of artificial intelligence created with the intent of protecting the earth. But he turned against his creators, and against the earth itself, becoming a cyber super villain in the process. Origin story complete. Now queue the good guys.
Such is the nexus of superhero narratives. A good intention turns violently wrong, necessitating radical intervention. Movies and comic books love to prey on fears of killer robots and cyber intelligence. It’s an archetype as old as the myth of Daedalus and Icarus: technology going too far and humanity in its arrogance flying too close to the sun, then landing on those old Led Zeppelin t-shirts instead.
This amounts to a technical placebo. The cybersecurity plan once implemented gives the impression of the cure without any real medicine provided. And while the attempt to paint over one’s data security problems is not itself an act of malice, it can nevertheless have deleterious effects to the organization in question.
My own experience in the business world tells me that user oblivion is as dangerous as malice when it comes to cyber vulnerability. A corporate network with rudimentary cybersecurity and normal online hacking attempts, such as phishing scams or malvertising, can be more problematic than a secured network under a heavy cyber attack, such as ransomware.
A Cyber Attack from an ERP Perspective
While the tale of Ultron and the Avengers had itself a happy ending, the story of many businesses is not so optimistic. I once worked for a manufacturing organization that was on the cusp of an ERP (Enterprise Resource Planning) cutover. Painstaking work had been done to ensure that all steps were accomplished and that everyone was ready for a successful go-live.
Training, communication, data conversion—all of the pieces were in place. Cutover weekend went without a hitch; the steps in the go-live plan were executed without issue. The first day live went off without major problems. The normal hiccups associated with a new system surfaced, but nothing unexpected came the way of the ERP implementation team.
On the second day after the ERP go-live, users quite suddenly lost access to shared network drives. Soon after, they began receiving errors when trying to save ERP transactions to the database. Then they abruptly lost access to the application entirely. Amongst all of the communication, they hadn’t even realized yet that their email server had gone down and that they were therefore no longer sending nor receiving communication. Their network had been completely compromised. Chaos ensued.
When people think of the most common reasons for an ERP failure, they normally speak of over-customization, or a lack of management support. They rarely think of ransomware. But for the company in question, getting ransomed over cutover weekend was the first step to a cascading number of failures. In a panic, the company reached for paper-based manual processes while communicating to customers and suppliers over hotspot connections, using the employees’ own private email accounts. It was a cyber mess on all ends and resulted in late shipments, efficiency issues, unhappy customers, and months of work to resolve. Time and talents could have been spent on things other than cyber attack recovery—if only the company had been prepared through preventive measures.
Companies Running ERP Systems Can Avoid Ransomware
The moral of this story is less than heroic: there are no super powers that can save a network that is unprepared, or insufficiently prepared, for an attack. And there are no super heroes to jump in and avenge the wrongdoing.
Avoiding a cyber attack entirely is always preferable to avenging it after it’s happened. Many companies believe they’ve taken the steps necessary to mitigate a cyber attack. Enterprise risk management needs to be an ongoing activity, however, with business owners and executives involved in designing, understanding, and implementing a cybersecurity plan customized to the vulnerabilities of the industry under attack—because every industry is ALWAYS under attack.
A company’s greatest vulnerabilities are often the ones that they never realized they had. The greatest risks are the ones they believe they’ve already mitigated. The company in this tale of ERP implementation security chaos thought they had done everything internally to secure their network. But their efforts were done in a vacuum, without any impartial opinions or outside analysis. They weren’t out to create a monster, but their vulnerabilities created a monstrous problem. They didn’t feel they were walking on enemy ground because the villians were hidden and undetected by current cybersecurity measures.
The lesson to be learned here is that malice often masquerades as magnanimity. The most significant threats to an organization are often clothed in good intentions.
Are you feeling the cyber risk and wondering what you can do to protect your business? Don’t avenge your problems—prevent them before they’ve occurred. Get a security assessment, identify your vulnerabilities, and assemble your future. Know the problems you had yesterday and predict the ones you might face in the future of cybercrime.
Software development never stands still. I remember a time where I felt like I had finally come to understand DataSets, DataTables, DataRows and DataViews, only to have a much more experienced developer inform me that the System.Data namespace was old, antiquated, and no longer used in the development of cutting-edge applications. I had walked the prescribed trail, only to realize that it dead-ended in a software swamp.
The implications of such rapid movements in application development are significant, as software vendors often find themselves down similar dead ends and are forced to backtrack their way out of them. I liken software applications to my great-grandaddy’s venerable old axe: two new heads and seven new handles later, yet still seen by everyone in the family as the same axe.
Like the axe, Epicor’s Prophet 21 ERP application has been refitted over time. P21 helps distribution companies with a variety of features and capabilities. But like many such applications, the vendor found that over time, there was a need to reshape the application as to better position it for future use. Limitations to the existing architecture could not support the long-term needs of the industry. For that reason, Epicor has been reworking and fine-tuning its P21 architecture, moving towards a more scalable, interoperable and accessible application. Understanding where P21 has been and where it’s going can be of great use for customers, as to help them chart a course for the future.
The Old Prophet 21
Epicor’s E10 application followed an infrastructure that separated the user client, the application server, and the database itself. For someone coming from Epicor 10, P21’s original architecture might look a little strange. Traditionally, P21 employed a fat client architecture, in which a large amount of business logic was housed in the 32-bit client itself, and this client communicated with the database. A liability of this approach was the difficulty in deploying a full API that could be accessed externally. Also, this model created natural limits to the number of clients that could share a single terminal server, due to the size and scope of the fat client.
The New Epicor Model
As Epicor sought to develop a more robust and accessible platform, changes were made both to the client and the overall architecture. Epicor’s updated architecture inserted a new layer, referred to as the “Middleware Server,” that serves as an intermediary between the client and the database, and provides the foundation for API-level interactions.
Logic that had previously resided in the “fat client” desktop version was moved into the middleware layer. This architecture more closely resembles Epicor’s E10 application server-based architecture. Communication with the middleware server occurs using Secure Socket Layer (SSL) protocol. This allows you to connect without the need for direct access to the network or a VPN connection. A web connection and an SSL certificate are all you need.
Beyond the API benefits, another benefit of this approach comes from performance, as the middleware server supports as much as twice as many clients as can be supported by a terminal server with the traditional fat client. For customers with high user counts, Prophet 21’s new architecture supports multiple load-balanced middleware servers.
Client Types: Understanding Your New P21 Options
From a client interaction perspective, two new options were developed to support the new architecture:
Web Client: The web client is a browser-based capability, allowing customers to access their system from a PC, a tablet or a mobile device.
Hybrid Client: The hybrid client meets the needs of customers who like the look and feel of a traditional desktop application, but wish to leverage the capabilities and features of the updated web client. The hybrid client installs like a normal Windows application, and connects directly to the middleware server, without the use of a browser.
Desktop Client – A Line in the Sand
Initially, Epicor’s web client lacked some of the functionality available with the traditional client, making things like DynaChange screen modifications difficult to accomplish without a traditional client. But as Epicor ramped up the capabilities of the web client, these differences have fallen off, such that as of spring of 2021, new P21 features will be available only in the web and hybrid clients.
Epicor will slowly migrate away from traditional desktop application. By the fall 0f 2021, Epicor will no longer develop and release new versions of the desktop client. By the end of the year, Epicor will no longer release fixes for the desktop client. For P21 customers, this will require all users to migrate to the new architecture, both to retain support and to capitalize on the benefits of the newer releases.
The bottom line for P21 customers is clear: they can migrate to the new architecture or else work on the legacy platform, in an unimproved and unsupported state. In making this move, there are a few additional considerations to be made relative to the Prophet 21 deployment options available.
SaaS or Private Cloud Hosting for Epicor P21 Applications
Customers may opt to choose Epicor’s SaaS solution and place their application under Epicor’s control. This amounts to making two significant shifts, and many customers may not be sufficiently confident in Epicor’s SaaS solution to make the move. For customers suspect of SaaS, but looking for cloud options to host their new P21 architecture, private cloud hosting for ERP combines the new architecture with P21’s full functionality, without the hardware investments that come with an on-premise install.
Do you need help understanding your P21 deployment options? Do you need help migrating your existing architecture to take advantage of Epicor’s new features and capabilities? Give us a call — we are the #1 Prophet 21 consultancy in the nation, and we’d love to make you our “client”!
Are you a wholesale distributor and planning for new P21 features and capabilities? Please take our survey as a step towards understanding the new client architecture of Prophet 21 and how it relates to your future!
Begin by gathering both business requirements & software requirements
After all that inward looking, it is time for some more inward looking. It’s now time to set a basis for communication that will help keep current and future software projects on track. It’s time to begin the process of discovering and sorting out the real requirements for your business as they relate to software acquisition.
A conversation that leads to a complete requirement list
When it feels like every possible software and technology requirement is on the table, publish the list for your entire company to review it. Let the whole business know what software is under consideration and what you hope to achieve through the new software. This could be a subject for the next company-wide get-together or a post on the company intranet. Give everyone a little time to consider the potential requirement list and ask for feedback. The guy at the shipping dock might offer an idea no one yet thought of. A remote worker might demand additional integrations in order to optimize a virtual office.
Try to separate the team members from the business processes to let your selection project entertain every product or service that could benefit both people and infrastructure. This is especially important when considering ERP systems. Every software system has its challenges, but as companies grow and enterprise resource planning increases in complexity, due diligence in the software selection process will overcome both high level and more detailed problems along the way.
Your software selection team
Always choose a selection team that represents departments from across your business. You will have some managers and directors, but also include people who will benefit from working on this project by getting to know the bosses while contributing to the cause.
Your potential requirements list is probably quite long, so take a comprehensive approach when it comes to team building. When it comes to software requirements, specification is key. When you have a talented team working together to brainstorm every potential problem and solution, you’ll likely surface a long list of needs and expectations. Likely some of the items are duplicates, or very similar. Combine those and shorten the list a little. It is not yet time to strike any ideas out yet. And avoid assumptions: take time to understand what the proposals really mean lest any good ideas become diluted beyond the original intention.
Look for requirements that probably cannot be helped by this particular software acquisition. Don’t simply strike the idea; move it to another list for future consideration. Someone thought they had a requirement to be solved, so keep it as it still needs a resolution, just not now with this particular software.
Prioritize software selection process outcomes
Prioritizing is the next step. Split your list into one section that truly is a requirement and another that is very nice to have but truly less than a requirement. Sort each section into your best consensus of priority. Theoretically, the required list is all number one, but there is still a good chance that less than 100% can be attained. A software selection process doesn’t always end with a new software. Keep an open mind when considering all options and how they might affect your business. Stuck on old software or technology? A growing manufacturing company will struggle without the move to an ERP software, and an ERP system will most likely benefit from a cloud hosting environment. Know your history and know your goals and choose your system and its deployment model wisely.
Communicate still more
Time now for more communication. This time upwards: meet with your executive sponsor and consider each requirement again. Be certain your sponsor agrees with your breakout of priorities and good ideas, and also with the sorting. Your sponsor might have other ideas too on how to revise some items, or they might have entirely new items for the list. Your executive sponsor must agree with the requirement list and commit to supporting your future efforts.
Communicate again with the rest of your business by sharing the current requirement list and a second list of items you hope to achieve. Let all know you will soon look for software that meets every one of the required points and as many as possible of the nice-to-have list as well. Be sure to thank everyone who helped with requirement points and with the enterprise evaluation of your requirements.
Will cloud technology change your software selection process?
Could a private cloud environment save you software headaches in the future?
Chat with us now to get a personalized demo of what your business would look like in the cloud.