Announcing Business4s: a new value proposition for Scala

We have an incredible language and rich ecosystem. Now it’s time to build on top of that.

“We Need Our Own Django”

The above sentiment has shown up in various discussions across the years, and it quite well expresses the more general thought: we need more high-level solutions that provide direct value to the businesses using Scala, not only transitively through the Scala developers themselves.

While the tools we currently have, like cats-effects, ZIO, fs2, akka or scala-cli, provide great value to building the systems, they are not something that can be easily mentioned in discussions with non-technical stakeholders. No business person ever said: “Build for me a typesafe, functional, reactive distributed system that is easy to build and deploy”.

This doesn’t mean we don’t have any high-level projects. The greatest example is Apache Spark, which solved a high-level problem of data processing in a novel way and became one of the strongest gateway drugs to Scala (even though the situation later became complicated). Besom, while technical, can be seen as a direct solution to the problems of infrastructure domain. Indigo opens doors for Scala developers to the completely new domain of game development. And there are many others, like Play, Tyrian, Laminar, Gatling, Tapir, Caliban or Chisel, that fit the umbrella to a varying extent. But is that enough?

According to the 2023 Scala Survey, 87% of Scala developers work on Web / API/ RPC projects, and that can be somewhat generalised to “backend development”. Could we have more high-level projects to boost that sector even further? Can we have a new Spark? Or even better, a new ecosystem of smaller, more composable “sparkies”?

Why Building High-Level Solutions Is Hard

There is a reason (quite a few actually) for why the most popular and widely used projects are low level in nature. Let’s see what often stays in the way of building popular, high-level, business-relevant solutions.

• The more specialised, the less applicable. This is the most obvious constraint. Low-level projects (like cats) can be used in almost any business domain. The higher we go, the smaller the problem space to which a solution can be applied. While this is true in general, Spark proves you can build a highly specialised product that is also widely popular.
• Generic problems are hard to spot. Business-relevant problems (and hence solutions) manifest, surprise surprise, in business contexts. This means that they are hard to spot in side projects and solitary tinkering. What’s worse, to identify a generic problem (applicable to different domains and companies), one needs to have experience from multiple companies that struggled with the same problem.
• Important problems get solved in-house. If the problem is important enough, it gets solved internally, and this removes further motivation to share the solution with the world. Once the problem is solved already and “well enough”, why re-solve it again in the OSS world?
• People with know-how are busy. Those people who solved those problems internally and are generally enjoying working on business-relevant problems rarely have time and energy to also engage in OSS communities.
• The problems are “boring”. Because the problems are business-relevant, they feel like work. People typically engage in OSS to experience something that is NOT work.
• It’s hard to split the solutions. Big problems typically need big solutions, and this means that 1) they require a lot of effort to build, 2) they are costly to adopt. Smaller, more composable projects (libraries instead of frameworks) mitigate that problem. A good example of this is Shardcake that solves only some of the problems that Akka solves, and hence is much more lightweight. But identifying those smaller parts is not easy in general.
• They have to be opinionated. On a low level, it's easier to find the right way to do things. For example, there are only so many ways to encode effects. And even if different approaches are possible (Scalaz vs cats vs zio vs kyo vs ox), in the end the differences are tactical. But the higher we go, the more ways there are to solve a particular problem. This means that the solutions need to make a bet that their way is the right one. In 2017, there were at least nine different projects trying to solve the problem of data processing! (Don't judge, the link is to one of my first public presentations!). And the more opinions we have, the bigger the chance people will disagree.

If there are so many obstacles, is it still worth trying to overcome them? We say yes.

What is Business4s?

It’s a new community focused on business value. On solving high-level problems in a business-centric way.

It’s a place for Scala developers focused on product engineering.

It’s a way to instill a domain-oriented mindset into the Scala community.

It’s an attempt to reshape the perception of Scala.

It’s home for projects that are directly relevant to non-technical people in a big enough number of companies.

What Business4s is not?

• It’s NOT a solution to a particular problem or challenge.
• It’s NOT focused on low-level issues such as parsing, concurrency, error handling, data transformation, jsons, http servers and similar problems considered as “technical”.

Ok, but what does it mean in practice? What is there today? We come with a bunch of things to kickstart the new community and ecosystem.

• Business4s Discord — a place to discuss and build community.
• Github organisation and the first two library prototypes: Workflows4s and Decisions4s, that we will discuss in a second.
• Domain-Oriented Scala Style Guide — a new style guide emphasizing focus on the business domain.

Let’s unpack all of that.

Why do we need a new ecosystem?

Let me explain what I think we can achieve through this effort.

