Notes of SoftwareArchitect.ID

Combining Modular Monolith and Hexagonal Architecture while Maintaining Domain Driven Design Principles (part 1)

Iman Tumorang — Thu, 13 Nov 2025 17:25:31 GMT

Today’s story originates from a recent client case at SoftwareArchitect.ID. It began when a team lead from the client company contacted me via email (iman[at]softwarearchitect.id — feel free to email me for technical advice, especially on software architecture, transitioning from monolith to microservices, or migrating to cloud from on-premises). The discussion continued through a few discovery calls, leading us to an agreement in which I will offer consulting services to help them plan for scalability and the shift from a monolith to microservices.

Although the monolith performed well for many years, moving to microservices became necessary due to the current process and scalability challenges they encountered, such as:

The desire for an isolated fault or loose coupling between domains.
Most importantly, per their customer request, they need to scale certain parts of their systems differently: some features require more resources due to high throughput, while others, like back-office services, handle low traffic.

However, the transition to microservices was carried out quite aggressively. As a result, costs have risen roughly 8 to 10 times compared to the previous monolithic setup. And that shocked management when they saw the cost growing 8-10 times more than expected.

After a few weeks of discussion, I learned about their pain points and expectations from management, engineering, and the business needs. Along with many tradeoffs and capabilities that the system must have, such as scalability, loose coupling, isolated faults, and predictive costs, I proposed some options. However, the most suitable option for them at that time was to revert to a monolith, but in a modular way. But also decouple some components into separate microservices. What I told them is, “Modular monolith, decouple as needed.”

Aside from the modular monolith, I also introduced them to Hexagonal architecture and how we can combine it with the modular monolith to create a powerful solution for their current system.

In this article, I will briefly walk through how to design a modular monolith pragmatically. I know there are many examples already available on the internet. But here, I will use Golang. I’m not sure if I can do it entirely in Golang, but I’ll try to make it as close as possible to the Hexagonal architecture combined with the modular monolith approach.

Layered Architecture

I started my journey when the Model-View-Controller (MVC) pattern was a thing. I started web development with Yii Framework and Laravel back then, when I was still in college. And after I graduated, I landed in real adult life, and I met new things. And back then, layered architecture was still a thing, similar to MVC — kinda, but it’s mainly for the backend, consisting of Repository (data layer), Service, and Controller.

layered architecture

In this layered architecture, there are usually about three main layers or sometimes more, with a DTO layer. This practice typically divides the application horizontally, with many services in the service layer, many controllers in the controller package, and so on.

The disadvantage of this approach is that, although it is layered, changes to any layer (repository, service, controller) can affect the entire stack from top to bottom. Moreover, people are beginning to realize that having everything connected in this way is not truly scalable.

The Rise of Hexagonal Architecture

Then, some experts, such as Alistair Cockburn (the inventor of the Hexagonal architecture), began evangelizing it. The principle is similar to applying the classic adapter pattern in a more structured way.

hexagonal architecture

Diagram referenced from: https://github.com/jmgarridopaz/bluezone

The domain contains the system’s business logic and language. It provides ports for both inbound and outbound external connections. These ports are connected to, consumed by, or implemented by adapters.

For example, an inbound port might be used by a REST API controller to receive requests and send the request context to the domain layer through a port or interface. Similarly, in outbound communication, the domain layer uses outbound ports to perform tasks such as querying data or calling external services.

hexagonal architecture interface

The same idea can be used to develop a “super app” that might include a CLI interface, a queue interface, REST, and more, as shown in the earlier diagram. This approach also eliminates the need to separate the API from the repository of Cron job scripts.

Similarly, Kafka consumers and RabbitMQ consumers do not need to be stored in different repositories. All these components should reside in a single repository because, under the hexagonal architecture, they serve as adapters, while the core logic resides in the domain layer.

However, if we focus closely on the details and use the concept of “layered architecture,” which involves three layers within an application: repository (data), service, and controller—along with hexagonal architecture, it will resemble the diagram below.

hexagonal architecture in code abstraction

If you compare the first layered architecture mentioned earlier to this hexagonal architecture, both are similar. However, in this hexagonal architecture, we use the term ports which are essentially interface contracts. An interface, as in Java, C#, or Go, consists only of function definitions without any implementation.

