I recently delivered a talk aptly named “Avoid Noodling Through an Architecture’s Foundations”, at Devoxx 2018, a developer community conference that this year had over 1,200 people attending. The conference covered subjects such as development, architecture, and DevOps practices, along with a multitude of other technology topics. Here’s the abstract I provided for that talk, so you know what that noodle was all about:

We all love pasta, right? Unless you're an architect: these people who design and envision systems from the ground up have developed an aversion to spaghetti throughout the years. When supporting the cutthroat business models of our era, it's fundamental to develop ways to evolve your architecture to match business concepts and processes properly, otherwise, you'll get yourself in a noodle—a spaghetti architecture.

By basing your architecture on strongly-defined tenets and well-established foundations, you can support rapid growth and massive scalability. This helps you avoid deployment nightmares, higher code maintenance costs, and an inability to keep up with the business.

After attending a few presentations and evaluating the audience we would be expecting, mainly by scanning and interacting with people visiting the OutSystems booth, I soon came to understand that the majority of attendees and talks orbited around the Java development planet.

Into the Weeds, Blinded by Toys

There was an almost tangible excitement revolving around complex tooling and manual processes, with lots of people mired in the weeds and the illusion of control of each and every byte of their code. It all seemed to emanate from the challenge of discovering and playing with new “toys.” I guess that just comes with the territory: that’s what being a geek is all about, right?

The army of geeks I found myself among—and that I belong to but probably in a different way—was proudly presenting its achievements: successfully gluing frameworks, going through long journeys to overcome challenge after challenge, implementing and deploying distributed services in state of the art cloud computing.

And that’s when it really struck me just how far ahead low-code platforms, and OutSystems in particular, are in terms of simplifying the life of an IT department.

Pistols at Noon: Simplicity Versus Complexity

Four talks were running in parallel at the time my presentation was scheduled. As mine was somewhat of an outlier, I found myself wondering if it would garner enough attendants, especially since it was clearly aimed at simplifying the lives of people who design and envision systems from the ground up. I wasn’t presenting nifty snippets of code, scripts, or high-code examples. No, I was bringing OutSystems to the playground and talking about the major advantages of using a low-code platform for the full software development lifecycle and with which you can instill a proper DevOps practice.

As I was about to start, I scanned the room and was relieved to see it full of genuinely interested people. They weren’t there to further entangle themselves in minute displays of technological prowess, they weren’t worried about the bits and bytes of code, and they weren’t just excited about new tools.

This audience seemed to be pursuing the promise of guidance. These people were looking for an architect’s guide through the galaxy of options and frameworks that were being presented everywhere in that conference. I reinforced this very notion by the set of interesting and relevant questions I got after I was done presenting. Most of them were truly worried about their implementation of microservices, for instance, or with the successful implementation of the underlying architecture.

I guess the somewhat abstract promise of shedding some light on how to evolve an architecture for continuous delivery and for the support of the cutthroat business models of our era—without getting into a noodle—had the desired effect, after all!

Pass the Lasagna

Now, with a low-code platform, the speed at which one develops is much faster. We actually had to stop telling people just how much faster, even though we had a paper to prove it, because it sounded like we made the number up. At the same time, the faster someone develops, the faster an architecture can become increasingly hard to maintain and deploy—what we call a spaghetti architecture.

“The object-oriented version of spaghetti code is, of course, ‘lasagna code.’ Too many layers.” — Roberto Waltman

We also didn’t want to venture into going from a noodle to a lasagna.

Therefore, I presented our systematic approach to map business concepts into software artifacts, based on our 4 Layer Canvas Architecture, which offers continuous delivery for different teams or lines of business. And, it lets you strike a balance based on the benefits of microservices vs. monolithic architecture.

When all was said and done, I left the conference with the sense of a mission accomplished. So much for my initial fears that I would not have the adequate content for such a conference! It turned out to be a great experience.

Here’s the video, courtesy of Devoxx, with my full presentation: