Abstract
The model-driven architecture of SAP Business ByDesign allows it to embrace e.g. new database and user-interface technologies – such as HANA and HTML5 – without disrupting the customer experience or re-writing the underlying application logic.
The journey begins
How often is it that you get to develop a new solution from scratch without having to worry about your installed customer base? Not very often in my experience.
In 2004, we got that opportunity with what we now know as Business ByDesign. Our brief was to come up with a new architecture for a mid-market ERP solution. Existing solutions for this market were just too complex and the cost of the infrastructure and implementation too high.
Imagine you’re starting with a blank sheet of paper, we were told.
Anticipating the trends
We started by getting a good understanding of how the technical capabilities would evolve over time. Thanks to our close cooperation with INTEL, we established the key trends: new browser-based user interfaces; a rapidly evolving number of CPU cores at lower clock speed; vast amounts of main memory, sufficient network bandwidth via the internat; and an ever growing need to seamlessly integrate systems via web services.
It was clear right from the beginning, that over the life cycle of what we call Business ByDesign today, the underlying technologies would evolve rapidly. The challenge was how to do this without having to re-programme applications or user interfaces at every evolution. Vishal Sikka, - SAP’s CTO at that time - used the term ‘timeless software’.
Deciding to go “model-driven”
For this reason, the lead architects decided for a ‘model driven’ architecture. In principle, they identified different layers and described the interfaces between them as depicted below.
![LayeredArchitecture.png]()
This meant that, instead of say, programming business objects such as a sales order or invoice, manually, we developed frameworks that would interpret and define business objects via metadata. This then automatically generates the required database structures, role-based access, state-action-behavior, CRUD (create, read, update, delete) services, as well as stubs for dedicated business logic.
The model-driven approach allowed us to work in parallel: one set of teams focused on defining business objects, process flows, user interfaces and analytical content – everything we wanted to describe via meta data. A second set of teams worked on the implementation of the frameworks. Once both pieces of the puzzle, the metadata and the frameworks, were ready, we added application-specific methods and events beyond the CRUD (create, read, update, delete) services and standard events.
Leveraging in-memory computing for performance gains
This kind of model-driven architecture comes at a price. It consumes an excessive number of CPU cycles and requires a lot of main memory.
By 2007, it was becoming clear to us that, despite the fast-pace of hardware evolution, the underlying relational database would become a bottleneck. The answer to our problem was to introduce SAP’s main-memory based search engine, TREX into the ByDesign architecture, in 2009.
Instead of using the relational database for queries, all read requests can be handled via the TREX search engine. We were able to make the required adaptations for in-memory search at the framework level, so that none of the business objects had to be re-implemented.
The impact on performance was significant. Today, all ByDesign customers see an average dialog step response time of 730 milliseconds in the SAP datacenter (for total end-to-end time you need to add network latency, number of round-trips and browser rendering time).
Simplifying the architecture – with HANA
TREX is far from the end of end of the story. By October 2013, SAP’s progress with its HANA columnar database gave us the opportunity to simplify ByDesign’s architecture even further.
Instead of using both a relational database in combination with the in-memory search engine TREX, we could now perform both activities on one engine - HANA. This time progress wasn’t performance but ease of administration and a simpler application of logic, because, if you can run all tasks in one engine, there is no longer a need to check the consistency of the database and search engine.
Since February 2014, all new customers were being provided ByDesign tenants on SAP’s HANA database.
The quick transition – the project started in October 2013 and finished in January of 2014 - was, again, only possible because the of modelled business objects and the use of standard SQL to access the underlying database layer.
And there’s more to come. In 2016, we will replace all remaining MaxDB/TREX systems with HANA. At this point, we’ll be able to start the next wave of evolution, leveraging native HANA capabilities, going for single-persistency across all frameworks and applying techniques like codde push, to further improve performance.
User Interface on HTML5 and FIORI
ByDesign’s user interface (UI) has benefitted from a similar approach due to its model-driven architecture.
When we started building ByDesign in 2004, we were working with static HTML4 pages. Compared to state of the art PC applications, the user experience was limited – no meaningful context menus, no drag–and–drop, for example. Nevertheless, we decided browser-based UI was the paradigm for us. Together with Adobe and Microsoft we discussed ways to get to rich internet applications.
Choice was limited. There was Adobe’s Flash/OpenAir or Microsoft’s Silverlight. HTML5 was being talked about but still immature and poorly supported by browsers at that time. But five years later, the next transition is on its way and both Flash and Silverlight have fallen by the wayside. The industry has decided HTML5 is the way to go.
Had we (hard) coded ByDesign’s UI, this would have meant a complete re-write. But because we took the same model-driven approach to the UI we a) separated UI logic from backend (business object) logic as shown below:
![UIModel.png]()
The ByDesign user interface comprises of patterns, which consist of controls. Therefore, moving from HTML4 to Silverlight meant to re-implement the controls. Today, we once again transition the controls from Silverlight to HTML5. Here, we leverage SAP’s investment in the and a lot of technology developed in the context of SAP’s UI concept FIORI.
What we set out to create in 2004 was a midmarket ERP that was built for change. Business ByDesign is just that. The model-driven architecture has helped us tremendously to leverage the advancements in technology at reasonable cost to us and without disrupting our customers’ experience.
