I’ve written several blog posts now covering the importance of design when it comes to building enterprise grade business applications. Over the last 18 months or so I’ve been fortunate enough to work on a number of SAP Fiori/SAP Cloud Platform based implementation projects so wanted to share some thoughts with the community. The last blog I wrote detailed Design Thinking concepts utilized in the 1940’s by the McDonald brothers – you can view this here.
Following on from this I wanted to write about the importance of design from a backend systems point of view. In my experience, I believe this often gets overlooked (or trivialized) in projects due to the snazziness of the front-end designs and the fact that the high-fidelity prototypes allow users to play with the data and navigational elements of the application required to be developed.
From a customer’s point of view, it’s as if the app already exists – therefore it should be pretty quick to build. Right? Ah – no! If anything, it hides the amount of work involved in developing the business logic (which is sometimes really complex) and business processes required to build the workable application with real backend data. In the projects I have been involved in I have always tried to delve into more detail – especially trying to understand, for example, when the user filters records using selection options what is happening in the backend system to limit and read back only those records the user is interested in. This usually starts conversations about which fields, tables, logic is required to meet these conditions etc. In my mind, there are a lot of questions at this point that need to be addressed and designed – not really from a UX point of view but more from a backend design point of view, including but not limited to:
What tables are involved in data retrieval?
What relationships are involved between the data sets?
What does the full data model look like?
What business logic is involved?
I would categorise the above sorts of questions as functional design elements. Again, these questions should be answered and documented prior to any development (coding) starting. This is especially important for Agile projects as sometimes along the way the detailed requirements and proposed solutions can be forgotten and this could lead to additional development work, recoding and confusion as to what is actually being built.
From a data model perspective, it is advantageous to document which tables are involved and relationships between them. This provides the end client with a more detailed view of what is being proposed from a backend functionality and data requirements point of view. Adding a data model with detailed tables also adds value. At the very least, the project team can start discussing (in more detail) some of the ins and outs of the application and what functionality is required in the backend. The data model will form the Entity sets included in the Odata service – similar to the following model provided by some of the SAP Applications. As it states in the screenshot – this is the starting point for building the Odata service, the SEGW transaction is not.
Figure: 1 SAP Entity Data Model example
Another suggestion is to compile a process flow chart for each application being built that incorporates bits of the UX design together with the backend logic required to meet the app requirements. Here are some snapshots of the type of flowcharts I am talking about. You can see in the below case that the SAP Fiori icons are shown together with the business logic (in plain English) as well as the main tables that the data will be retrieved from. This just provides a flavor for the logic being utilized in the app and provides some nice detail about the backend design. Developers can then take this and start building the backend Odata service, but not only that, it provides detailed design elements for the application in which most stakeholders should be able to understand and agree to. This can also form the basis for Agile stories that can be detailed and placed into Sprints. Awesome!
Figure: 2 Sample flowcharts detailing Backend Design elements
I’m not saying this will guarantee successful building of business applications but it does provide the sturdy backbone with which to design robust, scalable, enterprise grade applications - hopefully leading to less bugs, less detailed design discussions, and less rework overall!!!
So, in summary I would like to state that a suitable amount of time is required on projects to analyse, document and agree on backend design and it needs to be planned, thought about and incorporated into UX Design and Development projects. The message of Backend Design can be conveyed by the Simple Mind song title – “Don’t You Forget About Me”. Classic!
By Phil Cooley
Senior SAP Certified Consultant of 20+ years in the areas of SAP Sales & Distribution, SAP CRM, CO-PA and more recently SAP Fiori, S/4HANA, SAP Cloud Platform and SAP Hybris Cloud for Customer.