• Give a new focus to the Scala community — People in different subcommunities focus on different things and follow different values. Typelevel focuses on safety; ZIO focuses on batteries-included, simplified FP; Akka/Pekko focuses on reactive programming; Li-hayoi focuses on barrier-to-entry and simplicity. Business4s will focus on building solutions that are pragmatic and directly relevant to the businesses.
• Build a community — Because of the issues with building high-level solutions, a collaboration of people is needed. Different companies will have different needs, and only by working together we can find the problems that are most common and find ways to solve them in a way that justifies the effort.
• Build an ecosystem — For any solution to be adapted by the business, it’s critical to offer long-term maintenance. Even if development stagnates, we should at least ensure the continuous dependencies updates and best-effort support. This is possible only by lowering the overall bus-factor of the libraries and sharing the maintenance efforts. Another reason is the interoperability between the libraries, although this is less important in the context of Business4s. Lowering the bus factor is our primary concern.
• Affect language perception — By forging a named initiative around real world, specific, non-abstract problems, we get a chance to position Scala as a language that is particularly friendly to the businesses. For now, Scala is often seen as a safe and powerful language. Let’s try to make it seen as a safe, powerful and business-friendly one.
• Create a space for business professionals — For every developer engaged in the community, be it through OSS, conferences or any other activity, there are probably 10 or more developers who just do their job and try to provide as much value as possible to their companies. We want to create a space for those people where they and their problems will be understood and prioritized over current community issues and regardless of political beliefs or technological stack.

What Are We Building?

As of now, the Business4s organisation contains two libraries: Workflows4s and Decisions4s. Both of them are in the proof-of-concept stage, and it's important to understand that they are not the main point of this article. They will get dedicated announcements when they’re ready. Having said that, they are here to showcase what the new community can do and focus on. So let me elaborate on what is there today.

• Workflows4s is a scala-native approach to the problem of long-running processes. It’s a simpler alternative to tools such as Temporal, Camunda, AWS Step Functions and similar. It combines the Temporal’s execution model with BPMN process visualisation and Scala’s embrace of functional programming through 1) IO monads used for side effects and 2) expressing computations as values. Its value for the business lies in the visualization layer, that gives a medium for common understanding between non-technical people and developers.
• Decisions4s is a very simple decision engine that allows building DMN-like decision tables and rendering them as actual DMN diagrams. This allows exposing the critical pieces of business logic to the non-technical people in a readable way while keeping everything defined through simple Scala code.
• Domain-Oriented Scala Style Guide is an attempt to gather lessons learned in building end-user products in Scala and expose them as a resource that can be used across companies to streamline the development. Building applications is vastly different from building libraries, and this style guide is targeted directly at the former.

What else could we do?

Here are some ideas of libraries that would fit our current definition of business-oriented solutions. They are just ideas, and that’s exactly the goal of the new community: to validate which of them are worth building!

• Chat Ops — Getting information into and out of chat platforms (Slack/MS Teams)
• DB Audits — Collecting information about data changes for audit purposes.
• Notifications — Sending and templating SMS’s, IM messages, emails, and push notifications.
• Backoffice UIs — Scala.js high-level UI framework focusing on building user interfaces that don’t have to be deeply customised and that can be built by backend developers with little to no experience in frontend development.
• SSO library — Streamlining Single Sign On, which is a critical element of security for enterprises.
• Feature flagging — Ability to dynamically control feature toggles or config in general

Even in the presence of examples, it might still be vague what business4s might be interested in. A heuristic that can be used is: is it likely that a non-technical stakeholder asks to solve this particular problem? If so, then business4s might be a right place to collaborate on the solution.

Can we do better than Java?

Enterprise world already has its favourite horse, and that’s Java. Can we beat the years-long head start they had? Yes, by leveraging the unique strengths of Scala!

• Safety — Scala has a strong culture of writing correct code achieved through a mix of functional programming and a powerful type system. Many businesses understand the costs of bugs and mistakes and are willing to use a more niche language if they come with added value.
• Expressiveness — Thanks to Scala’s innovative nature, we can do things that are impossible in other languages. Workflows4s and Decisions4s are good examples of that as their ability to render business-relevant diagrams is possible only thanks to Scala’s friendliness toward DSLs.
• Scalability — “Scala” comes from “scalable language” and I believe we also achieved that scalability in the ecosystem. While Java can scale up, we have something more. We can scale down! Scala’s unique strength is in building simple, minimalistic, composable solutions that can be used in a system of any size. Both workflows4s and decisions4s could be used from a single-file script if needed.
• Smart developers — Scala has a strong selection bias among its developers, people either handle the language and love it or they leave for greener pastures. But the ones who stay can be seen as above the market average. We just need to make them focus more on the business problems!

What’s next?

Let’s start building! Here are the things that you can do to help build this initiative:

• Join Discord! Discuss, brainstorm, contribute ideas, problems, and solutions. Collaboration is the key element of what we are doing here.
• Try the libraries!— both of the discussed libraries heavily need more usage attempts. Try to model your use cases with them and contribute those attempts to the examples subproject in both repositories. That’s the easiest way to try the libraries and give us concrete input for further development!
• Become the community leader! — We desperately need more people to lead this effort. Reach out to me if you would like to contribute regularly in scope broader than code itself.
• Wait for the libraries! — Neither Workflows4s nor Decisions4s have a usable release at this point. Decisions4s should get one in coming months, and Workflows4s might get one by the end of the year. Monitor Scala Reddit for the announcements or follow @Business4scala on X!

Why now? Why announce something that is not ready?
Validating ideas early is at the core of modern product and business development. There is no point in keeping this initiative hidden without validating it with the community! With the feedback we might invalidate some ideas, evolve others or pivot toward something else entirely.

The future of Scala is bright, let’s shape it together.