Imagine you are building a massive, complex skyscraper. In the world of software, this skyscraper is a digital system (like a banking app or a social media platform).
Now, imagine that before you lay a single brick, you have to follow a thick, confusing, and constantly changing rulebook written by the government. These rules are about privacy, security, and fairness. If you get even one detail wrong, the whole building could be condemned, and you could face heavy fines.
This is the challenge Oleksandr Kosenkov is tackling in his paper. He is trying to figure out how to build software that is "compliant by design"—meaning it follows the law from the very first sketch, rather than trying to patch it up later.
Here is the story of his research, explained simply:
1. The Problem: Two Different Languages
Currently, building compliant software is a mess. It's like trying to build a house where the Architect speaks "Engineering" and the City Planner speaks "Law." They rarely talk to each other directly.
- The Architects (Software Engineers): They are used to moving fast, changing plans on the fly (Agile), and building things that work. They often treat legal rules as an afterthought, trying to fit them in at the end.
- The City Planners (Legal Experts): They speak in abstract, complex terms. They don't know how software works. They often sit in a separate office, writing rules that the engineers find impossible to understand.
The Result: The engineers build a great building, but it violates the city code. The legal team says, "You didn't follow the rules!" The engineers say, "We didn't know how to translate your rules into bricks!"
2. The Five Big Hurdles
Kosenkov identified five specific reasons why this is so hard:
- The Moving Target: Laws change, and software changes. Keeping them perfectly in sync is like trying to dance with someone who keeps changing the music.
- The "Afterthought" Trap: Companies usually think about the law only after they've already started designing the software. It's like realizing you need a fire escape after the building is already finished.
- The Ripple Effect: Changing a rule often breaks other parts of the software. Fixing one thing creates a new problem elsewhere.
- Two Worlds: Laws talk about "problems" (what shouldn't happen) and "solutions" (what must be built). Engineers and lawyers often look at these from different angles, causing confusion.
- The Translation Gap: It's very hard to translate "Legal Speak" into "Code Speak" without losing meaning.
3. The Solution: The "Universal Blueprint" (AM4RRE)
Instead of forcing everyone to follow a rigid checklist of steps (like "Step 1: Talk to lawyer, Step 2: Write code"), Kosenkov proposes a Blueprint-Based Approach.
Think of it like a Lego set with a master instruction manual.
- The Old Way: "First, build a wall. Then, paint it." (This fails if the wall needs to be a window).
- The New Way (AM4RRE): "Here is the blueprint. It shows exactly what pieces (artifacts) the Lawyer needs to define, what pieces the Architect needs to build, and how those pieces must snap together."
This model, called AM4RRE, creates a shared language. It doesn't tell you how to do your job; it tells you what information you need to produce so that the other person can do theirs.
4. How It Works: The "Tailoring" Process
You can't use the same blueprint for a house, a hospital, and a space station. You have to tailor the blueprint. Kosenkov suggests three ways to customize this model:
- T1: The Regulation Filter (The "What"): You take the specific law (e.g., GDPR) and highlight the specific rules that matter for this project. It's like circling the specific paragraphs in the rulebook that apply to your building.
- T2: The Connection Glue (The "How"): You draw lines connecting the legal circles to the engineering circles. For example, if the law says "We must know the user's age," the blueprint shows exactly where that "age" data goes in the software database. This prevents the engineers from accidentally creating two different "age" fields that don't match.
- T3: The Goal Selector (The "Why"): You pick the most important goals for your company (e.g., "Avoid fines" vs. "Build fast") and focus the blueprint on those.
5. The Future: Testing the Blueprint
Kosenkov is now at the final stage of his PhD. He has built this "Universal Blueprint," but he needs to test it in the real world.
He is planning to run an experiment where he puts a team of real lawyers and engineers in a room. He will give them a fake project and ask them to use his blueprint to design a compliant system.
- The Goal: To see if this "shared language" actually helps them build a better, legally safe product faster than they could before.
- The Challenge: Getting busy professionals to participate is hard because legal topics are sensitive. So, he is testing different ways to run the experiment, like using checklists or templates to make it easier for them.
The Bottom Line
This paper is about bridging the gap. Kosenkov is building a translator and a shared map that allows lawyers and software engineers to finally speak the same language. Instead of fighting over rules at the end of the project, they can use this model to build the rules into the software from day one, ensuring the final product is safe, legal, and built to last.