Several years ago, I made a blog post and a GitHub repository about “Go Clean Architecture” that actually follows this pattern here (https://github.com/bxcodec/go-clean-arch). In a way, it’s similar in that everything is connected through an interface (ports).

clean architecture

Diagram reference from https://github.com/bxcodec/go-clean-arch

From Uncle Bob, who inspired me to write the Go Clean Architecture, I learned that the deeper a layer is, the more it should be abstracted.

And quoting the blog post from Uncle Bob:

No, the circles are schematic. You may find that you need more than just these four. There’s no rule that says you must always have just these four. However, The Dependency Rule always applies. Source code dependencies always point inwards. As you move inwards the level of abstraction increases. The outermost circle is low level concrete detail. As you move inwards the software grows more abstract, and encapsulates higher level policies. The inner most circle is the most general.

In a way similar to Hexagonal, the deeper layer (the domain) will be agnostic to any concrete implementation/technology; the domain layer shouldn’t talk about “SQL”, it shouldn’t talk about “connection pooling”, etc. In fact, it only focuses on the business domain logic.

Problem with this approach?

At least, based on my experience, even with this kind of separation, the structure can get somewhat messier. Since slicing occurs across horizontal layers (repository, service, and controller), and additional files, such as interfaces (ports), are introduced, there are times when certain services import from other repositories. This approach increases complexity and steepens the learning curve, as components tend to import from each other and reside in the same directory.

Vertical Slicing with Domain Drive Design

Actually, the problem I mentioned earlier is quite common. Martin Fowler supports this in his article, where he also encourages vertical slicing alongside horizontal slicing to reduce the complexity of an extensive application with many domains.

Martin Fowler Domain data separation

Quoting from Martin Fowler's blog post

Although presentation-domain-data separation is a common approach, it should only be applied at a relatively small granularity. As an application grows, each layer can get sufficiently complex on its own that you need to modularize further. When this happens it’s usually not best to use presentation-domain-data as the higher level of modules. Often frameworks encourage you to have something like view-model-data as the top level namespaces; that’s OK for smaller systems, but once any of these layers gets too big you should split your top level into domain oriented modules which are internally layered.

As Martin Fowler stated, we also need to split the application vertically into module groups (domains), while maintaining the layered structure internally. So with the payment example previously, it will be evolved into a diagram like this below,

vertical sliced layers (module)

There were a few times when I also began applying this pattern to some of my projects, organizing them vertically by domain. For example, the payment module includes all payment-related implementations, from the service layer to the data (repository) layer.

This project organization helps build complex systems. Even with the rise of microservices, this pattern can still manage complexity. We can move from a high-level distributed system to more detailed code grouped by domain within each microservice, with each sub-domain divided horizontally by roles such as controllers, services, repositories/data.

Entering the Modular Monolith Era

The previous design, vertically sliced (based on domain) with a Hexagonal architecture, looks really nice and neat. This becomes somewhat cargo-culted among people: “if you build an application, you must do it in hexagonal, and vertically sliced based on domain,” etc.

Nevertheless, it works effectively with microservices or with services that are already set up as such. Properly organizing each service with a similar pattern is very helpful. And since it’s already isolated in a microservice, the domain usually remains within the same bounded context. Therefore, a vertically sliced, hexagonal architecture is invaluable in this situation.

However, microservices are not a cure-all for every problem. They provide solutions but also introduce new challenges, such as high costs and debugging difficulties. As a result, some are returning to a monolithic structure in a modular form, often called a modular monolith. This approach has gained popularity because it is less expensive than microservices and can be split into microservices later if needed.

modular monolith

Rather than creating multiple microservices with associated costs, all functionality stays within a single monolithic service. Internally, however, it is organized into modules based on different domains.

Implementation Challenges

This is how the problem started. If we build a modular monolith with all domains separated into individual packages or directories, cross-boundary calls still pose issues. For example, PaymentService needs to query the PaymentSettings, which belong to a different module.

Typically, based on my observations and past experiences, PaymentService imports the PaymentSettingsRepository directly. This is feasible because all interface modifiers are usually public. Technically, crossing imports to access the repository port or layer between domains is always possible. This can confuse some people, especially when working with a modular monolith. And it only makes the code base messier.

anti-pattern in modular monolith, accessing another module's repository directly

But what’s wrong with that approach?

As I previously mentioned, this issue is not a concern if we view it merely as a simple Monolith. However, our goal is to develop a “modular monolith.” Such a structure should also facilitate easier decoupling into standalone microservices when necessary.

Building on that idea, I foresee a future where we may need to split the domain into a separate microservice. For instance, we could eventually decouple the payment settings domain into its own microservice. In a microservice architecture, it seems unsuitable for the Payment Service microservice to access the Setting data layer (repository) directly.

microservice shouldn’t access another microservice's database

In microservices, direct database access between services is considered an anti-pattern. When constructing a Modular Monolith, we should adhere to this principle when organizing modules within a monolithic application.

For example, if the Payment Service in a microservice architecture communicates with PaymentSettings via a “public” API such as REST, gRPC, or GraphQL, then in a Modular Monolith, the Payment Domain Module should similarly interact with the Payment Settings Domain or Module through a similar “public” API, interface, or contract. The main difference is that microservice communication occurs over a network, whereas within a Modular Monolith, communication is direct within the same process.

So, based on the previous diagram, ideally, we should design them as shown in the following diagram.

introducing a “public API” as the communication gateway between modules

Instead of importing the payment-settings repository, here, PaymentService imports the PaymentSettingService interface (public API). And Payment Settings only exports the public API (interface) on the service while keeping other interfaces isolated internally.

The same pattern can also be combined with the CQRS pattern. If combined, we can view it as shown in the diagram below — I’ve included two options: one for direct command and another for async command via a queue or message broker. But the concept should remain similar.

advanced implementation of public API with modular monolith

So even later, we decouple them into separate microservices, with everything already isolated. We only need to change the protocol from a direct method call to a network API call. If you are already using a queue, that’s even better because the messaging is already abstracted in a modular monolith.

Final Words

Okay, enough of the theory — I know you guys are really eager to see how to do it in practice. With Java, C#, or any programming language that fully supports OOP, this should be straightforward. Since the key to building the modular monolith is using the access modifiers (private, protected, public) at the package level, which are built-in features in those programming languages. The main factor is determining which interfaces or functions constitute the “public API” and which should not be exposed to other modules.

But since I haven’t seen any Golang implementation that satisfies what I know (at least), I will write the example in Golang.

For simplicity, I will use the Payment and Payment Settings example. It might be too simple as an example to showcase the modular monolith. But hey, we have to start somewhere before going further to a more complex example, right?

The step-by-step process for building the modular monolith in Golang will be explained in the 2nd article after this. Initially, I put all the content into one article, but due to the newsletter’s limitations, I had to split it into two articles.

Combining Modular Monolith and Hexagonal Architecture while Maintaining Domain Driven Design Principles (part 1) — this article
Developing Modular Monolith and Hexagonal Architecture in Golang while Maintaining Domain Driven Design Principles (part 2) — subsequent article

Since establishing SoftwareArchitect.ID as my brand, I’ve worked as a fractional technical leader, mainly as a fractional software architect, for several years. My experience spans from small startups to medium-sized companies, more recently, serving as an advisor and architect for an enterprise migrating to the cloud and transitioning from a large monolith to microservices. Contact me at iman[at]softwarearchitect.id for consultation or a fractional role as an architect or tech lead related to building a scalable product and platform

Developing Modular Monolith and Hexagonal Architecture in Golang while Maintaining Domain Driven Design Principles (part 2)

Iman Tumorang — Thu, 13 Nov 2025 17:22:08 GMT

This article is a continuation of the previous one due to the newsletter’s limitations. I can’t send a 20-minute article in a single email to readers because it would degrade the experience (some text would be missing). Instead, I break it down into multiple articles.

Combining Modular Monolith and Hexagonal Architecture while Maintaining Domain Driven Design Principles (part 1) — previous article
Developing Modular Monolith and Hexagonal Architecture in Golang while Maintaining Domain Driven Design Principles (part 2) — this article

So, if you haven’t read the previous part, please do so before continuing. It’s required to read it first to understand my reasoning behind the implementation in this article.

The code repository of this article can be seen here: github.com/bxcodec/golang-ddd-modular-monolith-with-hexagonal. I will reference some code from the repository, and you might need to open it while reading this.

Step 1: Defining the Bounded Context

The first step before developing a modular monolith is to draw the domain boundaries. It’s sometimes hard to do, but it will pay off in the long run.

bounded context in DDD

In the example above, there are three bounded contexts: Sales, Inventory, and Shipping. Each context uses a different language or sometimes the same term with a different meaning. Grouping these into their respective domains isolates communication, simplifying understanding of the entire business process.

A good starting point to draw the domain boundaries is to follow Domain-Driven Design (DDD) technique, such as using

Event Storming

eventstorming

Or, Domain Storytelling for domain modeling.

Domain storytelling

The goal is to define a bounded context within a sub-domain and group related elements so they continue to communicate using the same ubiquitous language. And later, within the same bounded context, we can group them into a single module.

So, back to our example of a payment service. We will group them into two domains — note that in DDD, the payment settings service and payment service are often still in the same bounded context. For simplicity, we can imagine building a payment gateway that supports multiple payment methods. We can also assume that payment settings can be extracted as a different bounded context.

Code structure of a modular monolith in Golang

This bounded context will isolate all modules within their respective packages. As you can see, I have two domains, payment and payment-settings. Both are separated into different modules.

Inside each module, we will see: at least four types: factory, internal, module.go (module definition), and public-api.go (or just payment.go|setting.go| etc)—basically the public API definition for that module.

Factory

The factory essentially acts as the builder, the wiring manager, and the dependency injection manager. Basically, it helps us connect the module that will be exposed and assembled in the main.

factory example

Internal

In Golang, there is no granular access level / package-level modifier like private, protected, or public. Instead, Golang typically uses two levels of visibility:

Exported (Public): functions, structs, or variables that start with a capital letter can be accessed from outside the package.
Unexported (Private): those beginning with a lowercase letter are only accessible within their own package.

In Golang, there is also a concept of an “internal” package. Any code placed inside the internal directory won’t be accessible from external packages. Because of Golang’s limited features, I use the “internal” package to organize my code. I place all non-public APIs within internal, as illustrated in the screenshot below.

internal package in Golang

There are at least three packages: adapter, ports, and service. The adapter contains additional components that implement the technical details for the ports. The service can be considered the “domain” from a Hexagonal architecture perspective. However, since we are also implementing a Modular Monolith in which the public API must be accessible externally, I refer to it simply as “service.”

Module Definition (module.go)

This file will be a simple wrapper struct that holds information about the module itself. While it can be imported into other modules if needed, I strongly advise against this in Go to avoid circular dependencies. Instead, I use it here to organize components related to the module, such as controllers, services, and others.

module definition

Public API Definition

payment.go | setting.go | etc

Other than the module.go in the modules/ package, the rest serves as the “public API,” which defines the module itself. This public API will serve as the reference point for other modules that are interested in or depend on it.

public API in a module

As we can see, we define the public API of the payment module here

The Schema (Payment struct)
The API contract ( IPaymentService interface)

Other modules can access this public API. They can import it directly or create a local copy in their own module, using this definition as a reference, as I explain further below.

Step 2: Accessing Other Modules’ Public API (Interface)

Golang differs from Java, C#, and other programming languages. In Golang, there is a principle that most Golang engineers are already aware of: interfaces are usually defined as domain abstractions for external dependencies.

In our previous diagram,

public API interface between modules

I show that PaymentService is likely “importing” the interface definition from PaymentSettings. This shows a simulation of how the module communicates with other modules via the public API.

In Golang, instead of importing the PaymentSettingService interface from the PaymentSetting module, the Payment module should define the interfaces it needs from the PaymentSettings module or any other modules.

This can also be viewed as specifying the necessary ports (hexagonal ports) for Payment while abstracting the different modules. This also illustrates Golang’s idiomatic practice. Even if PaymentSettingService has 10 methods, PaymentService only needs 1-2 methods, so it only defines a local interface with the methods it requires from PaymentSetting. This also isolates the domain module from the other domain modules if we apply the hexagonal architecture principle.

Create a local copy interface of the other modules’ public API interface

The trade-off of this practice is that there will be a time when the contract between the module we import and the interface we define locally is inconsistent. But it introduces very loose coupling between modules. With this approach, each module can be developed independently.

But why not put them in ports?

You might ask why it can’t be in the ports package. “Since we are also following the Hexagonal Architecture, shouldn’t this be done alongside the other ports?”

The answer is about the modifier.

If you import the ports interface directly, eg, Go will throw a compilation error. You can’t import this interface because of “internal”.

For example, when I tried to import payment settings “internal” ports directly.

trying to import other modules’ “internal” package

And compile it:

Compilation error because importing another module’s internal package

I got an error:

modules/payment/internal/service/service.go:6:2: use of internal package github.com/bxcodec/golang-ddd-modular-monolith-with-hexagonal/modules/payment-settings/internal/ports not allowed

And that’s expected; that’s what we want —why we introduce the “internal” package and put all internal implementation inside the module.

Proper way to import another module’s interface

Think of each module as a microservice. Does it make sense for one microservice to access another service’s database directly? No, it doesn’t, as I mentioned earlier — that’s considered an anti-pattern. Instead, microservices should communicate through a public API.

Therefore, we adopted a similar approach to the modular monolith by separating the public API from other ports. Although it uses a hexagonal architecture, it is still considered a port; this distinction makes upgrades easier. When a module needs to be converted into an independent microservice in the future, it can be done smoothly because it interacts only through the public API, not with detailed implementations.

Step 3: Database Schema

Another key aspect in building the modular monolith is managing the database. Similar to an independent microservice, it should never access the database of another service. This is considered an anti-pattern.

In a modular monolith, even though it’s a single application with a single physical database, I advise against sharing tables across the repository or data layer. Instead, whenever data is required from another module’s table, always retrieve it via the “public API” interface that interacts with different modules.

Isolate tables from different modules usingthe database schema

I’m not sure about other database platforms, but in Postgres, there’s a concept called “Schema” that enables logical separation within the database. Even with just a single database, we can implement logical isolation at the module level.

If you look at the repository I have, you will see I have two schemas.

payment_module
payment_settings_module

Both are defined in the database and used during query execution. This setup provides flexibility, especially when planning to migrate a module to an independent microservice. It simplifies the process because there’s no direct database-level connection with other modules.

Step 4: Assemble all of them

Okay, we have finally isolated all of them into modules. We defined the bounded context. We grouped them into one module. The next step is to assemble them, and they will finally become an application.

Following the hexagonal principle again, we also apply it to how we organize the project, ensuring the application has its doors defined. Could be the REST, gRPC, CLI for cron, Queue consumer, etc.

Hexagonal Interface

So with the same application, what we have will be like a super app that contains all the possible processes. In my code example, I define a cmd package that will assemble the application I want.

Application main.go and command entrypoint

As shown, I have cron and rest commands. When I compile the project into an executable binary later, I can run both of them using the command below.

First, build,

$ go build -o ./engine application/main.go\n

Running the rest API server

$ ./engine rest\n$ ./engine rest --config .env.production

Running the cron (invoked by Crontab/Cronjob)

$ ./engine cron-update-payment\n$ ./engine cron-update-payment --dry-run\n$ ./engine cron-update-payment --batch-size 100

\n\n

\n view raw\n \n example.md\n \n hosted with ❤ by GitHub\n

\n","stylesheet":"https://github.githubassets.com/assets/gist-embed-0ac919313390.css"}" data-component-name="GitgistToDOM">

First, build,

$ go build -o ./engine application/main.go

Running the rest API server

$ ./engine rest
$ ./engine rest --config .env.production

Running the cron (invoked by Crontab/Cronjob)

$ ./engine cron-update-payment
$ ./engine cron-update-payment --dry-run
$ ./engine cron-update-payment --batch-size 100

view raw example.md hosted with ❤ by GitHub

And since we already modularized the domain, adding them to the command should be straightforward. Can see the code example I have.

cron command entrypoint

Refer to lines 58-69, where I use the factory to prepare the modules. This setup enables me to run the CLI command with all business logic encapsulated within its respective domain.

Final Words

Alright, I think that’s all the long explanation about applying DDD Modular monolith with Hexagonal architecture in Golang. It might be a bit different from other thoughts, but I applied this based on what I know and I have experienced.

Designing software is always interesting. Initially, I considered using C#.NET since my client from SoftwareArchitect.ID is using C#.NET, or another option, I am also considering writing it in Node.js. However, after reviewing some examples, I found that both languages are well-established, and I came across some good examples.

For C#.NET, I reviewed this repository: github.com/kgrzybek/modular-monolith-with-ddd, although it differs from my current Golang version due to language limitations. I implemented the same principles while also aligning with idiomatic Golang practices. Additionally, I am also applying the Hexagonal architecture, so I need to find a good balance. This process is both interesting and enjoyable.

Let me know your thoughts. Maybe you have a better idea. We can probably discuss it here (in the comment section) or in the GitHub repository (feel free to open a GitHub issue to start the conversation).

Alternatively, if you’ve identified additional use cases that don’t fit, we can discuss them and develop a better solution.

One thing is sure: although it’s a monolith, it’s not the usual kind but a modular monolith. Therefore, avoid crossing domain boundaries. If two domains communicate excessively, it likely makes sense to merge them into a single domain. This principle also applies to database access.

Always invest the time in domain separation, as defining the bounded context significantly benefits modular monolith development. It helps avoid hacks and common mistakes.

And finally, the code repository of this mini workshop can be seen here: github.com/bxcodec/golang-ddd-modular-monolith-with-hexagonal

References and Learning

How would you describe your ideal team composition?

Iman Tumorang — Thu, 17 Apr 2025 03:00:34 GMT

“How would you describe your ideal team composition?” This is a common question I encounter when I have a job interview. Until now, I still don't have a definitive answer. It depends on various factors, such as the hiring budget and the types of platforms involved- whether it's mobile, web, or both, the company's scale, and many more.

I have experienced many ups and downs in various roles and team setups across different companies. From the beginning of my career in the early stages of a startup and progressing through growth and unicorn phases has shaped my perspective on the entire process. While some may have different setups, the goal remains the same: to improve processes, reduce toil, and enhance overall effectiveness for everyone.

I’m not an expert or a seasoned manager in this field. Speaking from my experience as an individual contributor in this industry. Though I may be a bit young, I believe I’ve gained enough knowledge to share my insights here.

In this article, I share how my response evolves over time when people ask me, “How would you describe your ideal team composition?”

One Team For the Whole Organization

After graduating from a local college in Indonesia in 2016, I secured a position at a small startup with just five engineers: three seniors, myself as a junior, and the CTO. We focus on having fun while learning. During this period, I learned countless lessons. As a team of five, we handle everything from backend and frontend to infrastructure. It's important to be able to learn quickly and take on various roles to ensure we can deliver a working product within the following week or days, allowing us to secure the deal by creating a demo for the customer. In these early startup days, swift execution is crucial, and we must be ready to pivot at any moment.

one team engineering for all

One advantage of this is that we, as engineers, have a comprehensive understanding of the entire process. We can quickly identify any issues that arise. Frontend problem? It will be resolved by tomorrow. Backend issue? That will be fixed in two days, and so on.

For new joiners, the challenges can be overwhelming. Not only do they need to grasp new technologies, but they also have to understand the user journey and domain knowledge, as well as interpret customer needs.

There are also occasions when we, the engineers, are invited by the co-founder to participate directly in customer interviews at the customer’s office. We observe their problems directly and attempt to solve them. It is fundamentally straightforward and very hands-on to build the product at this stage.

But the takeaways that I can conclude with this approach:

Engineers must be generalists who can adapt swiftly, focusing solely on delivery. Sometimes, we just listened to customer feedback in the morning and directly developed solutions by night!
It is easier to manage and can quickly adapt to changing product requirements.
Context switching also becomes a major challenge. In the morning, you might focus on front-end development, and in the afternoon, you need to address a database issue at the infrastructure level. You may discuss feature A today, but then an urgent request requires your attention on feature B. While it may seem productive, it can be quite draining at times.

Is this my ideal team composition?

When people ask me about the ideal team composition, when I was in this situation, I said, Yes, that’s the ideal team composition. It’s a situation when you don’t have too many people, making too much communication overhead. But you also don’t have too few people, making it overwhelming. On the other side, as an engineer, I can learn the complete user and product journey, gaining extensive experience across various tech stacks. My resume boasts buzzwords that people don't expect. I’m evolving into a “Rockstar Developer” with Infrastructure, Backend, Web, and Mobile knowledge.

Team based on the Role

Team based on the role

In the following year, in 2017, I moved to another startup. This is a growing stage startup, where the people are big enough (20-30 engineers), so this company makes some groups instead.

Backend Team
Mobile Team
Frontend Team
Machine Learning Team

Every team member shares the same role, and although their experiences may vary, everyone on the same team communicates on the same ground. For instance, the backend team discusses backend issues only, discussing the database performance issue, API refactoring, Backend best practices, etc.

However, roles like Designer and PM don't belong to this team; they have separate teams, which seems unusual. Engineers become a kind of squad or tribe, or more like a software house with different skill sets.

One benefit of this setup is that, as a new junior engineer, I can quickly contribute to the team. The Seniors can onboard me easily; the knowledge is at the same level. I can ask anyone on the same team. Everyone supports each other because it’s a squad with the same skillset. Although some senior members might attend alignment meetings, junior and mid-level engineers primarily focus on project delivery. Unlike my first job, it’s much easier to begin contributing to the team since the focus is solely on backend tasks.

One of the major challenges that I foresaw back then is when developing a new feature that involves multiple teams. Establishing a clear alignment/contract from the project kick-off is crucial; for example, API contracts need to be defined and finalized so both the backend and mobile/frontend can work independently. Any mid-project changes should be communicated immediately to all teams so that everyone can adjust to the changes.

Whether we like it or not, placing blame on others will happen indirectly (or unconsciously). For example, one might say, “The Backend team has blocked us, so we cannot proceed with testing,” or “The Frontend team is blocking us because they are focused on Feature B,” or “The Mobile team is preventing us from moving forward; they haven't addressed our requests.”

If I encountered a blocker when I was still working at my first company, I would resolve it directly, eg, apply changes to the web app, mobile, or the backend, and configure the infrastructure as needed. There was no excuse not to tackle the problem. However, in this second company, people often find excuses to avoid stepping out of their comfort zones, perhaps out of fear of “breaking” things. Also, because the team setup has been like that, it’s hard to contribute anyway.

At least, that was my personal feeling at the time. I'm not sure about the others. Gradually, I started thinking this way, repeatedly making excuses and saying things like, “Oh, I don’t know about mobile, I can’t handle it. Can you all take care of it? I've created the Jira ticket on your board." Or some ML engineer says, "Oh, we don’t know about Golang. We created the ticket on your Jira board. Please help fix it.”

Is this my ideal team composition?

If I were in this condition/stage, if people asked me whether that’s my ideal team structure and composition, yes, I would likely describe it as my preference. This is where I feel most comfortable. I focus primarily on backend development, where I believe significant improvements can be made. I concentrate on resolving backend technical issues without overthinking. I don’t dwell on the product's features or appearance on mobile devices, as that task falls to the mobile team. My responsibility is limited to ensuring the mobile team's API responses are correctly served.

Also, there is not too much bureaucracy because only the lead will gather and align the requirements if it’s related to another team.

But, one unique situation back then was that even though we’re the same team in the backend, we also have a small sub-team that handles domain-specific tasks. But in the end, it’s still one team. Everyone can easily support each other because the skill sets are the same.

Team based on Product/Domain

Later, in 2019, I moved again to one of the unicorn startups. This new company has more people. It’s a multi-national, globally spread organization. The team is divided based on product, where each product team consists of

Frontend Engineer
Backend Engineer
Infra Engineer
QA
(some team) Also have an Android/iOS/Flutter engineer

In this arrangement, the team concentrates on a single product. If frontend development is necessary, they will include a frontend developer. If mobile development is required, they will hire a mobile engineer. So the team ensures they can support their roadmap, with the right investment (eg, hiring a new engineer with a new skillset)

While not common, some teams prefer their engineers to be polyglots, enabling them to work on various tasks as long as they stay within the same product scope. So instead of hiring a specialist engineer, the team have generalists, who can be a mobile engineer, a web engineer, a database engineer, an infrastructure engineer, or even a QA engineer who is setting up their automation test. However, the idea is still the same: the team is self-sufficient to do their product work.

This enables the team to focus and iterate more rapidly without blaming others, such as saying they are “blocked” by different departments/teams. Each member operates like a “mini startup” within the company. That can act freely and autonomously. The team possesses all the necessary skills to implement changes related to their product.

When I refer to a mini startup, I mean that the product team will create its own roadmap, develop the product it aims to sell, and so on. In this setup, the Product Manager (PM) functions as the CEO, while the Tech Lead takes on the role of CTO within this mini-startup.

Domain / Area Level

This arrangement extends up to the Domain area level, where a higher-level manager oversees the teams below.

Team based on Product/Domain on a higher-level view

The unique role that I experienced in this setup was the architect role, where I was positioned. I was one of the group architects who oversaw several product teams. The ideal situation is that every product should implicitly have an “Architect” role. So these architects will align with the group architect to ensure the integration within the domain/area is less friction. Architect and Techlead (on product level) or Architect and Engineering Manager (on Group /Domain /Area level), it’s like two brains in collaboration. The Engineering Manager/Techlead focuses on process and people management, and the Architect focuses on technical decisions, owning the architecture roadmap, etc.

However, the downside of this structure is that the bureaucracy can be overwhelming. Numerous layers must be navigated when proposing changes that impact the entire domain. Implementing changes is time-consuming because each product team has its own roadmap and priorities. As a result, it often feels like a competition to see whose roadmap wins support at the higher management levels.

However, it is relatively easy for higher priorities that come from the top level because everyone will make it their priority. And it’s easier to navigate because everyone will be autonomous, running independently. This is where you need an Architect to navigate the changes, by making a kind of “Architecture Northstar”, so that everyone will still align with the future, avoiding duct-tape solutions across the products when working on one priority altogether — read my blog post about Writing Architecture Northstar Document.

The birth of Platform Domain

Another interesting concept I learned in this setup is the birth of the “Platform Team”. As every team now functions like a product. However, referring to something like the API Gateway as a product feels strange. Therefore, instead of using the term Product team, we designate it as a Platform team. This team doesn't serve the customer directly; instead, it supports the product teams within the organization.

For instance, the dashboard platform team created the Microfrontend. This setup allows any Frontend Engineer in the product team to contribute by integrating their Microfrontend with the platform's core. Similarly, the Public API Gateway team is working on a Gateway Platform, enabling any Backend Engineer in the product team to expose and register their APIs for public access. Likewise, the Mobile Platform aims to foster the Mobile ecosystem, creating libraries, modules, and more, so that mobile engineers across all teams can easily contribute and implement their changes.

When I refer to the Platform, I mean that the platform team focuses on building the platform itself, rather than developing product features or fulfilling requests from other product teams. So it’s not like, for example, Product Team Payment, asking Platform Team to implement some changes in Mobile or Web because the Payment Team doesn’t have any Mobile or Frontend engineers. Instead, the platform team creates a way for the Payment Team to implement it by themselves easily, without waiting for the Platform team to implement it.

This distinction can sometimes be challenging for people to grasp, as it requires a certain level of understanding to differentiate between the platform and the product. For more insights, check out my previous blog here: “Product vs Platform: the Struggle to Make the Domain Boundaries”

Is this my ideal team composition?

At this stage, this is my preferred team structure. Considering the tradeoff involving considerable bureaucracy, it’s a necessity. As the company expands, alignment among individuals becomes increasingly essential. As long as team members are open-minded, ready for challenges, and willing to evaluate and question the status quo critically, I believe this represents the ideal team composition.

I remember how my team worked on expanding our product to one country to deliver new product payments. It was during the COVID pandemic time, and we could finish it in two months. We had a whole team: backend, frontend, database/infra engineers, designers, product managers, QA, and tech leads. There were no blockers; if something was blocked in the API gateway, we made changes, and if something was blocked with Mobile/Web, we made the changes directly to the repository — that later also became configurable and decentralized eventually when the Platform team made fixes.

However, the challenge with this setup primarily affects the platform team. Since it is utilized by several product teams, implementing versioning or breaking changes becomes difficult. Requesting product teams to upgrade their versions or transition to a new workflow will require time and alignment. Moreover, the product teams have their own priorities to consider.

For example, I remember rebuilding our new Auth Platform, and it takes a lot of alignment with the team, needs some hard push from management, so every product team complies with it, eg, consuming new headers returned from the API gateway after using the new Auth Platform, etc.

Another example, sometimes the platform team must be proactive and occasionally interact with other product repositories to facilitate library/client version upgrades. I can't recall how many times I've raised PRs while being on the platform team. People often recognize me from my GitHub contributions to their repositories due to upgrading the client version of our platform API in their repositories, even before we meet in person. 😅

My Ideal Team Composition?

So, given all my experience, what is my ideal team's composition? It largely depends on the stage I find myself in. In the early stage of a startup, I believe that one team for all roles is effective. However, during the growth stage with 20-30 engineers, having one team focused on a single role seems optimal. This approach allows me to oversee all product features while ensuring high-quality engineering output.

When operating at a unicorn or enterprise level, working within specialized domains is advantageous. This structure enables me to zoom in and out of different contexts. Zoomed out, I can see the broader eg, Payment Domain, and when zoomed in, I notice various products within it, each managed by a dedicated team. This setup facilitates smooth context switching between high-level and low-level discussions.

As the company evolves, a different approach is required. What was effective three years ago may not work today. Back then, the company was smaller, with a limited user and customer base. The risks were manageable, and implementing changes was straightforward, requiring minimal discussions about potential risks or persuasion. A single team for all tasks seemed efficient.

However, as the company grows, this structure becomes burdensome, requiring specialized teams for each stack: backend, frontend, and mobile. As the company expands, complexity increases, demanding individual attention for each product. Therefore, a single team structure is insufficient. Instead, adopting a product or domain-based separation is the optimal solution, allowing each product to concentrate on its development.

Ultimately, it all depends on the situation. I may encounter more examples of team composition in the future. But if hiring budget is not the issue, I will definitely have one team with various skill sets, where in one team, I will have Backend, Frontend, Mobile, Designer, Infra, QA, and Product manager, — like a “mini startup” that focus on one domain that may have sub-domain (products/features). With this setup, I believe we can achieve many things as a team, unblock ourselves, and not depend on other teams.

Have a different viewpoint? Please share your thoughts in the comments below. If you agree with my perspective, feel free to share this so others can see it.

Product vs Platform: the Struggle to Make the Domain Boundaries

Iman Tumorang — Thu, 09 Jan 2025 02:01:02 GMT

Hello 👋

It’s been a while since my last newsletter was posted. A lot of things happen in real life. 2024 is a crazy year. From the beginning of January 1st to the end of 2024, it’s a roller coaster life. It’s a good and bad year, good I learned so many life lessons. Bad year, I learned too many life lessons and didn’t have enough time to write new blog posts. Life update! I’m moving to a new company, and it’s been a few months now.

I want to share some thoughts on one of our many problems in this blog post. Please note that this is my personal opinion. I do not represent the company I work with or any group of people. But of course, I bring up this topic because of one of the problems we’re facing in my current job.

One of our most challenging problems right now is defining domain boundaries between the platform and the product in Software Architecture. Fortunately, our senior leadership is moving towards platformization. Simply, platformization means creating a configurable, well-structured system or process that will make it easy for any product team to integrate with each other and, possibly, build new products on top of the existing platforms.

From theory, it may seem easy to understand. A product is anything we sell, feature, or function—anything that solves the customer's problem. The platform is a tool we use to support our product.

Easy, right?

However, it is always difficult to establish clear boundaries between product and platform at the organizational level, where interests, collaborations, team capacity, and expertise will determine the domain boundaries.

Intro

I’m not a product expert, but I have more than four years of experience working on products and three to four years of experience establishing a platform to support company products.

From my point of view, a product is, in simple terms, something we sell to customers. It could be a service, an item, or anything else.

Let’s talk about Payment Gateway (PG). One of the PG products is, let’s say, payment with Direct Debit. In general, Direct Debit is a cashless payment method that will deduct or charge the customer’s bank account directly (Stripe’s explanation). The interface might be different; for example, outside Indonesia, it’s common to use Internet Banking, where the merchant will deduct the user's bank account directly through some validation (MFA, etc). In Indonesia, however, some banks allow Internet banking, and most only allow it through a debit card, which is also directly linked to a bank account (Xendit’s explanation).

From the explanation above, Direct Debit seems like a somewhat complicated product, depending on which country you’re referring to. It’s a customized feature that cannot be generalized globally, especially regarding how it works on the technical side.

Another example I can use is an identity verification service, like Veriff.com. I tried the product when I wanted to verify my document in Deel. Deel is a platform for freelancers that helps with HR and payroll. So, I used Deel for my fractional job. During my registration, I saw that they use Veriff for identity verification.

So, in general concept, Identity Verification works like as simple as:

Ask the user to provide a document
Selfie
Selfie + Document
Verify to Government Registry (if possible)
Get Verified
Done

Different countries may have various ways to validate the document — including different citizen registries. It’s something we can’t generalize globally.

However, the interesting fact is that, from Deel's point of view, Veriff is one of the platforms that helps them verify their customers to support their products. The same goes for Eccomerce or any business that uses a Payment gateway to accept payments from its customers. From Eccomerce's point of view, a Payment Gateway is just a platform. They can replace it with anything, e.g., self-build, change to another third party, etc.

From the words themselves, a Platform is a foundation—it’s the baseline. When we think of building a house, we can use the concrete base, wiring, etc., to compose and create rooms. At the same time, the rooms themselves are the product — which is the result of composing many platforms. It’s not our core product but a critical functionality to support our products.

Platform vs Product in Platformization Vision

product vs platform in platformization vision

Distinguishing between platform and product can sometimes be confusing. You could agree or challenge this, but for me, the simplest way to identify a platform and product in an organization (company/business) is to ask these questions.

Is this a business value that your customers paid for?

You are a business owner selling alcoholic drinks and shipping worldwide. Therefore, you need direct debit from any bank worldwide. Identity verification is also necessary for all people, and government documents and registries must be validated to determine whether the customer is of legal age.

E-commerce for Alcohol Beverage

So, from this, your customer pays for the alcoholic drinks you sell. They’re not paying for the Direct Debit feature or Identity Verification. They’re reaching out to you because you sell alcoholic beverages. So, the platforms in this example are the Payment Gateway and the Identity Verification. And your product is the e-commerce that sells alcoholic beverages.

The product is what the customer pays us for. The platform is what we, as an organization, paid for or built to support our product.

Can any products use this?

The next question I usually ask myself when defining the domain boundaries between product and platform in an organization is to confirm whether any product can reuse the component (a service or module, etc.).

For example, Notification. In SaaS companies, eg Payment Gateway or Identity Verification. It must have a notification module to send the notification (email, SMS, or Webhook). Payment Gateway has multiple products, e.g., direct debit, card payment, e-wallet payment, etc. All these products will always send notifications, e.g., payment initiated, succeeded, failed, etc. Even though all those products may have different configurations, it is all just a notification. So, from this example, we can extract the notifications and make them a single platform inside the Payment Gateway. It’s not a product we sell to customers, but it supports the payment products the Payment Gateway sells to their customers.

platform is a reusable components

Here’s the catch: a Platform is not tightly bound to business logic but explicitly built to organizational needs. But if we want to be extreme idealists, a Platform could also be extracted like an external company. So imagine Twilio. It’s a Notification Platform, but it’s a big company. Not only one, but millions of companies are using it. But from the Payment Gateway organization's pov, the notification platform should be something that can be configured easily to all product needs, or worse, can be replaced easily when it’s not aligned with company policy, e.g., cost is too expensive, etc.

The platform is a component that can be reused by any product inside the organization with minimal configuration or changes.

Platformed Product

The Dreams

Okay, we now clearly understand the difference between product and platform. But now, a question may come: Is a product of one SaaS company somehow just a platform for its users? Is it possible to make our product work like a platform?

This is the challenging part. I think this confuses many people and causes them to have different expectations when we say “platformization.” It’s a direction to make the product more configurable and serve all customers’ needs. All business owners, leaders, investors, etc., dream of creating a product that can (magically) solve any problem and allow the organization to expand aggressively. When a product can do this, there’s no competition anymore. We can quickly solve everything in one day and expand aggressively.

direct debit product with many usecases

Let’s take Direct Debit as an example from the beginning. Direct Debit may take a different approach depending on the bank, country, regulations, etc. So when we say “platformed product,” we mean making Direct Debit a platform that can onboard any new direct debit type and somehow make it configurable. Imagine what would happen if we could do this: We could expand direct debit payments to any country with fewer changes.

Moving in this direction requires much effort, trial, and error. It must not be too abstract, causing the context to be missing, yet not too specific, making it too complicated.

It also requires a lot of discussion and negotiation, including changes to the existing business flow.

It’s hard, but it should not be impossible — at least with fewer changes.

Working in both product and platform areas surely gave me a lot of experience in thinking in a “platform mindset.” I used to think it was impossible to make a product really configurable and solve any new incoming problems because software eventually changed depending on market needs, regulations, etc. So, it’s impossible until I see a perfect example of how a platform works.

An example we can use is how Operating Systems work, both on Mobile and Desktop: Windows, MacOS, iOS, and Android. These are the peaks of the platform. They allow any product to run on top of them, yet they have core OS features. We can write software or plugins to serve our needs on top of them. But it might be possible because it only does a platform job: an Operating system. An OS cannot browse the internet; it needs an application to do that. Or it can’t make a presentation slide; it needs Ms Powerpoint to do that. It extracted all unnecessary functionalities from the core OS and made it possible for everyone to create an application running on top of it. This is a perfect example of what a Platform should look like.

Another example is that let’s see how Kong Gateway or any API Gateway Platform is in the market right now. What I like about them is that they allow everyone to make their own “plugins” on top of the Kong gateway. They also support a configuration-based system for the API registry. People only need to change the kong.yaml config and register a new API for the public API.

kong gateway as an example of platformed product

The diagram above shows what a platformed product should look like. The product is an “API Gateway,” but it allows everyone to configure it, including adding a plugin to serve a specific use case. So with this, let’s say the company wants to add a new product payment method, e.g., Crypto Payment. Then, they won’t need to add new code to the API gateway; instead, it will be just simple configuration changes, e.g., YAML file changes.

The Challenges

From the beginning of this article, I’ve discussed platforms, products, and platformed products. In my eight years of professional experience, I've encountered challenges, such as people who are confused about what they want versus what others understand.

Some people want the platform to be a support and just an extra tool, a baseline that works like an OS, support plugins, etc. Some say a platform is a configurable product that can solve customer problems with fewer changes. Some say the platform is like a buffet. When I want to build my product, I will pick the building blocks (platform) and compose my product based on customers’ needs on top of all those building blocks.

In my opinion, there is nothing wrong with all those statements. Everyone has a glimpse of what a platform should be capable of, which is “configurable.” But again, we still need to ensure everyone has the exact expectations of how configurable they want in for the system itself.

Are they expecting a platform that works like a generic tool, such as an API Gateway, Authentication, or Notification that is not tightly coupled with the product’s logic? This will help them build new products quickly on top of the existing tools and platform. Or are they expecting their product to be configurable for their customers' needs? For example, when expanding to SEA, the product must be capable of X features, while when expanding to LATAM, the product must be capable of Y features.

So, these two expectations must be explicitly aligned. What does the leadership want? What does the organization direction? When everything is aligned, it will be easier to draw a line between the domain boundaries where the Product and Platform are located. It will also help to focus a group of teams on their domain.

First, it’s essential to understand the difference between a Platform and a Product. Then, when we have clear expectations, we can start to make the product be platformed—here, I call it a Platformed Product.

Platform vs Product vs Platformed Product Breakdown Examples

1. Direct Debit Payment

If I want to make a diagram showing the location of the platform, product, and platformed product, it will look something like the one below. For example, let's use our previous example.

direct debit with many usecases

If we grouped them into three categories, they would look like these

direct debit platform breakdown

Platform:

Gateway Platform
Auth Platform
Notification Platform

Products:

They sell Direct debit with Debit Cards. In the early phases of the startup/company, they might have a dedicated microservice for this, which is totally fine. It’s a phase for validating the market, so there is no need to be idealistic.
Later, in a few months, they identified another way for Direct debit with Oauth+OTP, so they created another Direct debit service for Oauth + OTP with web interface login payment.
…and later with SmartID
…and later with Giro
…etc

Of course, this is unhealthy, it only increases the complexity and cost of maintaining the products.

Platformed Products:

One Direct Debit platform/service, but with a configurable service to add a new Direct Debit type. Or at least allow plugins to support new direct debit types that are onboarded.
The goal is to allow fewer changes when onboarding new product types for the direct debit.
It’s still a product. If a team owned this, I would still call them a Direct Debit product team even though they’re making their product become a platform.

2. Identity Verification

To give more examples, let’s take Identity Verification products, like Veriff.com, which I mentioned above.

veriff products

On their website, there are 4 top products

Identity Verification
KYC
Biometric Verification
Fraud Mitigation

Where each product also has sub-products. But the essence is still the same for each group.

identity verification products helicopter view

Based on that, I can imagine these are the structures of the product vs. platform inside Veriff.

But one thing to note is that all three actually have similar features. For example, ID verification requires verifying the document and a person's face. KYC also uses ID Verification and maybe some other validations with the fraud registry, etc. Biometric Verification focuses on facial recognition, eye recognition, and other related features.

identity verification products

So, let’s imagine this company from the early stage. They obviously built the ID verification first— let’s assume it’s built-in one service. At the same time, maybe they got a new request for KYC that requires the user to also be validated for their government records, eg, AML (Anti Money Laundering) records, etc. Then, they also need to build it. For faster iteration, they build all independently — Again. This is just an assumption for a better example of how the transition from product to platformed product.

So, with this example, we can draft the three categories like the Direct Debit example above.

identity verification products with platformed products

Platform:

Gateway Platform
Authentication Platform
Notification Platform

Products:

ID Verification service that contains all the core functionalities, e.g. Document verification, government registries, Age Validation, Face Recognition, etc
KYC Service that contains core functionalities for KYC, Document Verification, government registry validation, etc
Biometric Verification Service

Platformed Products:

Now, we can extract all the reusable stuff and make it a platform, for example, Document Verification, Government Registry validation, Face Recognition, Age validation, etc.
All these platforms can be combined to create new products and support existing products that they sell to customers (KYC, ID Verification, Biometric verification, etc.).

Conclusion

Alright, that’s all my thoughts about Platforms and Products. I wrote this based on my experiences. It is an opinionated topic, yet it’s an interesting one to discuss. It tests our craftsman skills to make configurable software that can adapt to most new use cases. It’s not 100% adaptable to new use cases, but at least we should aim to make fewer changes whenever a new use case comes up.

Some takeaways,

It’s essential to understand how to differentiate between products and platforms. The platform is the foundation for composing or configuring customer-facing products. Moving forward, we should make our product work like a platform — easy to configure based on new markets or customer needs.
Investing in a platform movement has never been wrong, but expectations must be carefully aligned. Some people love to oversell the “platform” buzzword, but we engineers know the struggle to match expectations. I strongly advise aligning with all stakeholders when your team or organization starts overselling “platform” words in a meeting.
Having a clear line between platform and product helps us establish clear domain boundaries, which might affect the organization's structure. This is especially true in the microservices world, where we can group services based on domain, following a Domain-driven design approach. Unclear boundaries will create chaos and communication overhead and eventually affect productivity, issue resolutions, and feature developments.

Menulis Dokumen Architecture North Star

Iman Tumorang — Fri, 28 Apr 2023 04:23:29 GMT

Photo by Mike Setchell on Unsplash

Untuk orang-orang astronomi pasti sudah familiar dengan sebutan North Star (Bintang Utara). Saya sering dengar, bahwa orang pada zaman dahulu menggunakan rasi bintang sebagai penunjuk arah. Dan tidak jarang juga saya dengar, bahwa para pelaut dahulu kala, juga sering menggunakan bintang sebagai penunjuk arah. Salah satu bintang yang terkenal adalah Bintang Utara, atau disebut juga bintang Polaris.

Polaris posisinya tidak berubah, dan selalu menunjukkan posisi utara. Sehingga banyak orang pun menggunakan bintang Polaris sebagai pedoman ketika bernavigasi.

Dari sini, dapat kita ketahui beberapa kata kunci, yakni “pedoman”, “penunjuk arah”, dan “tidak berubah”. Dan karena inilah, banyak orang menyebut North Star, sama seperti tujuan ideal yang akan dicapai, baik personal ataupun organisasi.

Term ini jugalah yang kini banyak di adopsi oleh orang orang bisnis, seperti, North Star metric, yang menjelaskan parameter yang digunakan untuk memprediksi kesuksesan dari bisnis. Bisa di asumsikan, bisnis akan gemilang, jika perusahaan tersebut dapat mencapai “North Star metric”.

Agar lebih paham dengan konsep north star, buat kamu yang penggemar anime / manga One Piece, maka saya dapat analogikan menjadi lebih sederhana.

Dalam cerita manga/anime One Piece, disebutkan tokoh utama, Luffy, Kapten Bajak Laut Topi Jerami, memiliki mimpi untuk menjadi Raja Bajak laut dengan menemukan One Piece, harta karun yang tak ternilai yang telah ditemukan oleh Raja Bajak laut sebelumnya.
Dalam perjalanannya, dia pun mengalami banyak situasi naik dan turun yang membuat dia menjadi lebih kuat dan penuh petualangan, dan seiring waktu dia juga me-rekrut nakama nya (atau crew bajak lautnya) untuk menemani perjalanannya menemukan harta karun One Piece.
Nah, semua crew ini, juga memiliki mimpi masing-masing. Sebut saja, Zoro si wakil kapten, bermimpi menjadi pendekar pedang nomor satu di dunia. Nami, si navigator, ingin menggambar peta dunia. Sanji bermimpi ingin menemukan All Blue. Dan anggota beberapa anggota lainnya, juga memiliki mimpi yang berbeda-beda.
Jika dikaitkan pada satu titik, semua ini akan tercapai saat mereka menemukan One Piece. Karena One Piece tersebut berada di pulau terakhir yang ada di dunia One Piece. Jika disederhanakan, dalam One Piece universe,
Zoro akan bisa mengakui dirinya jadi pendekar terbaik, jika dia telah melewati semua tantangan dan sampai di pulau terakhir. Perlu diketahui untuk mencapai hal tersebut sangatlah banyak rintangan, perkelahian, dan perang dimana-mana.
Nami akan dapat menggambar seluruh peta dunia One Piece universe, jika mereka telah menemukan pulau terakhir.
Sanji juga akan menemukan All Blue, yang hanya ada di pulau terakhir.
Begitu juga anggota lainnya, seperti Franky, yang ingin membuat kapal terbaik yang mampu melewati segala jenis laut dan badai, ya tentu saja ini hanya bisa divalidasi jika mereka telah mencapai pulau terakhir.

Dari cerita One Piece diatas, dapat kita petakan pada struktur perusahaan. Harta karun One Piece yang ada pada pulau terakhir, merupakan tujuan akhir dari Bajak Laut Topi Jerami pada cerita diatas, dalam konteks perusahaan ini merupakan visi perusahaan. Visi perusahaan bisa apa saja, seperti eccomerce terbaik di dunia, atau one stop solutions for payments, atau ekspansi ke berbagai negara, dan sebagainya. Ini merupakan contoh dari North Star. Visi perusahaan atau impian yang hendak dicapai si perusahaan.

Lalu, semua crew dalam Topi Jerami (anggota bajak laut Luffy) pada cerita One Piece diatas, bisa di analogikan seperti tim/divisi dalam setiap perusahaan. Contoh, Nami ingin memetakan seluruh dunia, mungkin dalam organisasi, ini adalah divisi sales dan marketing, yang ingin acquire user sebanyak-banyaknya, bahkan seluruh user di dunia. Zoro ingin jadi pedekar terbaik, ini mungkin tim engineering, yang ingin memiliki world-class engineering culture terbaik dan menjadi pioner di dunia teknologi. Franky ingin membuat kapal terbaik, bisa di analogikan seperti Infra team yang mampu support dan scale bisnis support zero down time, dan fast response dalam segala medan.

Sehingga, berlandas pada visi (north-star), semua tim yang ada pada perusahaan akan bekerja independen namun saling mendukung guna mencapai visi (north-star) dari perusahaan tersebut.

Architecture North Star

Dari cerita diatas, kita sudah tahu apa itu North Star secara garis besar ketika dipetakan dalam struktur organisasi. Lalu saya akan membawa kita lebih detail lagi, yaitu North Star dalam sistem architecture. Konsepnya sama, bedanya pengaplikasian-nya lebih ke teknis, dan fokus pada sistem architecture.

Saat perusahaan telah menetapkan North Star metric yang akan dicapai, maka semua tim/divisi akan saling bekerja sama untuk mencapai tujuan tersebut. Contoh, Perusahaan akan fokus pada ekspansi ke negara lain.

Mungkin dari operation, dan business tidaklah terlalu banyak major changes. Namun jika kita berbicara dengan sistem, sistem yang sudah berjalan bertahun-tahun, sistem yang sudah kompleks, tidaklah mudah untuk support kebijakan tersebut. Terlalu banyak resiko yang harus dipertimbangkan, seperti refactor, versioning, data migration. Belum lagi depencies antar service/tim yang biasanya berimbas ke banyak tim engineering lain.

Karena faktor kompleksitas inilah, maka semua perubahan perlu dilakukan dengan hati-hati. Dibutuhkan satu dokumen algiment yang mencakup ideal design yang support terhadap kebijakan perusahaan yang baru. Dan tentu saja harus menjelaskan siapa saja tim-tim yang terkena impactnya. Terlebih jika tim yang kena impact adalah tim core yang terintegrasi oleh banyak tim produk, seperti Auth, Ledger (core banking), dan lain sebagainya. Dan dokumen ini lah kita sebut dengan Architecture North Star document.

Untuk menyimpulkan, tujuan dari Architecture North Star tidak lain diantaranya adalah memastikan semua orang memiliki:

Shared Understanding —setiap tim yang terlibat akan memiliki pemahaman yang sama dan visi yang sama
Coherent Architecture —sistem architecture yang jelas dan bukan arsitektur hacky-hacky atau tambal sulam yang menimbulkan banyak tech debt.
Less Coordination — membantu tim membuat keputusan cepat yang tajam tanpa koordinasi dari architect.
Visibility — membuat semua orang paham dan memiliki common language baik dari product / business dan juga engineering
Autonomy — semua team akan bergerak sendiri, dan mengontrol pace masing-masing selama mereka memiliki tujuan yang sama.

Jadi, Architecture North Star, akan menjadi fondasi untuk semua tim engineering/product yang terlibat untuk mencapai suatu goal, baik business goal, ataupun engineering goal. Dan dokumen tersebut haruslah fixed, mudah digunakan, mudah diakses, dan tidak ambigu, serta memiliki cukup informasi yang membantu semua team membuat keputusan sendiri.

My Experience in Writing Architecture North Star

Beberapa bulan terakhir, saya mendapat mandat untuk menjadi architect dari 4 tim core yang ada di perusahaan saya bekerja saat ini. Dan karena ini tim core, maka banyak tim-tim lain yang beketergantungan dengan ke 4 tim ini. Ke 4 tim tersebut adalah, Auth team — dimana setiap product, user pasti membutuhkan fitur Auth, dan menjadi pintu utama untuk semua akses, seperti API Key, User login, Server key, dsb.

Lalu 3 tim lagi adalah, Ledger team, Billing team, dan Reporting team. Karena perusahaan saya bekerja adalah perusahaan SaaS Payment Gateway, maka setiap produk haruslah terintegrasi dengan Ledger (core-banking) untuk pencatatan transaksi pembayaran, lalu karena produk utama kami adalah SaaS, maka semua produk juga harus terintegrasi ke Billing system dan Reporting, yang membuat semua produk dapat (allow) me-monetize produk mereka dengan pricing yang mereka inginkan.

Nah ke 4 tim inti ini, merupakan menjadi tanggung jawab saya untuk memastikan setiap development baik fitur, refactor, atau apapun yang berhubungan development tidak mengganggu tim lain secara drastis.

Normalnya, semua tim produk memiliki roadmap dan planning yang berbeda-beda. Memiliki prioritas berbeda, dan memiliki pace berbeda. Sehingga, saat kita develop suatu fitur di tim core, maka belum tentu semua tim yang ter-impact akan dapat langsung follow dengan cepat.

Lalu jika ada kebijakan organisasi yang sangat berhubungan dengan tim core, maka akan banyak tim lain yang kena impact. Sehingga saya pun harus menuliskan dokumen yang akan menjelaskan garis besar bagaimana ke 4 tim ini di masa depan, serta langkah-langkah yang harus dilakukan untuk mencapai titik tersebut.

Dokumen ini yang kami sebut “Architecture North Star document” akan menjadi panduan untuk semua tim terlibat membuat prioritas masing-masing. Dan membuat setiap tim lebih autonomous, termasuk di tim inti. Sehingga semua tim align pada satu visi design yang akan dicapai. Meskipun banyak prioritas dari issue lain seperti kebutuhan infra (DB upgrade, maintainance, etc), atau bahkan PM request fitur baru, maka tim engineer akan tetap align, techspec document dan development akan tetap berlandas pada ideal design yang sudah terpapar pada Architecture North Star document.

Menulis dokumen Architecture North Star

Untuk menulis dokumen Architecture North Star, buat saya tidaklah mudah, karena membutuhkan banyak koordinasi dan aligment agar mencapai kesepakatan terhadap semua stakeholders.

List Pain and Dreams

Namun langkah yang saya lakukan adalah tentu saja dimulai dari north-star metric yang akan dicapai perusahaan. Sebut saja, mencapai 100Billion transactions. Atau acquire 100 juta user baru. Atau ekspansi ke 5 negara baru.

Untuk support kebijakan ini, banyak tim harus memikirkan kondisi mereka saat ini. Apa saja yang menjadi blocker dimereka? Lalu apa ideal state yang harus dimiliki.

Sebut saja, untuk tim saya, yakni tim core. Maka untuk support ekpansi ke negara baru, maka banyak perubahan yang harus dilakukan pada sistem sistem core. Contoh, yang sebelumnya sistem kami hanya spesifik dengan negara Indonesia, maka kami harus refactor sistem agar bisa jadi agnostic terhadap semua negara. Atau setidaknya configurable, karena mungkin setiap negara memiliki regulasi yang berbeda-beda.

Nah untuk mengetahui apa saja yang perlu direfactor, tentu saja yang saya lakukan adalah melakukan interview dengan semua stakeholders yang terlibat. Apa saja pains yang ada sekarang jika kita hendak ekspansi ke negara baru? Lalu bagaimana dreams yang diharapkan?

list pain and dreams

Hasil dari interview ini akan disimpan dalam dokumen pain and dreams. Dokumen ini akan dianalisis tentu saja dengan pertimbangan current system yang sudah berjalan.

Analyze and Write Architecture North Star Document

analyze pain and dreams

Setelah Pain and Dreams kita dapatkan, maka tahap selanjutnya adalah memetakan system yang ada sekarang, sejauh apa perubahan yang perlu dilakukan untuk meng-cover keseluruhan pain and dreams. Disinilah role seorang Architect dibutuhkan untuk melihat secara high-level view. Architect harus menjadi jembatan dan melihat dari semua sisi, dari sisi stakeholders dan sisi tim yang terlibat, bahkan dari sisi user atau customer.

Core team tentu saja memiliki ideal solutions, namun terkadang ideal solution tidak align dengan stakeholders lainnya, eg, Sales, Product teams, Finance, dsb. Sehingga perlu aligment yang dipimpin oleh si Architect.

event storming with all teams, domain experts, and all impacted stakeholders

Praktis yang saya lakukan ditahap ini adalah dengan mengikuti Domain Driven Design (DDD). Dimana saya akan melakukan beberapa praktis DDD seperti Event Storming, atau Domain Story Telling yang dimana tujuannya adalah memperjelas domain boundaries, dan memperjelas ideal flow berdasarkan domain knowledge para domain experts (eg, PM, Engineer, Sales, Finance dsb) guna menyelesaikan masalah yang ada pada Pain and Dreams yang sudah di dokumentasikan.

Dalam praktiknya, ketika membuat dokumen architecture north-star untuk mendapatkan gambarannya dan aligned dengan semua stakehodler, para domain expert, bisa mecapai 3-6 bulan agar dapat selesai. Semakin banyak tim terlibat, maka makin lama dokumen akan dapat di finalisasi.

Finalized and Distribute Architecture North Star

finalize the north-star and distrbute to all stakeholders

Saat architecture north star sudah selesai, maka dokumen tersebut sudah dapat digunakan sebagai bahan acuan atau pedoman untuk development atau perbaikan semua sistem atau produk yang terlibat.

how architecture north-star document owner use the document

Untuk owner (pada diagram, core team) dari dokumen architecture north star, mereka dapat menggunakan dokumen tersebut untuk sebagai acuan ketika pengembangan fitur baru, atau bahkan refactor sistem yang sekarang untuk mencapai ideal state sesuai yang sudah dipaparkan pada dokumen architecture north star.

Sama halnya dengan tim product atau tim yang kena impact dari north-star dokumen dari tim core, maka mereka dapat menggunakan architecture north star tim core juga sebagai acuan untuk pengembangan fitur baru, atau untuk sebagai acuan di architecture north star mereka secara tim juga.

how the impacted team uses the other’s architecture north star document

Sehingga, meskipun setiap produk memiliki prioritas berbeda, tetapi dengan semua tetap aligned pada satu visi yang ada pada architecture north-star, perubahan pun tidak terlalu mengejutkan, melainkan lebih terstruktur.

Dan yang paling penting adalah, semua proses ini haruslah diulang-ulang / direvisi kembali sesuai kebutuhan. Karena seiring dengan waktu berjalan, business goal mungkin berubah, sehingga ketika itu terjadi, kita harus tetap memastikan architecture kita tetap align dengan tujuan perusahaan yang baru.

Kesimpulan

North Star dalam artinya, terdapat beberapa kata kunci, yakni “pedoman”, “penunjuk arah”, dan “tidak berubah”. Sehingga dari makna ini, banyak orang menyebut North Star, sama seperti tujuan ideal yang akan dicapai, baik personal ataupun organisasi.

North Star Metric, menjelaskan parameter yang digunakan untuk memprediksi kesuksesan dari bisnis. Bisa juga diartikan sebagai dreams yang ingin dicapai dari sebuah perusahaan, eg, 100 Billion transactions monthly.

Architecture North Star, merupakan ideal system architecture yang harus dicapai oleh tim yang terlibat. Architecture North Star ditulis dalam satu dokumen yang dapat dijadikan sebagai pedoman dan referensi oleh semua tim engineering yang terlibat. Dokumen ini akan digunakan ketika melakukan development atau refactor pada sistem yang telah berjalan.

Untuk menulis dokumen Architecture North Star, dimulai dari menerjemahkan visi perusahaan, dan perubahan yang harus dilakukan untuk mendukung visi tersebut. Secara garis besar, berikut flow bagaimana proses dokumen arhctecture norht star.

the complete flow of the North Star document

List Pain and Dream yang dialami stakeholders, e.g., Customer, anggota tim, management, tim lain, sales, account manager, partners, dsb.
Define solusi ideal yang dapat menyelesasikan semua itu dengan berlandas pada fokus bisnis, dan keadaan system yang sudah ada
Analisis sistem, proses apa saja yang terdampak untuk menuju kondisi ideal tersebut.
Gunakan dokumen Architecture North star sebagai pedoman ketika develop fitur baru, atau refactor sistem yang sudah berjalan.
Ulang proses ini setiap ada variable yang tidak terduga, perubahan business goal, atau lain sebagainya yang menjadi blocker semua tim untuk mencapai Architecture North Star.

References

Diary #4 C4-Model pada Software Architecture

Iman Tumorang — Mon, 16 Jan 2023 02:30:59 GMT

Menjalani peran Software Architect ternyata tidak mudah. Tim, manajer, bahkan perusahaan berharap banyak dari seorang Software Architect, yang salah satunya adalah dapat memahami keseluruhan sistem, baik dari bird-view maupun dari sisi implementasi detail pada level koding.

Melakukan peralihan konteks dari high-level view ke tingkat detail terbukti sangat melelahkan. Semakin kompleks sistem yang ada pada perusahaan, maka semakin sukar untuk memahami keseluruhan secara detail. Jujur saja saya pun tidak yakin ada orang yang mampu memahami keseluruhan sistem dari high-level view sampai tingkat detail (koding) tanpa membaca dokumentasi. Jika pun ada, maka saya akan meragukan apakah ia manusia, atau alien?

Dongeng: Kisah Pilu Software Architect

Architect Calendar Schedule

Ini adalah kisah seorang Arsitek yang bekerja di sebuah perusahaan di Indonesia. Screenshot di atas menggambarkan salah satu kegiatan hariannya. Ada beberapa pola yang bersifat detail seperti RFC xxxx, Standup, dan lainnya. Selain itu, ia juga menghadiri beberapa rapat bersifat high-level view, seperti Decoupling xxxx, Risk xxx, Event Storming xxx, Domain Storytelling xxx, Centralizing xxx, dan lainnya.

Misalnya, ketika menghadiri rapat bertema Decoupling xxx, si arsitek harus memikirkan batasan domain antara dua atau tiga tim yang terlibat dalam proyek tersebut. Atau, ketika menghadiri rapat dengan pihak upper management, misal: Centralizing xxx, ia harus memikirkan rencana dan arah jangka panjang dari sistem yang diwakilkan, mempertanggung jawabkan north-star architecture yang akan dimiliki tim tersebut. Kemudian setelah selesai semua rapat high-level view, ia juga harus menghadiri rapat RFC sync bersama salah satu engineer.

Berikut cuplikan percakapan rapat mereka.

Iman Tumorang: Hi? Yes what can I help you?
John Snow: I can’t pull the Go private library, how to do it?
Iman Tumorang: Oh you can read this, and please make sure you have connected to our VPN
…
John Snow: Which repo should I implement this, and which queue runner? Which cron? etc..

Bisakah Anda membayangkan saat Anda sudah letih dengan banyaknya meeting dengan tema yang high-level view, kemudian secara drastis menerima pertanyaan yang bersifat sangat detail? Bagaimana cara Anda bisa dengan cepat melakukan peralihan konteks dan mengarahkan engineer terkait ke repositori dan kodingan yang tepat?

Contoh yang lain adalah, bayangkan ketika timmu kedatangan engineer baru, dan dia ingin memahami keseluruhan sistem yang timmu miliki dari end-to-end? Bagaimana cara kamu menjelaskannya dengan mudah?

Introducing C4 Model

Seorang gamer yang pernah bermain CounterStrike, atau PointBlank(PB) pasti familiar dengan C4. Tenang teman, C4 yang saya maksud disini bukanlah hal yang berbahaya seperti C4 pada game tersebut. C4 disini memang bisa meledak, tetapi meledak dari yang high-level menjadi kecil dan detail.

TLDR; C4 Model dari website ini https://c4model.com/
A set of hierarchical abstractions (software systems, containers, components, and code).
A set of hierarchical diagrams (system context, containers, components, and code).
Notation independent.

Untuk menyimpulkan, C4 Model adalah sekumpulan diagram yang menjelaskan keseluruhan sistem secara hierarki dari hulu ke hilir. Disebut dengan C4 karena terdapat 4C dalam C4 Model, yaitu Context, Container, Components dan Code. Jadi ke-4 C ini saling berketerkaitan dan berurutan. Dan jika disederhanakan dalam diagram mungkin seperti berikut.

C4 Model diagram

Dengan 4 level ini, akan sangat membantu setiap orang untuk dapat memahami sistem secara keseluruhan baik dari high-level sampai ke level detail. Tujuan dari C4 Model ini paling penting adalah discovery dan traceability. Kita dapat dengan mudah memahami sistem dari end-to-end bahkan sampai level kodingan.

Level 1: Context

Context from C4 Model

Context merupakan pintu masuk untuk melihat seluruh sistem yang dimiliki. Jika terdapat banyak entitas perusahaan, maka setiap entitas dapat disebut sebagai sebuah sistem. Sebagai contoh, Eccomerce, Payment, dll.

Pada level ini, cukup dengan memahami secara high-level view. Fokus yang harus dibicarakan adalah tentang bisnis atau stakeholder lainnya yang masih berada pada level high-level view.

Scope yang harus dipahami adalah Users, 3rd Parties (Partner), Blackbox System, Alur Bisnis, User Journey, dll.

Audience yang hadir ketika membahas level ini adalah semua stakeholders bisnis (Sales/Partner/Account Manager), Product (PM, UI/UX, QA), Architect, dan Developer. Jika salah satu audience tersebut hadir, maka kita cukup membahas dilevel Context saja, tidak perlu lebih mendetail.

Level 2: Container

Container from C4 Model

Saat kita melakukan zoom-in lebih detail dalam sebuah sistem dari Context (C-Level 1), kita akan menemukan Container. Container ini dapat dianalogikan seperti tim-tim yang ada di suatu organisasi, ataupun lebih tepatnya adalah aplikasi yang dimiliki oleh perusahaan tersebut yang merupakan masih bagian dari Context (C-teratas).

Container dapat berupa Microservice, Aplikasi (Web/Mobile/Desktop), Dashboard, dan lainnya.

Scope yang harus dipahami adalah semua scope dari C-sebelumnya (Context) ditambah dengan container/aplikasi yang merupakan bagian dari C-sebelumnya (Context).

Audience yang wajib hadir ketika membahas level ini adalah semua stakeholder Product (PM, UI/UX, QA), Architect, dan Developer. Di level ini para Business stakeholder sudah menjadi opsional dan tidak perlu tahu secara detail akan level ini.

Level 3: Component

Component from C4 Model

Saat kita telah berpindah ke container/aplikasi yang lebih spesifik, kita akan memperluas cakupan pemahaman kita terhadap aplikasi dengan melihat komponen-komponen didalamnya. Tergantung dari container tersebut, misalnya microservice, maka akan terdapat beberapa komponen seperti Cron, API server, Queue consumer, gRPC handler, dll.

Sementara jika container sebelumnya adalah aplikasi web maka kemungkinan komponen yang terdapat bisa berupa SPA, Frontend Gateway, dan lain-lain. Pada level ini kita akan melihat semua komponen yang terdapat pada container yang telah kita zoom-in dan menjelaskan arsitektur aplikasi secara internal.

Scope yang harus dipahami adalah semua scope dari container sebelumnya ditambah dengan komponen-komponen yang terdapat pada setiap container/aplikasi, seperti Cron, gRPC, SPA, Queue Consumer, dan lainnya.

Audience yang wajib hadir saat membahas level ini adalah semua stakeholder Arsitektur dan Developer. Business dan Product stakeholder sudah menjadi opsional dan tidak perlu tahu secara detail akan level ini.

Level 4: Code

Code from C4 Model

Setelah salah satu komponen dipilih, dengan melakukan zoom-in lagi, kita dapat menemukan kodingan dari komponen tersebut. Artifaknya dapat berupa tautan ke repository Git (Github/Bitbucket, dll), atau dokumentasi langsung ke UML/ERD/Class diagram, atau apapun yang menjelaskan tentang bentuk asli dari komponen tersebut.

Scope yang harus dipahami adalah bentuk wujud nyata dari sistem yang dibangun, misalnya kodingan, UML/ERD/Class diagram, dll.

Audience yang wajib hadir saat membahas level ini adalah semua stakeholder Arsitektur dan Developer.

Workshop: Sistem Informasi Absensi Karyawan

Mungkin untuk dapat mengenal lebih dekat dengan C4 Model, saya akan buat mini-workshop pemetaan sistem ke dalam C4 Model — dengan menggunakan IcePanel.io sebagai platform diagramnya.

The story:

Perusahaan Tumorang Happy Employee Inc adalah penyedia HRIS terdepan di dunia. Salah satu produk andalan mereka adalah fitur absensi karyawan, yang telah dipakai oleh jutaan perusahaan di seluruh dunia, termasuk Gugel, MateMeta, Macrohard, dan bahkan Mamazon juga menjadi salah satu klien mereka.
Mereka memiliki banyak Software Architect yang menangani sistem mereka secara keseluruhan, salah satunya adalah Jack. Jack sangat kompeten dan terlibat dalam banyak proyek, sehingga dia pun mulai merasa kewalahan dengan context switching yang kadang-kadang tidak bisa dihindari.
Untuk meningkatkan discoverability, traceability, serta mempermudah learning curve para engineer dalam memahami keseluruhan sistem, Jack pun memetakan keseluruhan sistem Tumorang Happy Employee menggunakan C4 Model.

Berikut pemetaan keseluruhan sistem yang dilakukan oleh Jack dalam bentu C4 Model.

Level 1: Context

Context: Tumorang Happy Employee Inc

Pada level 1 — Context, hanya terdapat 3 kotak umum, yaitu Employees, sistem Tumorang Happy Employee, dan 3rd Party (Email Platform). Di level ini, semua aktivitas inti yang dilakukan oleh user dapat dilistkan dalam bentuk panah. Namun, untuk mempermudah, maka hanya dibuat satu garis panah saja. Dengan asumsi bahwa semua aktivitas dari sisi client sudah tertutupi dengan satu arah panah.

Kemudian, Sistem absensi juga ternyata memiliki integrasi ke 3rd Parties, sehingga ditarik garis panah ke 3rd Party (Email platform). Terlepas dari semua aktivitas yang ada, dapat di asumsikan semua aktifitas ke 3rd Party hanya dalam satu garis panah.

Level 2: Container

Nah, saat si “Sistem Absensi” kita zoom-in, (tombol zoom), maka kita akan dapat melihat keseluruhan container/application yang ada di dalam Sistem Absensi.

Container: Tumorang Happy Employee Inc

Dapat dilihat, semua container yang ada pada sistem absensi. Disini sudah dapat kelihatan bentuk wujud dari struktur organisasi dari perusahaan tersebut. Seperti Mobile dan User dashboard terknoneksi langsung ke Auth Platform. Lalu terdapat juga koneksi ke 3rd Party melalui Notification platform.

Level 3: Component

Lalu kemudian, kita bisa zoom lagi setiap Container. Contoh kita zoom-in lagi si Notification platform.

Component: Tumorang Happy Employee Inc.

Disini kita akan menemukan beberapa komponen yang ada di Notification Platform, seperti HTTP Server, gRPC server, dan Queue consumers.

Level 4: Code

Yang terakhir adalah codingan, untuk level ini, kita hanya tinggal membuat link referensi ke Github repository. Jika menggunakan platform IcePanel, maka akan terlihat seperti ini.

Code: Tumorang Happy Employee Inc.

Disini kita sudah memetakan keseluruhan sistem dengan C4 model dengan bantuan IcePanel tentunya. Berikut detail diagramnya di Icepanel untuk lebih detail

Kesimpulan

Jika dibuat dalam diagram secara keseluruhan, maka berikutlah penjabaran C4 model.

C4 Model in one diagram

*klik gambar untuk lebih detail

Jika kita kembali ke dongeng #1 di atas, C4 Model dapat membantu si Architect untuk melakukan zoom-in dan zoom-out secara praktis. Pada pagi hari ia melakukan meeting dengan tim A tentang high-level view dan aligment (C-Level 2). Siang harinya, ia bertemu dengan engineer X untuk membahas implementasi RFC (C-Level 3 & 4). Sang Architect dapat dengan mudah memahami konteks dengan cepat hanya dengan memanfaatkan C4 Model yang dimilikinya.

Namun, untuk sampai ke tahap itu akan memerlukan waktu yang lama karena membutuhkan dedikasi semua Architect untuk memetakan keseluruhan sistem mereka ke dalam C4 Model. Apabila C4 Model sudah solid, maka siapa pun pasti akan sangat terbantu untuk memahami sistem secara keseluruhan.

Untuk toolsnya sendiri, saya tidak ada rekomendasi. Namun untuk blogpost ini, saya menggunakan IcePanel. Selain IcePanel, kamu juga dapat menggunakan tools diagram lainnya, seperti, Structurizr, C4-PlantUML, atau yang lebih hard-core dapat menggunakan Draw.io, Excalidraw, dsb.

Demikian tulisan ini saya simpulkan, semoga berguna bagi yang membutuhkan.

Reference

Link untuk Excalidraw untuk dapat melihat diagram saya diatas.
Link untuk IcePanel untuk Miniworkshop diatas
https://c4model.com/

Diary #3 ADR (Architecture Decision Record) pada Software Architecture

Iman Tumorang — Mon, 11 Jul 2022 02:27:09 GMT

Hey semua, kembali lagi dengan saya, Iman Tumorang di series diary saya sendiri di SoftwareArchitect.ID.

Buat teman yang baru melihat tulisan saya ini, sedikit konteks, dari awal tahun 2022, saya memulai suatu inisiatif sendiri untuk membuat tulisan ataupun diari saya pribadi terkait software architecture dan kehidupan saya sebagai (aspiring) software architect.

Kali ini di tulisan ini, saya ingin menulis sedikit tentang Arhictecture Decision Record (ADR) ketika membuat keputusan software architecture. ADR sudah pernah saya singgung di diary#2 sebelumnya. Namun di diary#2 saya hanya menjelaskan sekilas bentuk dari ADR seperti apa. Nah, di tulisan ini saya akan menjelaskan lebih detail bentuk dari ADR yang lumayan sering digunakan orang, atau setidaknya, yang saya gunakan dipekerjaan saya.

Apa Itu Architecture Decision Record (ADR)?

Sebelum masuk ke Architecture Decision Record, kita perlu tahu apa itu Architectural Decision?

Pada Wikipedia, kita dapat menemukan bahwa Architectural Decision adalah,

are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.

Merupakan keputusan terhadap requirement arsitektur yang signifikan atau yang bersifat susah untuk dibuat ataupun diubah. Dimana jika dilakukan pengubahan akan berdampak pada cost pengembangan sistem.

Pada tulisannya di Documenting Architecture Decisions, Michael Nygard menyatakan bahwa mereka menyimpan koleksi records arsitektur yang signifikan yang dapat mempengaruhi struktur, non-fungsional, karakteristik, dependencies, interfaces dan teknik yang digunakan pada pengembangan sistem.

Dari kedua penjelasan tersebut dapat kita artikan, bahwa pentingnya untuk meyimpan keputusan-keputusan yang pernah dilakukan ketika membangun sistem, khususnya semua keputusan yang signifikan secara arsitektur.

Mungkin sebagai contoh, saya bisa sebutkan.

Suatu hari diperusahaan Tumorang Finance yang merupakan perusahaan Digital Insurance terkini. Tumorang Finance hendak melakukan expansi ke Indonesia, sehingga hal yang utama dalam expansi ini adalah integrasi dengan pembayaran versi lokal yang ada di Indonesia. Singkat cerita, Tumorang Finance akan integrasi dengan sebuah Payment Gateway, sebut saja Xendit.
Lalu sistem pun didesign sedemikian rupa, hingga disuatu titik, John Snow selaku Software Architect di Tumorang Finance berdebat dengan tim engineer terkait pemilihan teknologi yang akan digunakan. Tim Engineer ingin menggunakan RabbitMQ, lalu John Snow selaku software architect memilih untuk menggunakan SQS sebagai message queueing platform yang akan di gunakan ketika melakukan payment request ke Xendit (Payment Gateway).
Debat panjang pun dilakukan, hingga pada suatu titik, mereka pun menemukan titik terang dan setuju akan menggunakan RabbitMQ.

Dari contoh diatas, keputusan memilih RabbitMQ dan SQS akan berpengaruh pada struktur dan dependencies sistem yang akan dibangun. Jika menggunakan SQS, maka secara otomatis mereka pun harus menggunakan AWS Cloud provider. Jika menggunakan RabbitMQ maka mereka bisa saja menggunakan self-hosted, ataupun memakai vendor lainnya.

Nah keputusan yang mereka pilih ini akan disimpan dalam record bisa berbentuk Google docs, Atlasian Confluence, Markdown di Github, dsb. Nah record inilah disebut dengan Architecture Decision Record.

Sehingga dengan perkembangan tim dan perusahaan, orang-orang didalam pasti datang dan pergi. Orang lama mungkin akan resign, orang baru akan join. Sehingga jika suatu saat dikemudian hari orang-orang baru yang join dapat mengerti kenapa keputusan dilakukan. Mengapa tim terdahulu memilih RabbitMQ daripada SQS?

Komponen ADR

Untuk menulis ADR sendiri sudah banyak contoh di Internet. Ada beberapa resource yang mungkin berguna untuk kita ikutin. Namun disini saya akan coba jelaskan kembali dengan bahasa saya sendiri.

ADR components

Jika kita lihat gambar diatas, terdapat beberapa komponen penting pada ADR. Jika pun banyak versi ADR yang ada di internet, namun ke 5 komponen tersebut adalah komponen paling penting ketika membuat ADR.

1. Title

Komponen pertama yang sangat penting adalah Title. Ini akan menjadi identifier dari ADR yang akan kita buat. Formatnya bebas, namun yang wajib kita ketahui, harus memiliki nomor, lalu diikuti dengan judul utama dari ADR tersebut.

Contoh:

ADR 1: Using RabbitMQ over SQS
atau
1. Using RabbitMQ over SQS

Nomor ini berguna untuk urutan dan referensi nantinya yang akan saya jelaskan nanti di akhir tulisan ini.

2. Status

Komponen ini menyatakan status ADR yang telah ditulis. Biasanya tahapannya dimulai dari “proposed” ketika ADR tersebut masih menunggu approval dari semua stakeholders yang terlibat. Lalu diubah menjadi “accepted” ketika semua stakeholders setuju. Dan jika dikemudian hari seiring dengan perkembangan bisnis, keputusan tersebut tidak relevan lagi, maka statusnya akan diubah menjadi “deprecated” atau “superseded by ” jika terdapat ADR baru yang menjadi pengganti ADR yang sudah usang tersebut.

3. Context

Komponen ini menjelaskan latar belakang dari mengapa ADR tersebut hadir. Biasanya pada komponen ini sifatnya netral dan hanya menjelaskan fakta yang ada terkait sebuah masalah. Bisa juga pada komponen ini, kita memberikan opsi pilihan yang ada, (contoh: opsi 1: menggunakan Golang, opsi 2: menggunakan JavaScript).

4. Decision

Komponen ini menjelaskan keputusan yang telah disepakati oleh semua stakeholders yang terlibat. Disini akan dijelaskan semua alasan mengapa keputusan tersebut diambil. Yang akan menjawab semua pertanyaan “Why ….” pada design arsitektur yang telah dibuat.

Dan ketika menulis decission harus ditulis dengan kalimat aktif, “We will …” menyatakan bahwa secara konsensus semua stakeholders akan memilih decision yang ada pada ADR tersebut. Bukan “I will …” atau “The CTO will …” karna ini bersifat individual decission bukan keputusan secara bersama yang disepakati.

5. Consequences

Komponen ini akan menjelaskan semua effect negative atau drawback/tradeoffs dari keputusan yang diambil. Sehingga semua stakholders sadar bahwa keputusan yang telah disepakati ternyata memiliki tradeoffs yang harus disiasati.

Menulis ADR

Pada bagian diatas saya sudah menjelaskan sedikit tentang ADR dan komponen-komponen yang terdapat pada ADR.

Untuk latihan, saya akan coba buat contoh penulisan ADR.

Studi kasusnya dapat kita gunakan contoh kasus yang ada diatas yang ada pada Tumorang Finance.

Nah dari studi kasus tersebut, maka jika saya buatkan ADRnya, kira-kira akan berbentuk seperti ini.

Notes: hanya contoh ya!

Lalu kemudian, Tumorang Finance pun berhasil ekspansi ke Indonesia. Banyak client mendaftar dan menjadi aktif member dari digital insurance yang ditawarkan Tumorang Finance.

Lalu, 2 tahun berlalu, ternyata tim infra pun mulai kewalahan memantain RabbitMQ yang mereka host sendiri. Sehingga mulai muncul percikan-percikan issue karena RabbitMQ down yang kini menjadi bottleneck perusahaan untuk growing lebih aggresive.

John Snow, selaku architect di Tumorang Finance, melihat ini sebagai momen untuk mencoba solve masalah ini. Singkat cerita, setelah diskusi dan meeting dengan semua stakeholders yang terlibat, disimpulkan terdapat 2 pilihan.

Use managed RabbitMQ vendors (eg. CloudAmqp.com)
Migrate to Google Pubsub

Maka John Snow pun membuat ADR baru dengan status “proposed” berikut.

Proposed:

Nah selanjutnya ADR tersebut pun akan didiskusikan ke semua stakeholders yang terlibat, CTO, Engineers, Infrastructure, dsb.

Nah semisal singkat cerita ADR tersebut disetujui oleh semua pihak, maka status ADR tersebut akan berubah menjadi “accepted”, sementara ADR yang lama, yang sebelumnya untuk memilih RabbitMQ akan menjadi status “superseded”.

Accepted and Superseded

Nah setelah ini selanjutnya adalah melanjutkan proses design dan development yang akan mengikuti ADR yang telah disepakati.

Conclusion

Dari tulisan ini saya menjelaskan sedikit gambaran tentang ADR, dimana terdapat 5 komponen penting yaitu, Title, Status, Context, Decision, dan Consequences. Ke 5 komponen ini wajib ada ketika pembuatan ADR.

Kita juga bisa lebih kreatif menambah komponen lainnya seperti date, atau tagging (hastag) untuk memudahkan pencarian/filter ADR. Karena ADR ini haruslah mudah untuk diakses, baik secara searching maupun secara kategorisasi dan tagging.

Platform yang dapat digunakan ada banyak beragam, dapat menggunakan Google Docs, Atlassian Confluence, Notion, atau bahkan Markdown di Git (Github/Gitlab/Bitbucket).

Diary#2: Struktur dan Aspek Penting dalam Software Architecture

Iman Tumorang — Mon, 13 Jun 2022 02:25:12 GMT

Hey semua! Saya Iman Tumorang, kembali menulis disini sebagai diary saya sebagai (Aspiring) Software Architect.

Sebulan yang lalu di Diary#1, saya baru publish tentang ekspektasi yang diharapkan dari seorang software architect. Selanjutnya saya akan tulis tentang hal-hal penting yang harus seorang Software Architect ketahui ketika mendesign system architecture dari aplikasi yang dia kerjakan di tulisan ini.

Tulisan ini sudah lama saya draft, namun saya baru ada waktu untuk menulis ulang saat ini. Namun demikian, seharusnya konteksnya masih sama.

Suatu hari, sebut saja Iman Tumorang, lagi mengikuti pertemuan forum para Software Architect, sebut saja di salah satu komunitas di Indonesia. Dimana di forum tersebut, para Software Architects lainnya saling berdiskusi dan bertukar pandangan terkait software architecture mereka.

Lalu, salah seorang peserta pun bertanya kepada Iman,

“Hey Iman, boleh ceritakan sedikit tentang software architecture yang kalian gunakan?”

“Yeah, tentu saja. Kami menggunakan Microservice” jawab Iman.

“lalu..?” balas si penanya lagi.

“Lalu? Ya begitu, kami menggunakan microservice, terdapat beberapa services, API gateway, databases dsb” balas Iman mulai kebingungan. Karena normalnya ketika orang ditanya tentang software architecture, biasanya jawabannya pasti seputaran, Monolith, Microservice, Event Driven Architecure dan sebagainya. Tetapi si penanya malah bertanya lebih lagi, hal ini membuat Iman mulai kebingungan.

Ternyata banyak aspek yang perlu diketahui ketika berbicara tentang software architecture. Hal tersebut akan saya bahas selanjutnya dibawah. Ini juga hal yang baru saya pahami. Sehingga blog post ini juga saya gunakan sebagai catatan pribadi untuk referensi dimasa depan.

Aspek Struktur Penting dalam Software Architecture

Suatu hal yang baru saya pelajarin adalah ternyata software Architecture itu terdiri dari 4 dimensi dan ketika membuat software architecture design, maka kita harus membuat ke 4 aspek dimensi struktur software architecture tersebut, yakni

Menentukan Karakteristik dari architecture kita
Menentukan Komponen-komponen yang saling berinteraksi di architecture kita
Memilih Styles dari architecture yang akan kita gunakan.
Dan membuat Architecture Decision yang akan menjadi bahan acuan saat pengembangan sistem.

Ke 4 dimensi tersebut haruslah sangat penting di definisikan saat membicarakan tentang software architecture. Saya akan coba jelaskan dengan bahasa saya sendiri, agar mungkin lebih mudah di pahami.

1. Menentukan Karakteristik Software Architecture

Hal yang penting saat mendefinisikan architecture design kita adalah menentukan karakteristik software architecture yang kita inginkan baik eksplisit atau secara implisit.

Yang dimaksud dengan karakteristik disini adalah kualitas yang ingin dicapai dari software architecture yang kita design. Untuk kualitas itu sendiri tidak terbatas, namun demikian, sudah ada standard ISO yang bisa kita gunakan sebagai acuan dari karakteristik system kita contohnya dapat dilihat pada gambar dibawah.

software product quality by ISO25000.com

Atau untuk lebih banyak opsi, berikut beberapa contoh dari wikipedia.

system quality attributes

Nah, ketika membuat design architecture, maka kita harus menentukan ke -ibility-an dari system yang akan kita bangun. Karakteristik yang paling umum biasanya antara lain, reliability, scalability, availability, security, performance, elasticity dsb.

Karakteristik ini akan berguna untuk menjadi acuan keputusan yang akan kita lakukan terhadap system kita. Misal, karakteristik yang saya pilih adalah scalability, maka ketika men-design software architecture, scalability harus menjadi hal pertama yang saya pertimbangkan, misal ketika memilih REST vs Event-based protocol, maka saya harus kedepankan opsi yang lebih scalable, lalu saya pun memilih Event-based protocol (misalnya). Atau jika karakteristik yang saya pilih feasibility, mungkin karena projectnya harus selesai dalam 2 bulan, maka hanya butuh MVP dan tidak perlu terlalu canggih, maka saya akan memilih REST.

Semua karakteristik bisa saja berkorelasi, atau pun bertentangan. Apapun itu akan mempengaruhi keputusan kita ketika membuat design architecture dari sistem yang akan kita bangun.

2. Menentukan Komponen Software Architecture

Setelah menentukan Karakteristik software architecture yang akan di design, selanjutnya adalah kita pun dapat mulai menentukan komponen-komponen system yang akan kita kembangkan.

Komponen-komponen ini nantinya menggambarkan hal hal penting yang ada di keseluruhan sistem yang akan dikembangkan. Saat menentukan komponen-komponen system kita, kita tidak harus terpaut pada style seperti Monolith, atau Microservice, Event Driven dsb. Hanya benar benar murni komponen, seperti layangnya building block yang nantinya dapat kita bongkar pasang membentuk satu kesatuan sistem yang utuh.

Untuk sebuah contoh, saya akan berikan satu simulasi kecil. Sebut saja sebuah perusahaan Tumorang Finance, bergerak dibidang digital insurance, sistemnya sudah berjalan. Namun mereka ada kegundahan, mereka hendak memberikan pelayanan lebih baik ke user mereka untuk membuatkan sistem notifikasi ke user mereka. Notifikasi ini nanti akan dipergunakan untuk berbagai macam usecase, misal untuk reminder pembayaran premi asuransi, notifikasi pembayaran yang sudah berhasil, dan notifikasi OTP untuk login. Dan sistem notifikasi yang diharapkan dapat menyimpan status notifikasi yang dikirim, apakah sudah dikirim, gagal terkirim atau mungkin delay.

Dari studi kasus diatas, kita dapat ekstrak komponen yang mungkin ada di sistem yang ingin mereka harapkan.

Nah dari komponen-komponen tersebut, kita pun dapat melihat dengan jelas apa saja yang harus kita lakukan. Jika ternyata kita memilih untuk monolith, maka setiap komponen tersebut bisa kita buat jadi per module. Atau jika kita memilih membangun distributed system, maka setiap komponen bisa saja menjadi service tersendiri.

3. Memilih Styles Software Architecture

Kemudian, setelah kita menentukan karakteristik, lalu komponen komponen dari software architecture kita, langkah selanjutnya adalah menentukan Styles dari software architecture kita.

Terdapat banyak styles dari software architecture yang dapat kita gunakan. Semua styles tersebut bukan lah binary option, melainkan multiple options. Sehingga kita dapat memilih gabungan beberapa styles untuk software architecture pada system kita.

Untuk klasifikasinya, terdiri dari 2 jenis klasifikasi, dimana kedua klasifikasi ini juga terbagi ke beberapa jenis lagi, sebagai berikut.

Monolithic
- Layered Architecture
- Modular Monolith
- Microkernel Architecture
- Pipeline Architecture
Distributed
- Microservice Architecture
- Service-Based Architecture
- Event-Driven Architecture
- Space-Based Architecture

Ketika pertama kali ditanya tentang styles software architecture, saya sangatlah kebingungan. Hingga saat Mark Richards (author Fundamentals of Software Architecture) menyebutkan jenis-jenis styles software architeture seperti, Microservice, Monolith, Service Based, Event Driven Architecture dsb *yang saya sebutkan diatas.

Awalnya saya menyebut hal tersebut adalah software architecture pattern, namun surprisingly, Mark Richards, menjelaskan hal-hal yang tergolong pada pattern pada software architecture antara lain, Circuit Breaker Pattern, Event Forwarded Pattern, Command and Query Responsibility Segregation (CQRS) pattern, Backend For Frontend (BFF) Pattern dsb.

Kembali ke aspek software architecture, setelah kita membuat list komponen yang terdapat pada sistem kita (step sebelumnya), kita pun harus menentukan style software architecture yang ingin kita terapkan. Ketika menentukan styles, kita bisa mengombinasikan banyak styles sesuai keinginan. Contoh, karena systemnya hanya kecil misal hanya CMS saja, maka Layered Architecture style sudah cukup untuk digunakan. Atau sistemnya sangat kompleks, terdapat banyak domain yang tidak mungkin dijadikan dalam satu aplikasi monolith, maka kita dapat memilih Microservice architecture lalu dengan kombinasi Event Driven architecture. Tidak ada keharusan hanya boleh memilih satu, kita bisa kombinasikan per-setiap klasifikasinya (monolith ataupun distributed).

4. Membuat Architecture Decision

Tahap terakhir dari aspek software architecture adalah membuat architecture decision yang menjadi bahan acuan untuk semua tim terlibat ketika mengembangkan sistem.

Decision bisa dilakukan secara konsensus (suara terbanyak), atau pun dilakukan secara individual (Software Architect). Namun untuk setiap keputusan itu, haruslah disimpan dalam bentuk dokumen yang dapat dibaca oleh semua orang.

Beberapa komponen penting yang perlu diperhatikan dalam membuat architecture decision antara lain:

1. Diagram yang jelas dan granular, tidak ada singkatan-singkatan yang tidak jelas.

Sebagai contoh, coba kamu bandingkan ke 2 diagram dibawah.

Diagram manakah yang lebih mudah untuk dipahami? Tentu saja, orang normal akan memilih diagram ke 2. Sehingga siapapun yang akan membaca ini, akan memahami sistem yang akan di kembangkan.

Untuk menggambarkan diagram architecture tidak ada keharusan styles dan teknik yang khusus. Kita dapat menggambarkan dengan gaya/bahasa kita, selama itu jelas dan mudah dimengerti. Namun, terdapat juga beberapa model yang banyak digunakan orang (para experts) lainnya, yaitu:

C4 Model (by Simon Brown)
ArchiMate (by The Open Group)

Kita dapat mengikuti ke 2 model tersebut. Keduanya sama-sama akan membantu menjelaskan tentang system design dari architecture kita secara terstruktur.

2. Menghindari Anti-Pattern saat membuat Architecture Decision

Saat membuat Architecture Decision, maka akan terdapat banyak diskusi dan meeting untuk mencapai keputusan yang ideal terhadap architecture yang kita pilih. Semua orang akan terlibat, kapan saja waktu yang kosong, dimana saja, pasti orang akan berfokus pada decision tersebut. Berikut anti-pattern yang harus dihindari ketika membuat keputusan.

Groundhog day anti-pattern
Ini terjadi ketika tidak ada yang mengerti mengapa suatu decision dibuat, sehingga para stakeholders dan software architects tetap meeting membahas hal yang sama secara berulang ulang. Misal, suatu flow sudah ditentukan bahwa sistem akan menggunakan Event Driven. Lalu 2 minggu kemudian, engineer pun bertanya lagi, “kenapa Event Driven, kenapa tidak REST api call saja secara sync?” Dan kembali pun mereka meeting diskusi membahas hal yang sama seperti sebelumnya.
Slack (Email, or any communication platform) Driven Architecture
Ini terjadi misal ketika development sudah berjalan, tim engineer bertanya tentang misal, “Should we use RabbitMQ over SQS? Because of this reasons…. and this tradeoffs …” kepada Software Architect melalui chat di Slack. Diskusi ini terjadi secara improptu melalui aplikasi chating/communication platform lainnya.

Apapun hasil dari diskusi mereka di Slack chat tersebut pasti akan ter-telan dengan banyaknya chat dikemudian hari. Sehingga, jika suatu saat engineer baru join dan melihat project tersebut dan bertanya ke tim, “Why we use RabbitMQ over SQS?” maka tim tersebut akan kewalahan. Karena keputusan itu dilakukan lewat chat, tanpa meeting dan tidak ada record menyatakan alasan kenapa keputusan itu dilakukan.

Kedua anti-pattern ini biasanya akan membuat pengembangan sistem terbengkalai dan mungkin dapat berimpact membuat timeline pengerjaan project ke-delay menjadi lebih lama.

3. Membuat Architecture Decision Record (ADR)

Untuk menghindari anti-pattern tersebut diatas, maka seorang Software Architect, harus membuat Architecture Decission Record. Yang akan menjelaskan the “WHY?” pada setiap keputusan yang telah disepakati.
“Kenapa keputusan itu dilakukan?”.
“Kenapa pakai RabbitMQ dan tidak SQS?”
“Kenapa MongoDB, kenapa tidak PostgreSQL?”
Dan banyak lagi pertanyaan yang akan muncul dikemudian hari.

Segala alasan dan jawab pertanyaan itu haruslah disimpan dalam record. Record yang menjelaskan mengapa sebuah keputusan diambil. Dan semua record ini haruslah mudah untuk diakses oleh semua orang yang berekemptingan, dalam hal ini para engineers. Sehingga jika dilain waktu, terdapat engineer yang baru bergabung dengan tim tersebut, mereka dapat membaca semua records decission yang sudah dilakukan tim tersebut.

Berikut contoh template ADR yang lumayan sering digunakan.

Terdapat

Title: Judul decision
Status: status decision di repository decision records (biasanya proposed, accepted, superseds, superseded) dsb.
Context: menjelaskan kenapa decission ini ada? latar belakang dari decision ini muncul.
Decision: menjelaskan “decision” yang diambil dan disetujui oleh semua stakeholers. Disini juga harus menjelaskan kenapa keputusan itu dipilih. Point ini sangat penting, karena ini akan menjadi landasan para stakeholders, dan new hire untuk mengerti mengapa keputusan tersebut diambil.
Consequences: menjelaskan tradeoff yang akan terjadi. Dampak negative yang akan terjadi jika keputusan ini dilakukan. Ini penting agar pembaca aware tentang konsekuensi yang akan terjadi, sehingga mereka tahu untuk mengantisipasi apa yang tertera pada list konsekuensinya.

Misal untuk contoh diatas, adalah ADR untuk memilih RabbitMQ dibanding SQS. Sehingga jika suatu saat dikemudian hari, engineer baru datang dan bertanya tentang alasan mengapa memilih RabbitMQ daripada SQS, kita tinggal memberikan record ini.

Dan perlu diketahui juga, apapun keputusan yang dilakukan pada ADR, tidak ada salah atau pun benar. Mungkin saat keputusan itu dibuat, semua setuju dan merupakan keputusan terbaik pada masanya. Lalu 2 tahun kemudian, seiring berkembangnya teknologi dan bisnis, keputusan tersebut tidak relevant lagi. Sehingga tim terlibat dapat melakukan architecture design review lagi, dan memuat ADR yang baru.

Nah selanjutnya adalah mengulang semua step ini setiap kali hendak membuat design software architecture dari sistem yang akan kita kembangkan.

Conclusion

Di artikel ini saya telah menjelaskan aspek penting yang perlu diperhatikan ketika membuat design software architecuture yakni, pertama kita harus menentukan karakteristik software architecture kita, lalu kemudian membuat list komponen dari keseluruhan sistem kita, dan selanjutnya memilih styles yang sesuai dengan kasus dan karakteristik yang kita pilih, dan terakhir membuat architecture decission yang menjadi acuan untuk setiap stakeholders dari architecture yang kita design.

Ke 4 aspek ini sangat lah penting, saya pun baru menyadarinya, karna selama ini saya ketika ditanya tentang software architecture yang saya gunakan, saya hanya jawab “microservice” saja. Saya tidak menjelaskan tentang karakteristiknya, lalu stylesnya ataupun the “WHY”nya yang tidak jelas dalam decision. Jawaban yang paling umum saya berikan adalah, “Why? Enggak tahu, ini sudah seperti ini dari dulu sudah legacy, jadi kami tinggal ikutin dan improve” Ini merupakan jawaban yang buruk ketika menjelaskan software architecure. Pasti ada alasan disetiap keputusan yang dibuat.

Dan saya juga berencana akan mulai mengasah ini dan menjadikannya kebiasaan ketika melakukan design review terhadap software architecture sistem yang akan saya kembangkan.

Demikian tulisan ini saya rangkumkan berdasarkan apa yang baru saya pelajarin dari Mark Richards (author Fundamentals of Software Architecture). Semoga berguna kepada yang membaca khususnya teman teman software engineer yang ingin menempuh jalur software architect.

Diary #1: A Glimpse of how to Striving to be A Full-Fledged Software Architect

Iman Tumorang — Mon, 09 May 2022 02:27:36 GMT

Hey semua! Saya Iman Tumorang, kembali menulis disini sebagai diary saya sebagai (Aspiring) Software Architect.

Beberapa bulan terakhir, saya sangat dipadatkan banyaknya pekerjaan dari tempat saya bekerja. Namun, meskipun demikian saya masih mencoba untuk menuangkan ide-ide kecil dan draft (meski pada akhirnya lebih banyak draft haha).

Saya mungkin sedikit sibuk, namun sebisa saya, saya akan publish coret-coretan, curhat, ide, dan hal-hal yang saya pelajari khususnya tentang software architecutre dan kehidupan software architect di website ini.

Untuk itu, jika kamu tidak ingin ketinggalan konten yang akan saya publish, kamu dapat subscribe langsung dengan mencantumkan email kamu. Sehingga setiap saya publish cerita baru, kamu akan langsung mendapat notifnya secara langsung di kotak email kamu.

Beberapa hari terakhir, saya baru belajar sedikit tentang Software Architect. Karna hal tersebut, saya pun menulis ini bertujuan agar saya tidak lupa dengan apa yang telah saya pelajari + mungkin bisa berguna kepada orang lain juga.

Nah di catatan kali ini, saya akan membahas tentang ekspektasi yang diharapkan dari seorang Software Architect, atau setidaknya berdasarkan dari hal yang saya pelajari beberapa minggu belakangan ini.

Sebagai konteks, saya baru saja belajar tentang Software Architect, dari Mark Richards, merupakan penulis buku dari Fundamentals of Software Architecture: An Engineering Approach dan Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures

Beliau menyatakan, terdapat beberapa ekspektasi yang diharapkan dari seorang Software Architect, yang dimana setelah mendengarkan hal tersebut, saya pun semakin terbuka dan ~~terbebani~~ termotivasi dengan role yang saya emban saat ini.

Adapun ekspektasi yang diharapkan adalah sebagai berikut,

Menentukan keputusan terkait Architecture dan Design Principles
Menganalisa dan meningkatkan ekosistem teknologi yang dipakai di perusahaan secara berkelanjutan
Menganalisa tren teknologi yang terbaru yang ada dipasaran dan tetap update dengan tren tersebut.
Memastikan semua tim yang terlibat mengikuti rule/prinsip architecture yang telah disepakati
Memiliki pengetahuan dengan beragam jenis teknologi tidak terbatas pada platforms, programming language, dan sebagainya
Memiliki pengetahuan yang cukup dengan domain bisnis perusahaan
Memiliki skill interpersonal yang baik, termasuk pada kerja-sama, negoisasi, fasilitator dan sebagainya
Mengetahaui iklim politik yang ada dan harus mampu menjadi navigator iklim tersebut.

Ya demikianlah list ekspektasi yang diharapkan dari seorang Software Architect menurut Mark Richards. Saya akan coba jelaskan maksud dari hal tersebut secara detail dengan bahasa saya sendiri. Saya tidak akan menjelaskan semua, karna menurut saya beberapa point tersebut masih saling bersinggungan.

Dari beberapa point diatas, dapat saya simpulkan beberapa hal yang diharapkan dari seorang software architects, yang akan saya jelaskan berikut.

1. Menjadi Pawang Architecture Decision dan Design Principles

software architect thinking all the possible way

Berbicara tentang “pawang”, kita mungkin sudah cukup familiar. Beberapa minggu yang lalu, pawang hujan lumayan terkenal karena aksinya di sirkuit Mandalika, Lombok. Pawang dapat diartikan sebagai orang yang memiliki keahlian terhadap suatu bidang. Orang yang memiliki kontrol terhadap flow dibidang tersebut. Pawang hujan juga dapat diartikan sebagai orang yang mengontrol flow-nya hujan.

Demikian juga seorang Software Architect, mereka diharapkan mampu menjadi pawang, driver, dan pemandu kepada semua orang terhadap kebutuhan arsitektur sistem yang ada.

Dimulai dari mendefinisikan solusi yang disepakati, desain arsitektur, design principles, dan rule-rule lainnya terkait dengan Software Architecture.

Maka untuk itu, seorang Software Architect diharapkan mampu membuat sebuah keputusan yang akan menjadi acuan atau dasar terhadap software developer dan stakeholders lainnya. Keputusan yang dibuat tentu saja tidak melulu dari si Software Architect sendiri, bisa saja dari tim secara konsensus. Namun, sebagai Software Architect, dia/mereka harus menjadi driver dan rule enforcer saat keputusan itu disepakati oleh setiap tim. Dalam artian menjadi pawangnya arsitektur dan principle di semua tim yang terlibat.

2. Menganalisa dan Meningkatkan System di Perusahaan Secara Terus Menerus Mejadi Lebih Baik

Suatu hari, sebut saja si John Snow. Merupakan seorang Software Architect di perusahaan Tumorang Finance. Tumorang Finance merupakan perusahaan bonafit dan multinasional di bidang Digital Insurance. Saat ini Tumorang Finance, sedang gencar-gencarnya ekspansi ke multinasional dan sedang mencoba memasuki pasarnya Indonesia

Karena beberapa constraint, ekspansi ke tiap negara mungkin berbeda-beda secara sistem dan aplikasi, sehingga John Snow sebagai Software Architect di Tumorang Finance diharapkan membuat desain arsitektur untuk sistem Tumorang Finance di Indonesia.

Lalu singakat cerita, John Snow pun berhasil membuat semua design principles dan desain arsitektur untuk sistem Tumorang Finance yang baru di Indonesia. Lalu kemudian saat sistem tersebut dijalankan, sistem itu berjalan dengan baik. Atas kinerja John Snow, semua pihak senang, pihak executive senang karena bisnis Tumorang Finance berhasil berjalan dengan baik di Indonesia, tim product, sales, marketing, dan bahkan engineer juga senang , semua orang yang terlibat senang.

Lalu John Snow pun ditarik dari medan perang, dan di assign dengan projek baru lainnya di Tumorang Finance. Dan John Snow pun melupakan semua keputusan arsitektur dan desain serta principles yang pernah dia buat sebelumnya untuk sistem tersebut.

Ini bukanlah hal yang baik. Seharusnya seorang Software Architect, bertanggung jawab terhadap sistem yang dia buat. Bisnis mungkin bisa berubah (pivot) seiring waktu berjalan, atau compliance dan regulasi di Indonesia mungkin berubah. Sehingga arsitektur pun harus berubah mengikuti permintaan bisnis atau regulasi yang berjalan. Sehingga jika Software Architect langsung lepas tangan terhadap perubahan(pivot) tersebut, maka desain dan keputusan arsitektur serta principles yang pernah dia buat akan menjadi blocker dan bottleneck untuk perkembangan bisnis.

Dari sini, dapat disimpulkan, Software Architect harus terus menganalisa proses serta mengembangkan proses ataupun sistem pada perusahaan (product/bisnis unit) yang dia kerjakan. Tidak hanya proses, bahkan mungkin teknologi yang mereka pakai juga akan menjadi usang atau tidak relevan sesuai kebutuhan bisnis lagi, maka si Software Architect harus tetap memperbaharui desain dan keputusan arsitektur serta principles yang dia buat terhadap sistem tersebut.

3. Update dengan Trend Teknologi, dan Tetap Belajar Terhadap Ekosistem Teknologi di Pasaran

programming language from mycplus.com

Seorang Software Architect, diharapkan terbuka dan update dengan teknologi yang ada dipasaran. Tidak harus spesifik terhadap suatu brand, namun setidaknya mengetahui fungsi yang ditawarkan oleh brand-brand tersebut di pasaran. Contohnya, Messaging Queue, merupakan sebuah platform yang menawarkan fungsi untuk menangani antrian request/messages dalam skala besar. Brand yang tersedia dipasaran mungkin banyak, seperti RabbitMQ, SQS, NSQ, dan sebagainya. Cara penggunaan semua brand tersebut pun berbeda satu sama lain. Kita tidak perlu mengetahui semua cara menggunakan brand tersebut, namun satu hal yang pasti, kita tahu bahwa semua brand tersebut menawarkan fungsi yang hampir mirip untuk menangani antrian request/messages dalam sekala besar.

Software architect (tidak) harus menjadi ekspert di brand platform tersebut, namun memiliki pengetahuan dasar yang cukup membuat Software Architect dapat menggunakannya pada kebutuhan sistem yang akan dirancang dan dibangun nantinya.

Untuk mengikuti tren dan tetap belajar, ada 2 istilah yang perlu kita pahami. Yakni Technical Depth dan Technical Breadth. Keduanya ini akan sangat penting sebagai tolak ukur kita untuk memilih hal apa yang perlu dipelajari, dan sejauh apa hal tersebut dipelajari. Apakah hanya sekedar kulit-kulitnya saja, atau sampai sedetail mungkin sampai corenya?

Technical Depth dan Technical Breadth

Pada gambar diatas terdapat 3 lapisan penting.

stuff you know
Merupakan hal yang kita kuasai secara mendalam, yang dimana kita percaya diri ketika ditanya atau melakukan hal tersebut. Misal, membangun REST API dengan mengunakan JavaScript
stuff you know you don’t know
Merupakan hal yang kita sadari, bahwa kita tidak tahu hal tersebut secara mendalam. Misal, saya tahu tentang Clojure saya pernah baca tentang Clojure, tetapi saya tidak tahu cara menulis kodingan Clojure, dan bagaimana mendeploy Clojure di production. Nah Clojure disini menjadi “stuff you know you don’t know” Saya tidak harus tahu banget tentang Clojure sampai sedetail mungkin, namun setidaknya saya tahu Clojure itu apa, dan kegunannya untuk apa. Sehingga jika suatu saat saya dihadapkan dengan project yang membutuhkan teknologi Clojure, saya bisa memfokuskan belajar Clojure dan menjadikannya menjadi “stuff you know”.
stuff you don’t know you don’t know
Merupakan area yang tidak pernah kita ketahui jika tidak diberitahu oleh orang, media, atau pun secara tidak sengaja menemukannya. Misal ini saya analogikan seperti ketika saya masih baru lulus SMA, saya tidak tahu seperti apa itu jurusan Teknik Informatika. Saya tidak pernah tahu, kalau ada yang disebut dengan bahasa programming C, C++, Java, dsb. Kalau saya tidak kuliah, mungkin saya tidak akan pernah mengetahui ini. Maka ketika saya masih SMA, bahasa programming bisa dikategorikan sebagai “stuff you don’t know you don’t know”.

Nah dari 3 lapisan tersebut, kita pun bisa menyebut lapisan ter-atas adalah Technical Depth, lalu 2 lapisan teratas adalah Technical Breadht

Technical depth adalah kemampuan/pengetahuan kita terhadap hal yang kita ketahui secara kuat dan mendalam, semua hal yang ada dalam lapisan tersebut merupakan hal yang memang kita kuasai secara detail dan mendalam.

Sementara Technical breadth adalah pengetahuan kita terhadap semua hal dari yang kita expert dibidangnya sampai hanya tahu sedikit saja (stuff you know you don’t know).

Nah, yang membedakan dari Junior Developer, Senior Developer, Junior Software Architect dan Senior Software Architect adalah technical breadth dan technical depth yang mereka kuasai. Junior Developer akan memimiliki technical breadth lebih sedikit dari pada Senior Developer, begitu juga Junior Software Architect akan memiliki lebih sedikit technical breadth dibanding Senior Software Architect namun memiliki lebih banyak technical breadth dibanding Senior Software Developer. Jelasnya dapat dilihat pada diagram berikut dibawah.

Junior Developer

Junior developer cukup simple, sebagai junior developer, ekspektasinya mungkin hanya mengetahui sedikit hal, mungkin saat baru lulus kuliah kita hanya tahu tentang bahasa programming PHP, dan sedikit framework PHP.

Misal kita memiliki inventory “stuff you know”: PHP Language, Mysql, Laravel.
Lalu kita juga memiliki inventory “stuff you know you don’t know”, misal CodeIgniter, Java, C++.

Nah, Technical Depth kita adalah PHP Language, Mysql, Laravel.
Dan Technical Breadth ( “stuff you know” + “stuff you know you don’t know”) kita adalah PHP Language, Mysql, Laravel, CodeIgniter, Java, C++ (*tambahan dari technical depth)

Senior Developer

Lalu saat kita mencapai senior level, banyak asam garam dunia pun semakin terasa. Kita pun mulai menambah inventory knowledge kita. Yang sebelumnya hanya PHP dan Laravel, kini kita makin banyak expertise list.

Technical Depth(“stuff you know”) kita misal, PHP Language, Mysql, Laravel, Redis, MongoDB, RabbitMQ, Microservices.

Lalu kita juga memiliki inventory “stuff you know you don’t know”, seperti CodeIgniter, Java, C++, Kafka, Google Pubsub.

Maka Technical Breadth kita menjadi, PHP Language, Mysql, Laravel, Redis, MongoDB, RabbitMQ, Microservices, CodeIgniter, Java, C++, Kafka, Google Pubsub.

Junior Architect

Begitu pula selanjutnya dengan Junior architect, pada tahap ini, kita diharapkan makin banyak menambah inventory “stuff you know you don’t know”. Dan menggunakan inventory tersebut dan memindahkannya menjadi “stuff you know” sesuai kebutuhan.

Contohnya mungkin. Sebut saja John Snow, memiliki inventory “stuff you don’t know” salah satunya adalah MongoDB. Dia sadar dia kurang paham tentang MongoDB, tetapi dia menyedari bahwa ada teknologi NoSQL yang bisa membantu development yang menggunakan document based data. Dan suatu kesempatan, John Snow ada projek dan butuh akan penggunaan MongoDB untuk mempermudah penyimpanan document-based data di sistemnya. Nah dari sini, karena MongoDB sudah ada dalam radar “stuff you know you don’t know”, dia bisa pelajarin MongoDB sampai dia yakin untuk meng-implementasikannya di production. Mungkin dengan Proof of Concept (POC), dan testing skala kecil.

Dan pada akhirnya, saat dia menggunakan MonngoDB di production dan berjalan dengan baik, maka MongoDB akan bergeser dari “stuff you know you don’t know” => “stuff you know”. Saat ditahap ini, maka John Snow sudah membuat MongoDB menjadi technical depthnya dia. Selanjutnya adalah untuk John Snow untuk tetap me-maintain knowledge MongoDB dan tetap mengasah seiring dengan perkembangannya teknologi.

Senior Architect

Lalu di level Senior Architect, akan lebih abstract lagi. Harus memiliki segala inventori yang bisa dipelajari suatu saat nanti saat akan butuh terhadap teknologi tersebut. Namun hal menarik di tahap ini, kita juga harus merelakan kemampuan spesialis kita sebelumnya, karena mind mental kita sudah termakan penuh dengan hal-hal baru dari “stuff you know you don’t know’, sehingga mau tidak mau, kita harus learn to unlearn apa yang sudah kita pahami. Saat ditahap ini orang-orang yang resistance dan telah terjebak di zona nyaman akan kesusahan karena mereka sudah nyaman dengan hal yang mereka ketahui. Saya sendiri juga sedang mengalaminya. Saya sudah lama bekerja menggunakan Golang, sehingga saya sedikit kesusahan untuk mempelajari teknologi baru seperti JavaScript, Rust, dsb. Satu satunya cara untuk lepas dari jebakan ini tentunya memaksa diri dan membuat pikiran menjadi flexible, tanpa harus terpaku pada satu bidang teknologi.

Keep Adding List “stuff you know you don’t know”

Lalu mungkin ada muncul pertanyaan,

Bagaimana cara menambah list “stuff you know you don’t know”?

Salah satu langkah paling sederhana tentunya membaca, atau tetap update dengan teknologi melalui konfrensi online/offline yang ada di dunia. Mungkin dari sana kita nanti dapat belajar hal baru ataupun teknologi baru yang sedang di adopsi oleh para experts lainnya.

Referensi yang bisa dicoba diataranya adalah,

InfoQ
Radar by Thoughtworks
DZone
Engineering Blogs dari perusahaan teknologi lainnya seperti, Gojek Enginneering Blog, Xendit Engineering Blog, Grab Engineering Blog, dsb
dan banyak lainnya mungkin dengan follow akun-akun experts lainnya di Linkedin ataupun Twitter.

4. Menjadi Domain Experts / Memiliki Pengetahuan yang Mencukupi terhadap Bisnis Perusahaan (product)

domain experts from “The need for domain experts” by Joaquim Torres (Joca)

Selanjutnya, tidak kalah penting adalah, Software Architect diharapkan memiliki pengetahuan yang mencukupi terhadap domain bisnis dia bekerja.

Software architect memiliki banyak stakeholders, Executive, Managers, Software Engineers, Sales/Products, tim Infrastructure, tim Security dan sebagainya. Selain memahami masalah teknis, Software architect juga harus memahami bagaimana bisnis bekerja. Compliance yang berlaku, regulator (jika finance misal, OJK, Bank Indonesia), Enteprises dan partner policies, dan sebagainya.

Semua hal yang berhubungan dengan berjalannya bisnis tersebut, domain dari bisnis tersebut haruslah diketahui oleh Software Architect. Mungkin tidak secara detail, namun secara high-level view, bagaimana semua proses bekerja harus lah dipahami seorang software architect.

Saya tidak ada penjelasan banyak tentang bagian ini, karena setiap bisnis memiliki domain yang berbeda-beda. Sehingga sebagai Software Architect, diharapkan mencari sendiri jalan yang terbaik menurut dia untuk mempelajari domain bisnis yang dia miliki.

5. Memiliki Skill Interpersonal yang Baik, dan Mampu Navigate Iklim Politik yang Ada di Perusahaan

Berbicara tentang politik, mungkin kesannya sedikit negatif. Terlebih didunia pekerjaan, saat kita sebut “office politic”, tentu kesannya sudah sangat buruk (toxic culture). Namun yang dimaksud dengan iklim politik disini adalah, “the art of Negotiation and Convincing people”.

Jika diberikan contoh mungkin, sebut saja ada 2 orang architects. Saya dan John Snow.

#kasus 1

Saya sedang melihat repository dari notification service, dari struktur kode, tersebut sangat kompleks, dan tidak clean, banyak fungsi yang redundant, tidak loosely coupled yang mengakibatkan developement time jadi lama karena banyaknya tech-debt di service tersebut . Lalu saya pun membuat proposal untuk refactor dan mungkin re-write sistem dari awal dengan practice yang benar, rapi, clean dan loosely coupling yang memudahkan untuk pengembangan fitur fitur baru nantinya.

#kasus 2

Di sisi lain, John Snow. Melihat suatu sistem payment statement. Dimana fungsinya adalah untuk menyimpan history pembayaran.

Namun, ada keanehan pada architecture sistem ini menurut John Snow.

Bisa dilihat, terdapat shared DB terhadap banyak services/component. John Snow, selaku Software Architect membuat pernyataan, “DB should be isolated to its service, and no shared DB allowed. All data access should be only through interfaces like REST, gRPC and Events/Messaging”. Mungkin proposal John Snow, adalah sebagai berikut.

Nah dari kasus 1 dan kasus 2, yang manakah yang paling sulit dilakukan (mungkin impossible)? Ya tentu saja, kasus 2.

Pada kasus 1, Saya hanya mengubah struktur kode. Dan ini bisa dilakukan sendiri/team tersebut. Dan tidak perlu banyak drama.

Namun untuk kondisi kasus 2, akan sangat dibutuhkan interpersonal skills, komunikasi, negosiasi, dan convincing tim yang lain. Mungkin reporting service, admin dashboard, dan analitical team memberikan respon:
“Kenapa tidak buat Read Only DB replication saja?”
“Kenapa harus mengubah flow?”
“Ini sepertinya terlalu besar, harus butuh decision dari pihak management”

Semua komentar ini akan datang dari semua sisi. Karena dengan memberikan proposal tersebut, maka banyak pekerjaan akan tertunda, banyak tim harus memikirkan roadmap kembali. Priority management harus di restructure lagi.

Sehingga, untuk menghadapi kasus seperti ini, Software Architect harus memiliki interpersonal skills yang baik. Harus mampu meyakinkan semua tim, products, engineer bahkan eksekutif bahwa proposal ini harus dilakukan.

Kesimpulan

Saya merangkum ada 5 ekspektasi umum yang diharapkan dari software architect, dari 8 ekspektasi yang disebutkan oleh Mark Richards. Ke 5 ekspektasi itu adalah,

Menjadi Pawang Architecture Decision dan Design Principles
Menganalisa dan Meningkatkan System di Perusahaan Secara Terus Menerus Mejadi Lebih Baik
Update dengan Trend Teknologi, dan Tetap Belajar Terhadap Ekosistem Teknologi di Pasaran
Menjadi Domain Experts / Memiliki Pengetahuan yang Mencukupi terhadap Bisnis Perusahaan (product)
Memiliki Skill Interpersonal yang Baik, dan Mampu Navigate Iklim Politik yang Ada di Perusahaan

Dari semua ekspektasi yang diharapkan dari seorang software architect, saya sadari saya masih banyak kurangnya. Namun demikian saya belajar hal banyak dari topik ini. Saya akan mencoba meng-aplikasikan ini dan membuat ekspektasi sendiri agar saya bisa menjadi Software Architect yang benar.

Hey! Jangan lupa share ya! Bantu saya untuk membagikan artikel ini agar teman-teman kamu juga dapat membacanya ^_^

Software Architect: Continuous and Endless Sailing on the Endless Sea

Iman Tumorang — Mon, 17 Jan 2022 10:22:12 GMT

Saya pernah ketemu satu komik lucu. Tentang sebuah kapten kapal yang nekat berlayar meski kapalnya sudah buruk. Berikut komiknya.

Comic by Pablo Stanley

Apakah komik ini relate dengan teman sekalian? Buat kamu yang bekerja di dunia startup, saya rasa hal ini cukup relate. Kondisi dimana pihak manajemen dan product yang ingin merilis fitur secepatnya tanpa melihat kondisi sistem dan tech-debt yang menumpuk.

Akan tetapi kondisi ini terkadang menjadi buah simalakama, terlambat rilis tentu saja dapat tersaingin oleh kompetitor. Sebaliknya jika terus-menerus rilis tetapi malah menambah tech-debt, nantinya malah akan menumpuk untuk diurus dikemudian hari.

Dan memang bukan rahasia lagi, bahwa hal seperti ini cukup lumrah di setiap perusahaan khususnya di Indonesia, atau setidaknya di beberapa perusahaan yang pernah saya ketahui kondisi di dalamnya dan saya pun mengalaminya.

Untuk itu terkait penanganan tech-debt, dibutuhkan kesepakatan antara tim engineer dan pihak management atau PM. Dibutuhkan beberapa orang yang bertugas menjembatani keadaan yang terjadi di engineering, dan memberikan solusi terbaik menurut kedua belah pihak antara Product dan Engineering.

Dan untuk itulah kenapa role Software Architect dibutuhkan. Di tempat saya bekerja ketika menulis ini, untuk mengatasi permasalahan antara keeping best practice while release faster dan reduce tech-debt maka dibentuklah satu group independent yang kita sebut Architects. Dimana orang-orang didalam akan di assign ke semua team dan bertanggung jawab terhadap menyelesaikan masalah teknis dan architecture yang ada pada tim tersebut.

Apa Itu Software Architect?

Software Architect adalah orang yang bertanggung jawab terhadap permasalahan arsitektur yang terdapat dalam perusahaan, baik secara teknis atau pun bisnis. Software Architect bertanggung jawab menjadi penghubung antara kebutuhan bisnis dan ketersedian teknologi yang dapat dimanfaatkan guna mendukung kinerja bisnis.

Software Architect merupakan posisi/jabatan yang cukup ambigu secara general. Karena tidak semua perusahaan memiliki posisi ini. Berbeda dengan Software Engineer, Tech Lead, Engineering Manager, VP Engineering dsb. Posisi/jabatan tersebut memiliki job desc yang jelas, title yang jelas dan responsibilitynya pun sangat jelas. Saat bekerja di perusahaan X sebagai Tech Lead, maka saat pindah perusahaan pun, kita masih bisa menjabat sebagai Tech Lead.

Berbeda dengan Software Architect. Mungkin saat ini saya sedang bekerja di posisi Software Architect di X, namun jika semisalnya saya ingin pindah pekerjaan ke perusahaan lain, maka posisi Software Architect tidak selamanya ada. Mau tidak mau, saya mungkin harus menerima lowongan yang lain seperti sebagai Software Engineer, Tech Lead, Engineering Manager dsb.

Namun ke-ambiguan posisi/jabatan tersebut, bukan berarti role Software Architect tidak penting. Jabatan mungkin tidak ada secara umum, akan tetapi role/peran Software Architect masih harus dibutuhkan oleh perusahaan. Biasanya untuk perusahaan yang tidak memiliki posisi/title/jabatan Software Architect, maka role/peran Software Architect biasanya di pegang oleh para petinggi seperti Engineering Manager, VP Engineering, CTO atau bahkan dipegang oleh Software Engineer di perusahaan tersebut.

Dalam article “The Architect Elevator: Would you like architects with your architecture?”, Gregor Hohpe menyebutkan tentang kombinasi posisi/peran architects yang ideal.

Organizing Architecture by Gregor Hohpe in The Architect Elevator

Terdapat 4 kombinasi yang biasanya terjadi di banyak perusahaan,

Benevolent dictator: tipe yang one-man show, dimana satu architect decide everything dan team follow the architect’s decision.
Primus inter pares: tipe yang one man role dalam satu tim, yang dimana sang architect terkadang masih ikut turun tangan secara implementasi. Namun biasanya fokusnya lebih ke roadmap dan architectural problem. Posisi ini mungkin cukup lumrah jika terdapat satu Principal Engineer (Staff Engineer) di dalam satu tim. Atau untuk komposisi yang umum lainnya seperti Techlead dalam satu tim yang juga bertanggung jawab terhadap architectural problem di tim tersebut.
Architecture without architects: tipe yang work as a team, dimana decission dari Software Architecutre di tentukan bareng bareng sesama orang yang terpilih di tim tersebut, biasanya 2 orang atau lebih. Semisal, Principal Engineer dan TL decide tentang Software Architecture, shared responsibility.
Inmates running the asylum: tipe terakhir yang adalah kondisi lebih dinamis, biasa orang sebut dengan agile flexible. Dimana semua ditentukan bareng, dan tidak ada orang yang focus untuk melakukan tugas tugas architect. Sehingga decision biasanya lebih lama terjadi. Namun untuk tim yang lebih mature dengan experts didalam, biasanya decission lebih cepat terjadi.

Sehingga dalam perusahaan, bisa saja jabatan “Software Architect” itu tidak ada sama sekali. Namun untuk peran “Software Architect” pastinya selalu ada hanya mungkin peran itu terselubung secara implisit di posisi-posisi yang ada pada perusahaan tersebut.

Software Architect Expectations?

Lalu apa sajakah tugas dan tanggung jawab seorang Software Architect tersebut?

Apa yang akan saya jelaskan berikut adalah menurut yang saya alami, dan saya pahami. Sehingga jika ternyata berbeda dengan yang terdapat pada perusahaan kamu, kita bisa diskusikan dikolom komentar ~~sehingga saya bisa menyamakan ekspektasi jika suatu saat saya melamar ketempat anda *eh~~ sehingga dapat menambah data point tentang apa saja tugas dan tanggung jawab dari seorang Software Architect.

Mungkin terlihat abu-abu, berikut adalah point penting yang diharapkan oleh perusahaan saya bekerja terhadap role yang saya emban, diantaranya adalah sebagai berikut.

Architects connect the dots.
Maksudnya adalah, para architects di harapkan mampu menyambungkan semua Lego block yang terdapat pada keseluruhan sistem. Semua sistem di dalam perusahaan sudah pasti di design independen dan berjalan dengan baik. Namun sebaik apapun keseluruhan sistem tersebut berjalan, masih belum cukup untuk membuat bisnis berjalan. Dan layaknya seperti Lego block, architect harus mampu menyambungkan semua itu menjadi satu kesatuan dan sejalan dengan bisnis.
Architects fight complexity
Software Architecture sudah sangat kompleks, IT itu kompleks, bisnis kompleks. Maka sebagai architect diharapkan mampu mengurangi semua kompleksitas tersebut, dan menyederhanakan semua sebisa mungkin. Namun tidak harus menjadi over simplify, setidaknya menjadi mudah dipahami oleh para stakeholder dan tetap rasional.
Architects see trade-offs
Architect ketika memberikan solusi, haruslah menyertakan kekurangan atau poin-poin yang perlu diperhatikan dari solusinya jika solusi tersebut dilakukan. Karna menurut saya, tidak ada solusi yang benar di dunia software architecture, namun solusi optimal lah yang harus kita cari. Dengan perbandingan benefit vs trade-offs, maka kita memilih yang paling optimal.
Architects look beyond products.
Architect tidak terpaku pada satu product fitur. Tetapi harus melihat secara general, untuk melihat opsi yang lebih baik terhadap suatu solusi. Looks on the abstraction level!
Architects articulate strategy
Architect menerjemahkan strategy bisnis ke bahasa teknis. Sehingga bisa menjadi jembatan antara orang bisnis dengan engineer. Tujuan IT tentu saja menjadi enabler bussiness, mendukung strategy bisnis. Maka seorang architect diharapkan mampu menerjemahkan kebutuhan bisnis menjadi bahasa teknis yang dipahami oleh engineers.
Architects deliver
Meski architect lebih sering berpikir high-level domain. Architect juga diharapkan mampu down to earth, dan mendengarkan feedbacks secara langsung dari implementasi project ~ a.k.a terjun kelapangan, gak nyuruh nyuruh aja, tanpa tahu bagaimana keadaan project di lapangan :D

Namun in reality, apa yang saya alami adalah,

Menjadi unblocker, dan enabler para engineer.
Saya harus aktif bertanya terhadap tim, apakah ada yang bisa saya bantu agar tidak terblock. Membuat tools, atau RFC yang diharapkan mampu meringankan pekerjaan para engineers.
Memberikan pilihan solusi, tetapi tidak menetapkan solusi.
Ketika menyelesaikan satu masalah, saya biasanya sediakan beberapa solusi. Dimana nantinya saya kasih keputusan kepada tim untuk memilih. Atau terkadang tim malah memberikan solusi juga. Sehingga, bisa saja semua opsi yang saya berikan ditolak oleh tim. Dan saat itu terjadi, saya tetap akan harus mendukung solusi tersebut dan mengimplementasikannya bersama tim.
Lead by example
Ya tentu saja, saya masih harus melakukan implementasi jika diharuskan. Saya tidak boleh cuap-cuap theory saja. Saya harus langsung turun, dan melihat tingkat kesusahan solusi yang saya tawarkan.

Continuous and Endless Sailing on the Endless Sea

Saya masih sangat baru role ini, dan jujur saja, saya terkadang masih bingung untuk berpikir layaknya seorang Software Architect. Jika berbicara tentang zona nyaman, saya masih lebih memilih untuk tetap di Senior Software Engineer. Dimana seperti kata dari sesepuh The TechLead si Youtuber kondangan dengan opini-opini fenomenalnya. Salah satu opininya adalah:

Senior Software Engineer(SSE) itu adalah “Sweet spot” dari jenjang karir software engineering, dimana kita memiliki domain tersendiri, kebebasan tersendiri, dan memiliki outcome jelas dari Techlead, atau Staff level lainnya.

Ya memang benar, karena di level SSE, ketika kita tidak tahu berbuat apa-apa, kita bisa bertanya ke yang lebih senior, Principal, Techlead, dsb. Berbeda dengan ketika menjadi Software Architect. Ketika diposisi ini, saya tidak tahu harus bertindak seperti apa, ketika saya bertanya kepada manager saya, yang beliau katakan adalah:

“Iman, seharusnya kamu datang kepada saya membawa topik masalah dan pilihan solusi, dan requirement atau resource yang kamu butuhkan, apakah engineer, infrastructure, etc. Dan kamu eksekusi solusi tersebut sendiri. Jadi saya hanya tinggal membantumu mencari orang/engineer yang bisa menemanimu meng-eksekusi solusimu”.

Saya diharapkan menemukan masalah yang tidak pernah disadari orang, lalu menyelesaikan masalah tersebut.

Sehingga saya pun menggangap, berjalan di level Software Architect sama seperti berlayar tanpa henti di lautan luas. Harus peka terhadap lingkungan dan masalah yang tidak disadari orang lain. Harus cepat tanggap dan responsive, flexible dan manage ekspektasi semua stakeholder.

Sama seperti berlayar jauh dilautan luas, kita harus melihat apakah kapal baik-baik saja. Apakah tidak ada kebocoran, dan jika ada bocor, kita harus perbaiki sebelum kebocorannya makin melebar luas dan membuat kapal kita tenggelam. Kita tidak ada pedoman yang pasti, tidak ada yang bisa kita harapkan, hanya mencoba trial-error and looks the best answer.

Conclusions

Software Architect bukan lah posisi/jabatan yang umum, tetapi peran Architect biasanya pasti dimiliki perusahaan baik secara implisit atau eksplisit, misal TechLead diharapkan mampu menyelesaikan architectural problems. Atau Principal Engineer bertanggung jawab terhadap architectural problems, dsb.

Berjalan di architect role sama seperti berlayar di lautan luas tanpa henti. Harus memiliki disiplin dan peka terhadap segala perubahan dan masalah yang orang lain tidak sadari.

Namun meskipun demikian, saya tentu saja harus tetap berjalan. Jika tidak seperti ini, sampai kapan saya akan berjalan di tempat, menunggu disuruh baru bisa bekerja? Meskipun saya masih hijau dan butuh banyak pengalaman, saya yakin saya akan diposisi dimana saya akan bangga dan di akui oleh orang-orang lain sebagai Software Architect seiring dengan waktu berjalan nantinya.

Reference:

https://architectelevator.com/architecture/organizing-architecture/
Xendit’s Principle about Operating as an Architect

Demi mencapai cita-cita saya menjadi Software Architect yang handal. Saya menerima tawaran part-time/freelance/consultant Software Architect dan focus di area Software Architecture, Microservices serta masalah scaling secara umum lainnya. Saya akan memberikan solusi yang terbaik menurut kemampuan saya sesuai kondisi masalah yang diberikan.

Notes of SoftwareArchitect.ID

Combining Modular Monolith and Hexagonal Architecture while Maintaining Domain Driven Design Principles (part 1)

Layered Architecture

The Rise of Hexagonal Architecture

Vertical Slicing with Domain Drive Design

Entering the Modular Monolith Era

Final Words

Developing Modular Monolith and Hexagonal Architecture in Golang while Maintaining Domain Driven Design Principles (part 2)

Step 1: Defining the Bounded Context

Factory

Internal

Module Definition (module.go)

Public API Definition

Step 2: Accessing Other Modules’ Public API (Interface)

But why not put them in ports?

Step 3: Database Schema

Step 4: Assemble all of them

First, build,

Running the rest API server

Running the cron (invoked by Crontab/Cronjob)

First, build,

Running the rest API server

Running the cron (invoked by Crontab/Cronjob)

Final Words

How would you describe your ideal team composition?

One Team For the Whole Organization

Is this my ideal team composition?

Team based on the Role

Is this my ideal team composition?

Team based on Product/Domain

Domain / Area Level

The birth of Platform Domain

Is this my ideal team composition?

My Ideal Team Composition?

Product vs Platform: the Struggle to Make the Domain Boundaries

Intro

Platform vs Product in Platformization Vision

Is this a business value that your customers paid for?

Can any products use this?

Platformed Product

The Dreams

It’s hard, but it should not be impossible — at least with fewer changes.

The Challenges

Platform vs Product vs Platformed Product Breakdown Examples

1. Direct Debit Payment

2. Identity Verification

Conclusion

Menulis Dokumen Architecture North Star

Architecture North Star

My Experience in Writing Architecture North Star

Menulis dokumen Architecture North Star

List Pain and Dreams

Analyze and Write Architecture North Star Document

Finalized and Distribute Architecture North Star

Kesimpulan

Diary #4 C4-Model pada Software Architecture

Dongeng: Kisah Pilu Software Architect

Introducing C4 Model

Level 1: Context

Level 2: Container

Level 3: Component

Level 4: Code

Workshop: Sistem Informasi Absensi Karyawan

Level 1: Context

Level 2: Container

Level 3: Component

Level 4: Code

Kesimpulan

Diary #3 ADR (Architecture Decision Record) pada Software Architecture

Apa Itu Architecture Decision Record (ADR)?

Komponen ADR

1. Title

2. Status

3. Context

4. Decision

5. Consequences

Menulis ADR

Conclusion

More Reading

Diary#2: Struktur dan Aspek Penting dalam Software Architecture