The Development of Foodware 365 as a Cloud Solution

Project Texel: A new way of working

A whole new team was brought together for Project Texel. We defined a new organizational structure in which the following roles were assigned: developers, consultants, a test coordinator, a UX designer, application & solution architects and a program manager.

The tasks and responsibilities that came along with these roles can best be explained while illustrating our ‘new way of working’ mindset.

Translating customer needs into Foodware 365

In our first year we’re creating a Minimal Viable Solution for food companies throughout the world, to accomplish that we’ve defined a new way of working. But before I dive into that deeper, we’ll first have a quick look at our history. Schouw Informatisering exists for over more than 20 years. In these years we’ve developed and implemented SI Foodware on top of Microsoft Dynamics NAV in many different companies in the food industry all over the world. We haven’t done this alone. Our local Microsoft partners helped us along in reaching this. These past experiences result in a thorough knowledge of the food industry. Today we’re facing the challenge to convert this knowledge into our new solution: Foodware 365 on Microsoft Dynamics 365 Business Central.

We’re not just simply copy-pasting our solutions into Foodware 365. Based on our experiences and avoiding known pitfalls, we’re actually translating customer needs into Foodware 365.

Rethink functions per app

First we’ve created a set of apps which fit the needs of our global food customers. We start off with rethinking which functions are needed per app. It’s all about answering the “What” question: What functions are needed to accomplish a full-fledged app? And because we are working with time boxes, we have to prioritize these functions. Therefore, we assign every separate function into one of the three following categories: Dissatisfiers, Satisfiers and Delighters. In the end, we want to realize a module with a healthy mix of functions out of all three categories. The roles involving the rethink phase are the functional experts, the solution architect and the application architect. The output of this phase is a functional decomposition.

During this phase we also involve our reference group. Members of the reference group are a few of our highly appreciated global Microsoft partners and a Dutch heavy end user of our current food solution. In a weekly conference call, we discuss the functional decomposition with them and get valuable feedback. The interaction with the reference group is to ensure that we make a Cloud solution with a global food fit and that we also get important feedback from an end users perspective.

Redesign the software solution

This functional decomposition is input for the next phase, the Redesign phase. In this phase the “How” question is answered. Roles involved, in addition to the application architect, the functional expert and the solution architect, we also have the lead developer, the UX designer, the test coordinator and the consultants. The functional decomposition is discussed, and after that we decided how the app will be developed, inside Business Central with AL code or outside Business Central applying the capabilities of Azure and the Dynamics 365 platform. We’re also deciding if API’s are needed to extend the Foodware 365 function to third software solutions.

Another challenge in this phase is the fact that we’re creating a Cloud solution which will be vended via the AppSource of Microsoft, so we don’t know which Foodware 365 apps a customer is using. That’s why the apps have to work independent of each other. They can’t be developed in a monolithic way anymore, but at the same time we want to accomplish that the total package of all Foodware 365 apps is more than just the sum of these independent apps. The output of the redesign phase are use cases and test scripts.

Development, Testing & Documenting

That output is used in the next phase: development, testing and documenting the functions of the app. During this phase the whole team is involved. A big change for the development of our apps is that it can’t be done via embedded code. It has to be done via extensions. This development possibility is already quite some time around, but because it’s a Cloud Solution it is essential to extend the base code of Business Central.

And by development we don’t only mean development of the code for the desired functionality, but also development of the automated test script. These automated test scripts guarantee the quality of our solutions. And because it’s a Cloud solution it’s indispensable to have automated test scripts, otherwise you can’t keep up the pace of periodic Microsoft upgrades.

During frequent periodic validation sessions the developer shows his/ her progression and the next steps are discussed and finally agreed upon.

Intuitive and easy accessible Cloud solution

During this phase we also spend time to make our apps Saasified, with which we mean that our Cloud solutions are intuitive and easy accessible for our end users. We’re doing this by applying tooltips, quick entry, notifications, headlines, assisted setup, ready to use cues, charts and Power BI reports.

And last but not least we provide a thorough documentation, so that for every app a clear documentation is realized.

That’s it, hope you enjoyed reading my blog!