According to sociologists, my brother and I are from the same generation. Sometimes I wonder… with nine years between us, we occupied two very different points of time, especially when it came to music. My brother was a man without a hat, a child of the 80s, while I left my toque at home so I could let my hair hang low à la Kurt Cobain. But in spite of the age gap, we shared an abiding mutual interest in contemporary sounds, and my brother once remarked, when comparing my Pearl Jam to his Bruce Springsteen (Springfield, after all, had been his generation’s Eddie Vedder), that my music was sure easier to dance to. That was certainly a surprise to me. I always thought of myself as a double-left-foot biped, and moreover I’ve long suspected that I have no genetic predisposition to dance—our father’s visits to the local dancehalls were to roughhouse, not to two-step, and I’ve often wondered if he only met my mother because he couldn’t find another ruffian to dance with that night.
For many years I was close with a World War II veteran who also met his spouse at a dance hall. As a man of the Greatest Generation, he felt the Great Depression firsthand, served in the European Theatre, and returned to the States to become a successful business owner and family man. But if you asked him what he really was, he’d tell you he was a dancer.
His greatest joy was to fling himself and his dancing partner across the parquet of a long-forgotten ballroom, with the band laying it down in the corner. And whenever I’d make it home to see him after an extended consulting gig, he’d ask me if there were any polka bars in the town where I’d been. It broke my heart to disappoint him that I couldn’t find a polka venue to spend my nights, as his dance hall culture had long since become an American timepiece.
My crowd, for one, never caught onto it, and I personally never learned how to dance. I didn’t exactly need to be Jean Erdman to make my way through a mosh pit, and my crowd later gravitated to house and electronica music, where dance meant minimal vertical sufficiency while moving to the beat. Even still, I found one abiding continuity between my companion’s old-style Polka and my Mosh. Always keep moving, always keep to the beat. Or, as he loved to say after reminiscing about his dancing days, “Don’t ever let grass grow on your wheels.”
Good software is like a good dancer—it doesn’t stop moving.
Has anyone on this dance floor ever worked on a green screen application? Or does anyone remember the look and feel of Netscape Navigator? In spite of my nostalgia for 90’s apps, baggy jeans, three-chord anthems, and a full head of hair, I realize that software doesn’t stand still—a software package that can’t dance soon becomes a two-left-feet wall-flower. And a software package that can’t teach its users how to dance might lose out to nostalgia. It was the twist that put my polka buddy out for good: “I just can’t understand how a guy can do nothing but put out cigarettes all night on the dance floor and call that dancing.”
Fresh off Epicor’s annual Insights conference, I’m ready to tango and tangle with all the new capabilities that are in development or already in the process of being released to the user community. Needless to say, there is a whole lot of shaking going on at the great Epicor Code Laboratory, where Epicor’s waltzing wizards ply their trade. And the release of this functionality for public consumption is more than just movement for its own sake. Like a good ballroom turn, software release requires a cadence, and Epicor has been hard at work perfecting its rhythms.
New releases of Epicor functionality conform to the Major.Version.Release.Update structure.
For example, a company on version 10.2.300.4 would be broken out in the following manner:
Major: 10
Version: 2
Release: 300
Update: 4
These different elements are further described below:
Major:
Major Product changes occur when fundamental architectural changes are made to the product. From a customer perspective, a new product level may require significant changes at the database or application server level.
Any customizations in the previous product level need to be retested, and many may need to be rewritten entirely.
Significant functionality or user-interaction changes may also be included, which may require retraining of the user community.
The most obvious example of this was Epicor’s monumental move from 905 to E10. This was a fundamental change to the database and all the levels of its server-side business logic.
Major Product deliveries are planned to occur approximately every 60 months.
Version:
New versions may have a significant impact on Epicor’s data schema—fields may be added or removed.
For example, Epicor’s move from its 10.0 to 10.1 brought with it important improvements in performance, stability—not to mention a ton of new features.
New versions of the software are planned to occur every 18 months.
Release:
Releases are fully-packed new instances of the software, with significant functionality enhancements, but the enhancements are limited as to allow for an easy upgrade process from a prior release.
Releases (or patch-levels) include additive changes to Epicor’s data schema, but no deletions.
These changes may have minor impact to BAQs, BPM’s, and screen customizations, but these are smaller in scope and gravity than with new versions.
For example, in the .300 version of Epicor’s 10.2 product, Epicor’s License Plating (PCID) functionality was greatly enhanced.
New releases are deployed every 6 months.
Update:
Updates are smaller, release-specific changes, constructed with the intent of addressing issues within the current release. Changes are restricted to minimize disruption. As such, technology or schema changes are not present in these packages.
User training is not required for updates—the system will function as it previously had, only with fewer issues.
Updates are released every 2-3 weeks.
Within this structure, it is important to understand the rationale of Epicor’s release cadence. The goal of their rhythm is to minimize business disruption, while at the same time quickly providing resolution to issues, and providing functional enhancements at a reasonable rate. The implementation of this cadence has allowed Epicor to balance functionality and support, while allowing the customer base to focus on running their businesses without interruption.
For cloud customers, these upgrades happen automatically, with prescribed periods set aside for preparation, testing and validation, prior to deployment. For customers who have the application installed on-premises, the cadence is customer-defined. I have found that customers who keep their system up-to-date reap the benefits of this decision—new versions are easier to maintain and support, and they perform better and have fewer issues.
As such, my advice to customers with regard to the frequency of upgrades is simple: learn how to dance and don’t ever let grass grow on your wheels.
Have a question about Epicor ERP, Prophet 21, or ERP system updating cadence? Let us know.
I’m Jeff Klaubert, with the EstesGroup. You know, I think by now we all accept that we are living in a digital and cloud-based world moving forward. As a matter of fact, according to research conducted by the Enterprise Management Associates, in 2017 alone, companies will move 19 percent of their applications to the public cloud. They’ll move an additional 10 percent to a private cloud. So think about that. Just one year, companies are moving 30 percent of all their applications to some form of a cloud environment.
And, of course, the cloud has been with us for a number of years, so it’s not just that 30 percent from this year. It’s a big shift. And the research goes even further. They concluded that today, 45 percent of all companies are using the public cloud services of at least three providers. So make no mistake. We are in the midst of a major digital transformation that is impacting all industries. And the fact that you’re watching this video suggests that you’re probably in the middle of your own transformation or certainly evaluating the strategies that make the most sense for your business.
In this video blog, we’re actually going to cut through all the jargon and hype, and we are going to define and compare and contrast the different types of digital deployment scenarios you should be thinking about for your business. And, you know, to start off with here, let me just kinda set-set the-the baseline, all right? This video is not about telling you that you need to go to the cloud. It — we don’t know that, right? In every business is going to be different. But what’s crucial is that you understand the differences between the-the-the deployment scenarios and you use the terminology correctly.
We hear these terms “cloud” and “hosted environment” and “hosted applications.” Throw in “virtualization” in there. People use these terms interchangeably as if they mean the same thing as if there’s just like one common general digital deployment scenario, and that couldn’t be further from the truth. Cloud and hosted applications are very different solutions, and it’s crucial for you to understand the implications for your business so that you can evaluate your options with clarity.
So, over the next two videos, we’re going to, one, define — simply, let’s define, using industry-standard definitions, what cloud is and what a hosted application or a hosted environment is. That’s what we’re going to do in this video. In the second video, we’re going to compare and contrast the two deployment scenarios using National Institute of Standards and Technology — NIST — using their five essential characteristics of a cloud solution. So at the end of these two videos, you are going to understand how those, how these different deployment scenarios relate to your business and what makes the most sense, because no one size fits all.
Now, before we get started into that, I actually want to start off with a little, setting a little context, that cloud, and hosted applications, these models are not new by any stretch of the imagination. They’ve been around literally for decades. As a matter of fact, IBM introduced the underlying technology of cloud, which is virtualization, all the way back in 1972. They called it VM virtualization. And they did it — here, check this out — to create an agile mainframe that had the ability to share resources dynamically in response to a changing environment. Now, doesn’t that sound pretty similar to the cloud pitches of today?
And, interestingly enough, in that same year, SAP introduced a revolutionary new application that they called Enterprise Resource Planning in 1972, which enabled customers to take orders and track inventory in real-time to provide better visibility and control to the business and provide enhanced customer relationships. Now come on, folks. That was 50 years. So that’s proving out the adage that the more things change, the more they stay the same. I want to, I want to set one more context here. Some would argue that the current version of the cloud is nothing more than management’s response to needing to get more things done quicker.
You see, the pace of change has accelerated so much that oftentimes the traditional on-premise IT strategy just can’t keep up with the pace of business. So in order to remain competitive and innovative in today’s hyper-competitive and-and increasingly global environment, it really does take the cloud and digital business models. Okay. Let’s get right down to it. Let’s define cloud and hosted applications. Let’s start off with Gartner’s definition of cloud. They define cloud as a style of computing where massively scalable, IT-enabled capabilities are delivered as a service to external customers using internet technologies. Did you notice there was no technobabble in there?
They’re talking about business capabilities. Now go back to my argument that some-some would say cloud is nothing more than management’s response to needing to get more things done quickly. Well, what is a capability? You know, at its core it is the ability to get something done. So that’s what cloud is doing for us. It’s enabling us to accelerate how much we need to get done, where we can get it done, how we can get it done. It’s really exciting, actually. Now. Let’s get a little more, you know, infrastructure-y about this. Let’s look at the National Institute of Standards in Technology. NIST. Let’s look at their definition of cloud.
They define cloud computing as a model for enabling convenient, on-demand network access to a shared pool of resources, meaning servers, storage, network, applications and underlying services — here’s the key thing — that can be rapidly provisioned and de-provisioned with minimal management effort or service provider interaction. Now think about this here. What in your current on-prem IT environment that is significant enough to run an aspect of the business can be rapidly provisioned or unprovisioned today? Probably nothing. [laughs] And, in fact, if you can do that, you’re on the cutting edge, and you’re probably on the cloud, and you probably know that.
Okay. So those are two definitions of cloud. Let’s compare that to what a hosted environment is. And a hosted environment is pretty much taking your current environment — you have an entire technology stack, so you have your own manufacturing ERP software, your own services, your own network, all that stuff — and simply transporting it to someone else’s data center and letting them manage that. Major differences between cloud and what I just described there. So in a hosted environment, you still have to — you or someone else has to maintain your own software, and you still have to deal with version issues or how many versions back are you. Or, you know, you have customizations that are required to meet your business requirements. Will they be carried forward to the latest manufacturing ERP software?
You still have all those concerns, and you still have to implement that on a server, both whether it’s physical or virtual. You are going to own that, buy that, or pay for that somehow, and someone’s going to implement that. And that server’s sitting on a network in a data center, so you got ping, power, and pipe. And you have your own silo, your own stack of technology compared to and contrasted to the cloud, where you have a shared pool where you can dynamically have access to all of the underlying resources. As a matter of fact, one of the key differences between cloud and even a virtualized environment is that cloud adds orchestration and automation so that you get to extract your applications in your workload from the underlying infrastructure.
You don’t have to worry about that. Think about it like a-an-an automobile, right? Pretty much any car, anywhere in the world, you get into it, and your interface with it the same way. It has a standard set of capabilities and functionality that pretty quickly you can, you can, um, understand and adapt with and get using it, versus a hosted environment. Think of that like, you know, a water tank. You have to own the tank itself. You’ve got to make sure there’s enough water in it. and then there’s must be a hose to get it to you. So those are the differences between cloud and a hosted application.
As you can see, they’re completely different. So, in the next video, we are going to go just a little deeper, and we’re will use NIST’s, definition of cloud. Well, actually we’re going to use their five essential characteristics of the cloud as a framework to compare cloud and hosted environments from a functional perspective. We will be pretty granular about this. And at the end of these two videos, you will understand the difference, and you’ll be able to better evaluate your options. Now I want to leave you with this thought that, you know, no one solution fits all businesses.
So our approach at the EstesGroup is we want to get to know your business. We want to talk with your people. We’d actually like to visit your facility and walk your production floor and understand your processes. You see, we’ve been implementing manufacturing ERP software systems in the mid-market manufacturing space since 2004. Our people understand manufacturing and distribution processes. We’ve run the same systems you’re running today or are considering implementing in your business. Invest an hour of your time, and let’s do a digital process review and see how ready we both are to help you do your own digital transformation. I’m Jeff Klaubert, and we’d love to talk with you.
Schedule Your Digital Transformation Review conversation with us.
Continuing our EstesCloud IT Security blog series on the importance of cyber security, which began with why you should write a security policy, we continue with our next edition about malware.
A server malware protection policy is designed to protect your systems from cyberattacks. Malware is software with the intention to damage or disable computers or computer systems. It can be code, spyware, cookies, viruses, worms, Trojan horses, and more that compromise your PC and possibly your whole network! They can be very expensive to correct, not just in lost productivity, but also in equipment restoration or replacement.
Exploiting vulnerabilities in the hosts, communication networks or perimeter systems
Convincing a user to install infected software/apps
How and why to create a malware policy
Just as with any policy, you will begin with the “Why”. Why are you creating the policy? Presumably it’s to minimize the likelihood and the subsequent impact of an infection.
Let’s begin with some more basic questions:
Who does it apply to?
What equipment is included?
What are we talking about?
We can then ask questions that lead to solid definitions:
What is malware?
What damage can it cause?
What is an anti-virus program?
What is filtering software?
How is the malware policy activated?
Where do we go for additional resources?
The malware policy itself can be stated in various ways:
What the anti-virus program is, who installs it and what devices require installation.
What to do in case of new devices, suspected infection, suspicious or problematic software links.
How and when scans should be run and if they are manual or automatically scheduled.
How the software should be monitored, updated and management of the required updates
Rules about installing applications, downloading information, updating software, and opening attachments.
The use of filtering programs such as website blockers and e-mail scanning.
Rules about spam, junk mail, chain e-mails, social sites and any other applicable areas of potential risk.
Then it might be a good idea to make a malware policy response plan
Sometimes all the policies, plans and procedures can’t stop a cyberattack, in which case you may consider a malware response plan. This response plan should be included as part of the malware policy.
The malware policy back up plan kicks into action when there is an infection or a threat. It is typically a flow chart of action steps to mitigate as much damage as possible.
Step 1: Determine if there is a threat and how significant it is.
Step 2: Isolate the problem. The solution may require blocking internet services or shutting down a server or workstation to prevent further infection.
Step 3: Remove the problem. This is what the anti-virus programs are designed for. It may simply be a scan, repair, re-installing the OS from original disks, or even replacement of equipment.
Step 4: Recovery. Once the problem has been isolated and eliminated, check the systems for any other problems. Depending on the depth of infection, you might consider the venerable “format C:” to remove most (but not all!) infections. Be careful you don’t re-infect your system as you restore data, and make sure you close the attack vector so you don’t get re-infected! It is absolutely essential that your backup and disaster recovery plan be 100%, as some infections (like CryptoWall) cannot be removed!
Step 5: Communication. Talk about the malware was able to cause damage. Talk about the situation with users and make any needed adjustments with the IT company to avoid it happening again in the future.
The bulk of information involved in a malware policy is in the communication to users about what it is, how it can be prevented and what to do in case there is an infection. With EstesCloud Server Care, ClientCare, and our HIPAA Compliance Care antivirus and filtering software installed, incidents can be avoided and you’ll have support if there is an issue.
CompleteCare:Maintaining your own IT infrastructure is expensive and frustrating. EstesCloud CompleteCare combines the benefits of our ServerCare and ClientCare programs into one comprehensive program that protects your entire IT infrastructure at a predictable fixed cost. Let the EstesCloud team become your Trusted IT Advisor, so you can get back to growing your business. Let’s start the conversation!
ServerCare: A proactive approach to IT that includes regular scheduled maintenance and monitoring is essential to maintaining a healthy network and a productive staff. EstesCloud ServerCare will give you peace of mind knowing that our team is continually watching and caring for your servers. Discover the Benefits of ServerCare.
ClientCare:Proactive support for your desktops, laptops, and mobile devices. We provide all of the monitoring, patching, and security tools for your systems, plus full access to our help desk services 24/7/365. EstesCloud ClientCare will ensure your valuable data is secure whenever and wherever it is needed. Take control of your systems today.
How much fear is behind the tens of thousands of daily searches for backup disaster recovery?
How do you know your backup recovery will work? What will you be able to restore, really? Globally, the search is on for the best backup and disaster recovery solutions for businesses. As it becomes easier to create and share data, the need for backup services increases. Fortunately, new cloud computing technologies allow for endless data sharing and syncing, and these interactions can be protected by replication services.
Is backup testing part of your business continuity plan? Let’s consider the effect of disaster drills throughout society. Why do schools still have fire drills? Why do day cares still practice tornado preparedness? Because natural disasters happen, we do well to stand prepared for the unfortunate extraordinary. In fact, disaster recovery is not a matter of “if,” but rather of “when” in the cybersphere. And, in the best case scenario, all the planning was for nothing. Because, of course, we would rather be prepared and not need data restoration than be caught unaware. Backup testing is a critical part of any disaster plan.
