Unique architecture

Architecture Philosophy

Jeeves was founded in 1992 on the idea that no two businesses are alike—and that software should celebrate and automate the processes and workflows that differentiate one company from the next. We knew the core problems facing most ERP system users: either they were changing their business in order to use their software (losing sight of their original vision while wasting time on process workarounds and workflow mismatches), or they were changing their software to preserve their business processes (throwing money at upgrades and customizations both new and old). We knew there had to be a better way—we needed to solve these problems and, at the same time, deliver a lower total cost of ownership to end users. So we set out to design an ERP software solution that could deliver easily-built, highly-custom implementations that that were also easy to upgrade. We wanted to build an ERP software solution that would allow companies to implement their chosen business strategies and allow them to be different. We envisioned an ERP software solution that would be easy to modify to help companies grow, adapt to changing market conditions, and better serve their customers. The Jeeves ERP genius architecture is the result of our desire to solve these real problems with the ERP market. Our architecture is ”genius” not only in the way that it’s technically built, but also in the way that it offers undeniable value to our customers.

The Architectural Evolution

The many definitions of the word architecture describe the process and result of planning, designing and building physical structures. We study the architecture behind buildings and cities as works of art that can be classified into categories of similar style and approach. Software architecture is no different. Architecture is responsible for software usability, flexibility, and longevity. And, just as with buildings, software architectures can be categorized and classified. Historically, we can trace different software architecture styles according to the core problem-solving ideas behind different ERP systems, including their advantages and limitations:

Best Practice Systems

Many of the ERP systems available today are rooted in their evolution from the demands of the very first customer to those of the next customer, and so on and so forth. More often than not, these architectures are the accidental backbones of on-premise systems built to fit a handful of companies—but that end up being used by many companies. And more often than not, these architectures are plagued by rigid databases and older technology that are difficult to evolve over time. Changes in one area of the system often have deep consequences elsewhere in the system. Systems of this type, modeled on a small core of companies, are generally referred to as “best practice” systems, since they implement the practices of a selected group of companies. Unfortunately, these systems rapidly become difficult to change and require you to change your processes to follow those of the original group of companies. Customers coming from these systems beg for the ability to make easy customizations to support their competitive differentiators.

Configurable Systems

Next came the 10,000-switch gorilla, a popular architectural direction during the 1990’s, led most famously by SAP. These systems were built to meet the needs not of a few select companies, but of every company, no matter what industry they worked in. Every possible requirement was included in the code base, and all you had to do was “configure” the system. After customers select from the thousands of parameters and data views available to them, they then embark upon a tedious and lengthy custom development process. Implementations tend to be long and complex, made that way by installing, sorting through, configuring, and testing massive amounts of code. And, just like prior systems, the 10,000-switch architectures are difficult to evolve and test. As a result, they became nearly impossible to upgrade without a full reimplementation. Customers of these systems rapidly become frustrated with their aging technology, the cost of ownership, and the massive cost to upgrade.

Multi-Tenant SaaS

In the 2000’s, the backlash from these types of systems sent vendors running in the opposite direction. Leaving the idea of highly custom, costly systems, software vendors went back to the idea of simplicity, where everyone shares the same system, database, and infrastructure with minimal configuration. Essentially shrink-wrapped software running in the cloud. Customers essentially had state-of-the-art technology at a lower cost, but they were back to their original problem: they owned a generic system that didn’t fit anyone and was also difficult to customize. Even worse, customers don’t even have a fully defined “best practice” system. They now have a “lowest common denominator” system with no way to differentiate themselves or handle their advanced business functions. Users of these systems quickly learned that the pain of not being able to even customize your system is the worst pain of all. Is there an architecture that is as cost-effective and technology-proof as a SaaS solution but still allows for customization? An architecture that allows companies the ability to protect their unique business processes without thousands of hours of effort? An architecture that doesn’t create a barrier to continuous improvement as companies grow and change? An architecture that is capable of adapting as technology evolves? Enter the Model-Driven Architecture – this is what makes the Jeeves ERP architecture so “genius.”

Model-Driven Architecture

Model-driven architectures are built on technical models that describe how software works and business models that describe what the software should do. Model-driven architectures produce flexible systems built for modification and change. The architecture allows new logic and data behaviors to be added at any time. Old logic and behaviors remain functional even when the underlying system logic is upgraded. Model-driven architectures start from the premise that you will tell the system what you want done and the system will do just that. Not someone else’s best practice—but your best practice. Not 10,000 options—just the options you want. And certainly not the lowest common denominator in the industry. What you want, the way you want it, fast and easy.

The Architectural Revolution

Unlike earlier ERP systems where every aspect of the product is hard-coded and difficult to adapt or change, the Jeeves ERP system architecture is model-based. A developer defines the way the product should look and feel and that model is used to control the operation of the system. Not only is the customer data unique to each customer implementation, but the look and feel of the product and the content of every page is unique as well. The Jeeves ERP system carries a Site Repository where all of the customer-specific implementation details are stored. When the core application is upgraded, these changes are retained, and the product continues to operate as specified in the Site Repository. Customers can easily create a truly unique ERP solution that preserves their ability to change and upgrade their system over time. The idea is simple: describe the desired system, rather than hard-code it, and keep this description separate from the core system.

Key Benefits

Let's explore some of the key benefits of Jeeves ERP's genius architecture.

Run-Time Flexibility

Some model-driven architectures implement the model by regenerating the code that implements the system. The Jeeves ERP architecture maintains its model as a critical element of the system. The model is used and executed at run time so that changes and enhancements and upgrades can all be done with a minimum amount of disruption to the run-time system.

Upgrade New Functionality Alongside Modifications

The Jeeves ERP architecture separates the model for the standard system from the model for the customizations, so that customers can keep their adaptations, while continuing to take advantage of newly released, standard functionality.

Zero Upgrade Force (ZUF)

In code-based systems, adaptations must be manually transferred from the old version to the new version and then adjusted based on new features or dependency changes. With Jeeves ERP, the core system is upgraded around the customizations. This means that customers can upgrade on their own terms and pace with significantly less effort. More than 80 percent of Jeeves customers upgrade to the next version within two years of its release—and that’s a decision they make. We stand by this unbeatable statistic in the ERP industry.

High-Efficiency Development

The Jeeves model-based development environment is very efficient and productive. Programming is kept to a minimum, allowing Jeeves to quickly release new functionality, and allowing customers, as well as partners, to rapidly release new functionality as well. Significant changes can often be made in a matter of minutes.

Available Anywhere

The Jeeves architecture easily supports ubiquitous connectivity, and by that, we mean more than just accessing the application in the cloud on a Web browser from a mobile device. Jeeves ERP has very effective client-server communication system that allows the application to be used in networks with narrow bandwidth, outside local networks, or by companies with a geographically dispersed organization.

Collaboration and New Feature Time-To-Market

The Jeeves Application Builder (JAB) allows customers to quickly and easily share functionality between installations, allowing them to import and export settings in applications, report templates, or new programs as an “app.” Apps can also be shared between different Jeeves environments via the JAB, allowing you to collaborate with Jeeves, our partners, or other customers to solve problems and further extend your system—or to automate the process of moving customizations from development to test to production. This provides for a much shorter outage window during deployments into production and eliminates human error.