Show Cover Slide

Who I Am — Turning Flow into Structure

gpt-4-turbo has translated this article into English.

Why I Write

Hello.
This document is an attempt to reflect on the work I have done and to organize how I have worked.

This is not a document that presents a completed definition.
I am just beginning to put into words the times and decisions that were passed by without being organized.

Each individual’s energy is different even in the same job.
I plan to find my own way forward by organizing the ways of thinking and working that were natural to me.

Reflection on Myself

In many organizations, I have been remembered as a fast person.

Porting new technologies,
quickly connecting existing systems with external services,
and solving problems that others could not.

Thus, I was called a “fast developer” and “problem solver.”
While not incorrect, I have rarely worked with speed as my goal.

Being fast was just a result.
What made that result possible was not ‘speed,’ but an obsession with ‘structure’.

What I Do Well: Structure Created Speed

The reason I could deliver the desired results quickly in business was always because I thought of structure first.

• Where did this request start?
• What is essential, and what can be boldly discarded?
• Which choice can reduce the overall burden on the team?

These were the questions I asked first.
Then I built the minimal structure and piled execution on top of it.

Looking back,
I have found more charm in creating a foundation for judgment and execution that prevents problems from reoccurring than in solving problems directly.

This task kept me focused for a long time and eventually enabled fast results.

The Invisible Structure is Easily Forgotten

Especially in startups, roles are not clear.

Even if there is work on designing structures or reorganizing processes, the visible outcome is merely “the problem has been solved.”

What remains at best are artifacts like frameworks or code structures.

Over time,

“It was nothing special after all.”
was how it was often summarized.

The term ‘architect’ has gradually lost its importance in the changing flow of the ages.

The process of creating and trivializing problems was not highlighted, and its significance also faded quickly.

During that process, I failed to develop the language to express myself.

Although I have quietly created structures in the flow of time, I have increasingly lost the way to explain their importance.

The Dilemma of the Term ‘Architect’

I have described myself as someone who solves business problems through computing.
However, this description was too abstract and difficult to garner empathy.
For a while, I defined my role with the word ‘engineer’.

As time passed,
I wanted to reflect on the work I have done and find a more accurate language to describe it.

My attention naturally settled on the term ‘architect’.

But I didn’t want to use it merely as a label for a role.
I have come to think that the word ‘architect’ should encompass the depth of structural thinking and the responsibility of creating a basis for judgment.

Therefore, I would like to define an architect as follows.

• A person who creates a structure that can be judged
• Not just someone who chooses technology, but someone who creates conditions that make choosing technology possible.
• Not someone who decides what to do, but someone who helps the organization explain why it must be done.

That is the role of an architect as I see it.

Why Architects Are Needed

When an organization is small and immature, solving the problem itself is the priority.

However, as the organization grows, merely solving individual problems is no longer sufficient.

Problems reoccur, and the flow becomes increasingly complex.

At this time, what is needed is

• not more personnel,
• not more projects,
  but a structure that prevents problems from reoccurring.

I think of an architect as

not someone who solves problems,
but someone who designs a structure that prevents problems from reoccurring.

Creating a structure that allows people to judge for themselves and the organization to grow on its own.

That is why architects are needed.

An Engineer’s View on Software Architects

From an engineer’s perspective, the essence of a software architect involves structural thinking and setting reproducible standards.

A SW architect is not just someone who handles code or systems.
An architect is responsible for:

• Designing a structure that can control complexity
• Transforming requirements into structural problems
• Making decisions considering the lifecycle of the system
• Explaining the reasons and limitations of technical choices

From an engineer’s perspective, structure and standards must exist before the output.
Structure and standards make the output sustainable.

Therefore, a SW architect should focus on

“Can it be built quickly?”
“Can a structure be designed that won’t collapse even if built quickly?”

The Evolution of Architect’s Role Over Time

In the past, writing code itself took a lot of time.

Compilers and development tools were not as advanced as they are now, and the testing environment and deployment automation were not adequately equipped.

As a result, architects had to focus on:

• System modeling with UML,
• Algorithm design using Pseudocode,
• Detailed and sophisticated documentation.

Since code production was high-cost and high-risk, meticulously designing the structure beforehand was a core task.

However, the situation has changed significantly now.

• Advanced development tools and frameworks,
• The expansion of the open-source ecosystem,
• An automated deployment environment based on DevOps,
  All these have dramatically increased the speed of code writing and verification.

Now, architects need to focus more on

• designing a flexible structure that can withstand changes and expansions,
  rather than perfect pre-design.

In a rapidly changing technology environment,
designing a structure that is resilient to change is the modern architect’s challenge.

The Emergence of Design Shortage and Automation

In the rapidly changing development environment, it has been difficult to deploy sufficient structural design and architects in every project.

The supply of designs has not kept up with the increase in development speed and requirements.

As a result,

• instead of manually controlling complexity, operational and deployment automation (DevOps) has been enhanced,
• instead of developing features directly, consumption in the form of services (SaaS) has been strengthened.

DevOps was an attempt to

automate infrastructure and deployment complexity,
to compensate for the absence of design through operational automation.

SaaS was

a result that abstracted individual features,
and made quick integration possible.

These changes have created a development environment that produces results quickly through fast combinations and integrations, rather than delicately designing structures.

The current development culture demands
the ability to combine and adapt to changes
rather than sophisticated structural design.

New Roles Required of Architects

Architects should not simply follow the old ways.

In today’s environment,

• automation through DevOps,
• feature abstraction through SaaS,
  These trends should not just be followed but structurally understood and combined.

In other words, how to use automation and SaaS to design and propose an efficient and maintainable development structure suitable for the organization.

Architects should

• not be swept away by the flow,
• interpret the flow structurally,
• create realistic alternatives that fit the rhythm of the organization.

I believe designing a foundation that allows the organization to grow stably amidst changes is the new role given to architects today.

And I am committed to thinking and acting to achieve this goal.

The Structure I Want to Create

I want to create a structure that connects rapidly dispersing execution with direction and context.

So that the organization does not stay with one-time results, but

• execution creates flow,
• flow creates structure,
• and the structure supports the entire organization’s judgment and execution.

Specifically,

• strong against changes,
• expandable,
• and understandable and maintainable by people,
  a living structure is what I aim to create.

Not a structure for technology alone, but a structure that connects people and execution.

That is the direction I want to build towards.

In Conclusion — The Process of Creating Definitions

I do not yet have a completed definition.

The word architect cannot be explained in a form that everyone can empathize with.

However, it is clear that I am in the process of creating my own meaning of an architect.

• Repeating structural thinking,
• interpreting structures in the changing flow,
• and trying to find realistic alternatives suitable for the organization.

This document is the first attempt to record that process.

I will continue to ponder, confront, and revise to complete my own definition of an architect.