sugaiketadao

Posted on Jan 25

I built a lightweight framework for Japan's "SI" projects (third attempt in 10 years)

#java #javascript #framework #systemsintegration

When your team includes beginners (and GitHub Copilot), "less magic" becomes a feature.

I built a lightweight Java framework for Japan's "SI" projects (third attempt in 10 years)

Introduction

Hello! I'm a programmer with over 20 years of experience in system development, mainly in Japan's SI industry.

As the title says, I've built a Java and JavaScript framework from scratch.
You might be wondering: "Another framework in 2026?" but let me share the background and some surprising discoveries.

What is "SI" in Japan?

In Japan, "SI" (System Integration) is a major sector of enterprise software development. SI companies (called "SIers") build and operate custom systems for clients—typically large corporations, government agencies, and financial institutions.

These projects have some unique characteristics compared to typical startup or product development:

Mixed experience levels: Teams often include programming beginners alongside experienced developers due to rapid staffing needs
Conservative tech choices: Constraints on adopting new OSS frameworks without established track records
Diverse project scales: From small batch-only systems to large enterprise platforms
Custom solutions preferred: Building from scratch is common for compliance, customization, or legacy integration reasons

This context is important for understanding why creating yet another framework in 2026 might actually make sense.

Why I Built Yet Another Framework

Consecutive Projects Building Frameworks from Scratch

Recently, I've had several SI projects in a row that required building frameworks from scratch.

In SI environments, there are various reasons for not using existing large-scale frameworks (like Spring Boot or Struts):

Constraints on adopting open source software
Small-scale projects or batch-only systems that don't justify large frameworks
Technology choices like Node.js where frameworks without in-house track record should be avoided

Also, as a characteristic of SI projects, programming beginners often join the team.

Frameworks Understandable for Beginners

SI projects often require a large number of people in a short period, so team members include:

People completely new to programming
People who studied Java but have no work experience
Experienced developers in other languages but new to Java

In such situations, using feature-rich frameworks like Spring Boot leads to frequent problems, mainly due to learning costs:

Not understanding what annotations mean
Not knowing what happens automatically
Unable to trace the cause when errors occur

So we end up creating simple and understandable frameworks or wrappers each time, but rebuilding from scratch for each project is inefficient.

"Let me organize my knowledge and create a generic framework for next time."
——This was the direct trigger this time. I also thought about organizing documentation so I could reuse it as my own knowledge base and source snippets in the future.

A Surprising Discovery: Beginner-Friendly = AI-Friendly

While working on a framework-building project, I suddenly realized:

"Design for beginners" is similar to "design for AI"?

Characteristics for Programming Beginners

Eliminate "magical mechanisms" like annotations as much as possible
Easy to trace code execution flow
Simple and clear rules

What AI (like GitHub Copilot) Needs

Consistent patterns that are easy to generate code from
Simple structure that reduces token consumption
Good visibility into the framework internals (provided as source code)

These were surprisingly aligned.

In other words, if you replace AI with an engineer with 2-3 years of experience, a beginner-friendly framework becomes an AI-friendly framework.

Third Attempt in 10 Years

This is actually my third time building a custom framework, and I wonder if many of you have similar experiences.
The first was a Struts wrapper, the second was a Wicket wrapper, and neither made it to public release, but this time I was determined to publish it properly on GitHub.

About the Name "SIcore"

I named the framework SIcore.
It embodies the meaning of a "simple framework" cultivated in SI environments.

Future Plans

I plan to organize and introduce SIcore's features and design philosophy.

Conclusion

You might be wondering: "Another framework in 2026?" but SI environments have their own unique circumstances and needs.

And I feel that the value of "simple and understandable code" is being re-evaluated with the arrival of the AI era. Building enterprise core systems with AI alone isn't easy, but I believe using such frameworks together makes it a more realistic approach.

If you're interested, please check out the GitHub repository.
It's still under development, so bug reports and feedback are very welcome!

Next time, I'll write about SIcore's specific features.

DEV Community