DEV Community: Nicolas de Mauroy

My late and enthusiastic discovery of HTML5

Nicolas de Mauroy — Thu, 15 Dec 2022 06:21:22 +0000

I was 23 years old in 2000, and I missed the web revolution. Back then, I loved to write performant C code, nurturing my pointers with love. So I could only be dismissive the poor performance and inelegant design of Internet technologies, most of all Javascript (come on, can a serious language not be compiled ?). I do not like to think about opportunities I missed because of this.

So in 2010, when I started thinking about designing software on my own, which later turned in the Open Lowcode project, I naturally went for a native client, using java JavaFX technology. I could actually develop what I wanted, but I had two problems.

First, when I tried to promote my software, nobody was interested by a design using untrendy technology, even if it had some advantages, like stability and performance.

Also, developing the interface I wanted in JavaFX turned out to be more complex than I thought. I think you can spend a lifetime in the Table widget not getting exactly the result you expect. With the technology now in maintenance mode, there are limited hopes it will get improved.

So we are now in 2022, and I would like to have a go at developing another 'serious' software in parallel to my video game project. I have decided to use the most widespread trending technology this time.

So I humbly went to W3C Schools, and started to learn HTML5 last week-end. I am a few days into it, and long-story short, I completely love it. I can build good looking feature rich screens really easily. Modern browsers have super powerful debugging features. The DOM API in javascript allows to define really rich interactions. I think I can easily build spreadsheet-like features , the holy grail of any enterprise software, from mostly native HTML5 with a few snippets of javascripts here and there.

Now, I need to figure out the server technology, both for the web server and the storage. I need something easily deployable on big cloud providers, trendy, and having good performance. Any recommendation ?

Open Lowcode version 1 Released

Nicolas de Mauroy — Thu, 02 Apr 2020 05:11:26 +0000

I am glad to announce that after a few years of effort, Open Lowcode version 1 is released. Open Lowcode is a solution for enterprises and organisations to create good specific apps quickly and cheaply, and run it for years with rock-bottom costs.

Open Low-code magic sauce boils down to:

Full open-source so customers will never experience vendor lock-in
vertical integration providing performance, simplicity and almost no obsolescence
All freedom to code the complex last 10%
Ergonomics for real work, as close as possible from Office suites

if you want to know more about the reasonning behind this initiative, please have a look at the Tech Blog

I am actively looking for contributors, and highly welcome developers of all skills, especially if you come from an enterprise background. If you are stuck a few days at home in the last weeks, why not come and hack a little bit in a friendly environment ?

Empower your teams with specific software

Nicolas de Mauroy — Tue, 03 Dec 2019 21:53:04 +0000

Large companies now understand that employee engagement is a key to success. I have seen countless examples of people increasing their productivity significantly when motivated to reach a goal, and feeling part of a team. We are not discussing here marginal improvement, sometimes, the productivity can vary by a factor of 2 or 3. This certainly comes from working harder. However a different, proactive, attitude has an even greater influence on the final work.

Engagement is not just an HR topic

HR departments go at great length to try and improve employee engagement. However, it can only go so far. Indeed, most of the employees experience come from their work tasks, not by the environment setup by HR. When making decisions on the work organization and processes, managers rarely take into account the impact on employees. Many trendy business decisions of the last decade have made work harder and less engaging: outsourcing and externalization, more and more formalized processes that leave no room for people judgment, matrix organizations that diffuse responsibility, to quote just a few. Not surprisingly, on the same period, employee engagement has lowered.

Digital is important

One such area is the choice of business software. The automation of business processes promises significant improvements. Building this software can be a collective effort, with all people involved providing suggestions, and the best ones are implemented in the software. Ideally, you even have software flexible enough that you can try ideas, and rollback them after a few years if they end-up not working.

If teams can have freedom to implement their own digital tools, benefits are two-folds. You are likely to implement the best process possible for your situation, as teams on the field usually know their daily job best. Also, teams will get motivated by this collective effort. The pride that an operational worker will get from having his suggestion implemented is worth ten thousands HR seminars on engagement.

Frustrations of packaged software

Compared to this solution, the implementation of a packaged COTS solution generates many frustrations. The organization needs to change its processes, not for a business reason, but just to fit with the IT tool. Granted, this tool can provide best practices and powerful features, but, generally, the bottom line is negative. This is easily explained as the ideal process depends on the context, history, and also on an organization culture and size, factors that are almost never taken into account by the one-size fits all packaged software.

The bottom line is even more negative taking into account the trauma of transition, and the unnecessary disturbances that will come every 3 to 5 years, when the software editor forces an upgrade.

