Work on our own product. Our approach

fdForge

fdForge is an internal system, which has been developed in Fresh Design for 5 years and which is the basis for all our web projects, as well as the basis for business process automation projects in the company. Platform Features:

• flexible customization without requiring a development team;
• high connection with client apps (personal accounts, mobile apps and other interfaces) that are developed for the project;
sets of interfaces for integration with current company information systems.

If this project is an internal one (i.e. all project decision makers are inside the company) and it is also integrated into all other client projects of our company, the fdForge project has some features in the development process that we would like to talk about.  

Product history

We worked on many web projects  for 12 years; different directions, but since 2012 we have been increasingly involved in projects related to flexible receipt, processing and distribution of applications for various services - mainly financial sector, as well as insurance, FMCG and web services. 

Working on each project, we focused on the common patterns, the functional modules that are available in each of them. So, during the development of the next project, we found a solution that makes sense to combine all the work we had done before into a single technical solution. Taking into account that one of the most important parts of our platform has always been working with personal data, the basis of the then unnamed product was the rights delimitation module. Further, for 5 years we have been complementing, developing and modifying the functionality of fdForge, creating a more and more flexible platform.  

Primary reasons for the creation of the platform are as follows:  

• Code unification to ensure support and survivability -previously, each project had its own team, its own development approaches. And even though the whole code was modified, it became expensive to support and develop the project without any of the key specialists. With the transition to a single system, we were able to quickly switch specialists between projects.
• Proposal optimization - by developing more and more flexible modules, we were able to reduce the time and budget for the implementation of functionality on projects. It is much easier to test one project with high quality than dozens of them;
• Additional value of projects - we are ready to offer our customers more by using many ready-made modules on the project, in addition to the directly implemented functionality, the customer immediately gets extensive opportunities to monitor and control the system;
• The possibility of further updating - by developing projects on fdForge, we can provide our customers with the implementation of new functionality as technology develops and new analytics, marketing and communication solutions appear in the market.

Task Setting Approach

Based on the specifics of the project, we have developed four main sources of task definition for ourselves, which will be included in the upcoming releases of fdForge: 

• Customer preferences - account and project managers analyze customer needs, identify common preferences for different projects and form them as tasks for fdForge team. In this way, we can respond to the wishes and requirements of our customers, providing a solution to their problems within the optimal time frame and budgets;
• Bug reports - in the case of problems identification in the system, the specialist forms a task on this report. Not only within the project where the problem was identified, but also in the root project fdForge (in order to check whether the question is global);
• Tasks from the technical team - the development team constantly generates system optimization tasks in terms of productivity, internal interfaces or code quality
• Tasks from Product Owner + business analysts - within this task flow, plans for further development of the system functionality are formed. Thus, we have implemented flexible functionality of work with directories, as well as the constructors of entities and links between them.

.

All company employees have access to the fdForge project backlog and can express their wishes. This is how we got so many successful solutions. 

This approach allows us to maintain high stability of the system, taking into account the wishes of our existing customers, as well as increase the value of the system for new customers. 

Forming releases

Every two weeks we have a meeting where technical experts and analysts discuss the composition of current and upcoming releases. During this meeting we discuss the priority of tasks, make the timing of implementation and update the composition of upcoming sprints, as well as determine the team responsible for one or another release.

Time of two weeks is optimal, because there are enough materials for discussion. There is no need to meet more often, but less often you can't, because you can miss some of the actual “fichas“

Development of releases

With each release, we have a set of rules that we adhere to both within fdForge and most other company projects:

1. Documentation preparation - any fitch that takes on the work first goes through the stage of development and coordination of documentation. After writing the terms of reference for the module's implementation, there is an internal discussion within the development team, so that analysts, developers, and the testing team understand which module to implement;
2. Prototyping - prototypes of new functionality are being developed and discussed before the task is handed over to the UI team - even minor interface changes can greatly affect the usability of the system for both new and existing users.

1. Code documentation - this item, like the previous one, does not only concern fdForge. There are many developers from different teams working on the project, so it is crucial that everyone understand what each code fragment does.
2. Compiling a manual for working with fdForge - along with the development of new functionality, work is underway to update the technical documentation for new features that will appear in the system. 
3. Test content preparation - experience has shown that it is much easier to explain some functionality both inside and outside the team by providing users with a demo with real content. That's why fdForge's basic build initially includes test content that is purged from the project when switching to the production environment.

Micro-release transition

Some of the solutions we came up with as part of our work on the project was the transition to micro-releases. Previously, work on a release could take up to 2-3 months, but with the development of the project, this approach has become impossible, the functionality required for projects should be delivered to the system in a shorter time.

• Customer preferences - account and project managers analyze customer needs, identify common preferences for different projects and form them as tasks for fdForge team. In this way, we can respond to the wishes and requirements of our customers, providing a solution to their problems within the optimal time frame and budgets;
• Bug reports - in the case of problems identification in the system, the specialist forms a task on this report. Not only within the project where the problem was identified, but also in the root project fdForge (in order to check whether the question is global);
• Tasks from the technical team - the development team constantly generates system optimization tasks in terms of productivity, internal interfaces or code quality
• Tasks from Product Owner + business analysts - within this task flow, plans for further development of the system functionality are formed. Thus, we have implemented flexible functionality of work with directories, as well as the constructors of entities and links between them.

The similar approach allowed us to shorten the period of testing and debugging of the system, as well as to reduce the complexity of updating projects based on fdForge, transitions became more predictable.

Publish and update projects

After the publication of the new release, we update our customers' existing projects with new functionality. Most projects are updated by us as part of our signed support contracts, but there are cases when a customer enters into an additional agreement with us to update the fdForge version. 

In most cases, the update takes 2-3 hours, with system downtime of 5-15 seconds. However, there are cases of major releases where the logic of the app changes with the fdForge update. Let us explain this point by the example of the FinMe project.

As part of release 1.18, fdForge has introduced flexible transaction configuration functionality, where a system administrator with a sufficient set of rights could customize the list of properties that a transaction would have, while different types of transactions could have their own set of properties. The FinMe system is a financial broker that receives, processes and sends requests for microloans from various partners. At the same time, due to the specifics of business, the set of properties in these requests may differ depending on the source of receiving requests.The FinMe team had a choice to develop their own solutions to optimize the set of fields in the request, or to translate the existing logic in the system to the functionality of deals in fdForge and get the flexibility to configure the API based on the system capabilities. The first option was evaluated at 190 hours, while the upgrade could be integrated within 40 hours. 

But more importantly, our FinMe colleagues got access to all the functionality that was associated with transactions and appeared in the system in subsequent releases - visualization using dashboards, building statistics, exporting transactions and forming user segments based on their transactions.

Total

Indeed, work on an internal project is very different from external development, but most of the principles and approaches that we apply to work on fdForge are also used in client development. 

Checking the experience of the projects we have launched, this approach has proved to be successful, allowing flexibility to change and develop the functionality of existing systems, while at the same time meeting the high requirements of our customers, allowing high-quality and timely launch of new projects.