Project Texel: The development of Foodware365 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 by way of project Texel
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 in project Texel 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 offered 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 independently 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 is to 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 the 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 easily 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 easily 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. Last but not least we provide thorough documentation, so that for every app clear documentation is realized.
Learn more on Foodware 365 and how this solution can transform your business. We are excited to hear more about Foodware 365 integration with Dynamics 365 Business Central. You can contact us to find out more about how this solution fits your business needs.
Resource Credit | Foodware 365