The opportunity of low-code

This is where low-code solutions can help. They provide a robust framework. It means your local team can develop scalable software without being high-skilled IT architects. And it also ensures your tool will still work in the years to come. Scalability and long-term resilience used to be the main concerns of the local developments, so you should be safe now.

Lowcode tools of course provide all the freedom to actually implement what you need. With Open Lowcode, you define first your data, and build your application around it. 90% of the application is generated automatically, ensuring development costs are limited. And you have full freedom to develop what you actually need for the last 10% of requirements. The tool is fully open-source, ensuring you will have rock-bottom costs when you application has stabilized.

Software Package versus Specific Development

Nicolas de Mauroy — Sat, 27 Jul 2019 04:58:36 +0000

A company requires many IT systems to run its business, and typically spends a few percent of its revenue on building and operating those IT systems. A typical IT system will live for a decade and sometimes much more before being replaced. There are two strategies to deploy an IT system: software package or specific development. The choice will deeply shape the company for the life time of the system.

Software Package

Software package provides directly a solution for a business process. For instance , an accounting software will provide you directly a solution to register your transactions, create invoices and file tax return. Additionally, software packages allow you, to some extent, to adapt them to your needs, but there is always going to be a limit. Very few packaged software vendors have developed quality plug-in frameworks to allow for extension, something other industries do better: wordpress or many video-games come to mind here.

Specific Development

On the other hand, in a specific development, you develop yourself the requested business logic. This is done on top of a generic IT infrastructure that does not know anything about your business process. One such infrastructure is a database that stored safely your data. Fortunately, there are great, stable, and open-source infrastructures for most of the basic technologies you need. In specific development, you implement directly, according to your own rules, the business logic, which is great if you have special needs or constraints.

However, you also have to implement some infrastructure common to all business systems, such as security and access control, workflows, and application page layout. And this is where low-code platforms, such as Open Lowcode can help here, by providing those common bricks ready to assemble, and all flexibility to develop what you need on top (the mortar).

So, you have to create a new business system, or replace an old one, and you should choose which way to go, packaged software or specific. This post suggests a method to get to a decision.

Size and cost of the topic

The first criteria to look at is the cost of developing the system. This should be seen in the context of your company IT budget, a typical few percents of your company revenue (for example, it may be 100M€ for a company with several B€ of revenue), and generally a standard ratio per industry. Systems are:

Huge if they represent several years of IT budget.
Big if their development and deployment cost represent around 1 year of IT budget
Small if their development and deployment cost represent far less that1 year of IT budget

There is a natural limit to how much you can invest in new systems. You will typically be able to undertake one big project every 3 to 5 years, and several small ones per year.

Business Impact

IT systems fall in several categories depending on their business impact, and how standard the requirements are:

A strategic system is crucial to the competitive position of your company, and this is an area where you expect to be able to innovate. If your company focus is logistics, and you pretend to be the best in the world, you probably want to have your own supply chain software with all your proprietary innovations implemented quickly.
A normalized system is implementing an enforced standard process. The quintessential standard process is accounting, where there are laws and norms the company absolutely has to follow. Legal standards are not the only one, and there are also industry or scientific standards that are really applied: steel alloys are really standardized across the industry, and their mechanical properties also are. Here, caution should be applied that there are some ISO norms that are more a marketing trick or a hobby than a really applied industry standard, it is always better to ask a few disconnected experts before making a judgment call.
Many systems do not fall into this category, and are neither strategic nor normalized. However, having good systems can be critical for the productivity of the company. Such systems include word processors and office suite, many industrial systems, HR systems...

Insights

So, based on those two criteria, it is possible to propose a strategy, considering the following facts:

Some commercial software is very expensive while providing little value. While, in a perfect market, you would expect relatively simple software price to decrease, and also old technology to commoditize, enterprise software vendors are making a great effort at keeping price high in a market that includes mostly ad-hoc private transactions. So you should systematically challenge or reflect on the value a solution will provide and its cost. Just having the good title is not enough.
Using commercial software, you are at the mercy of the editor roadmap, and this includes, every few years, having to perform a potentially painful and costly upgrade. Specific software also suffers from obsolescence of the basic technologies used, but this is typically a fraction of the cost of an upgrade of packaged commercial software. To quote one, changing database version is no big deal.
Extending commercial software to fit to your requirements is almost always going to be extremely painful, as most commercial software does not have stable, powerful and properly documented APIs and customization points. First development is painful, but typically, the pain is felt mostly during an upgrade. Specific development of the same features is relatively easier.
You are likely under-estimating the cost of developing new software, or adapting existing software. Especially, there is a lot of work to stabilize a piece of software once it has been written, often an extra 30 to 100% of the original estimates. So keeping a working system, or using a widely spread packaged software as it is intended to be used, the stabilization work is already done
There are some topics that are just too big for your company to do on its own, and the smaller the company, the more there are such topics. This means that, in that case, you just have to make a smart purchasing decision, and go with whatever software exists. This may shape the strategy of your company, and prevent you from innovating in some areas. It is very important, and very rare, that all stakeholders recognize this, and adapt their strategy.

Finally, the decision matrix

So taking all this into account, decisions become quite obvious.

You should clearly buy software packages for any big or huge normalized topics. Examples of huge topics include a full accounting and tax suite, probably including payroll.
You should also procure software packages for any huge topic that is neither strategic nor normalized, as you cannot afford to build your own. One example is a word processor or spreadsheet. As those are huge investments you cannot afford, you should just use an existing product and live with its limitations.
If you have a need for a huge topic that is also really strategic, you have a problem. Your company considers it worth having a huge investment on this precise topic well beyond the normal IT budget. As an alternative, you create a real partnership with a software vendor to incorporate your requirements. As you will become highly dependent from the supplier, you probably want to limit the partnership to the minimum scope required
If you have a need for a big or small strategic topic, then, you should definitely go the specific way. This will give you exactly what you want, and you will get more flexibility. Open Lowcode is a very efficient way to do that
For simple normalized topics, and other topics simple or big, both packaged strategies or specific development may make sense. This includes a big part of the famous ERP system. Companies typically customize their ERP to take into account their specifics. However, many companies do not consider supply chain as a differenciating factor, just something not to fail at. One approach I could advocate is to get your local development team build a specific prototype. You could invest 10% of the original development budget and see how far they go. Thus, you will get a good understanding of the complexity of the problem, and how skilled your local team is, a big factor in deciding if going the specific direction is a good decision. With Open Lowcode, you need less technical skills as the framework already provides a very good base, and will guide your developers.

This is not exactly a fair game

While your team develops specific solutions, external vendors sell software package. You will not compare the two approaches in fair conditions. Especially, the specific development solution will lack the powerful, professional, and self-interested advocates from the vendor companies. Whatever happens, they will be happy to get your money. And nobody may ever know that is would have been 3 times cheaper to go to another route. This is even before mentionning the famous "Nobody has ever been fired to choose a big famous vendor" that will be common in your teams. So, to compensate this bias, you probably want to nudge slightly the decision into the specific development direction, and be the devil’s advocate when the packaged software case will be made. At least, you should run a few hackathons and see what comes out of it.

Is the web browser optimal for enterprise ?

Nicolas de Mauroy — Thu, 11 Jul 2019 02:43:17 +0000

Over 20 years building, maintaining and managing enterprise applications, I came to have strong opinions on many topics. To take one, I definitely favor strongly-typed languages, as they will ease maintenance, and allow typial developers to ramp-up faster. Using standard technology with an open-source solutions is also a no-brainer for the enterprise context. You want the application to still run in 10 years, when the current fad will be over, and not pay forever licenses.

So when I started to build Open Lowcode, an open-source low-code platform, many choices were obvious. The application would be written in java, and use SQL for persistence. It would use parsimoniously open-source libraries, most of them from Apache. You may find those choices bland, but bland is exactly what is needed here for the rough life of enterprise applications.

Now, I had to make a decision on the client to use, and this one was the most difficult to take. To be sure, I wanted a thin client: enterprise applications are maintained very frequently, let's say a patch 2 times a month. I do not want to reinstall the client every time. The question was then: should I use the web client, or develop an alternative thin client ?

Web client seems an obvious choice at first, huge amounts have been invested by internet giants on various frameworks and technologies. Nonetheless, I ended up taking a different route for a variety of reasons.

I chose to develop a specific thin client (enterprise app) using javafx. The client displays pages that are made of high-level primitives exactly suited for enterprise purpose. This includes the famous spreadsheet-like interface to manipulate data in table, which is the 'killer widget' of enterprise software. As far as I know, and my research may be incomplete, such widgets are not really available, or very costly to make with web technologies.

Other benefits include possibility to limit data sent between client and server to a minimum, or to implement ad-hoc security tools when working in a military context. And I expect javafx to be stable in the next decades. One potential drawback is the installation of the software on the client computer, but this is adressed by making the client simple to install, and having an automatic updater.

Still, this choice is the one I am still hesitating the most about, and I would like to hear your opinion.