The Wiz way to build technological solutions
Tags: microservices, governance, agile, devops
Published: 2020-07-07 20:47:47

Hello, I'm Lucas Mindêllo, an IT Manager of Wiz and I'm responsible to define the Wiz way of working in technological solutions. So, I need to provide you a background of Wiz challenges that I'm trying to address.

We are Wiz, we sell insurance and financial products using our business units. So, we have an initiative shaping the way all our sales structures works.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/6vozev3na7e2o7dacoyl.png)

For that, we're organized in Squads where each one looks for a singular business unit, each one with different needs and, as head of the development team, I need to help our Dev team to be able to work, build solutions with a corporate vision, and delivering value on every sprint. By the way, we mainly use Scrum, although that needs another article.

# How we keep governance in our development?
I believe that we have three main pillars to address, a frame to deliver the same vision to all developers, a well-known process and management on those pillars. This article will focus on the development frame.

To deliver that, we need to level some ground premises:

We develop using microservices architecture;
We deliver autonomy to all squads;
We need to level knowledge with our DEVs;
We need to maintain corporative system governance.
And this frame results in white-label solutions for our costumers. Based on components and low effort to change the look-n-feel.

# What a component represents?
Besides the frontend component concept, we've extrapolated it to backend/frontend connection. We did that, somehow a component is configurable to any similar need.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/8mjmb0yaoallue3n1lit.png)

The image above represents a simple component that has the CRM and two databases as sources. We believe that a project standard for components and pages is enough to address the governance needs for the frontend, although we need to better shape the backend architecture.

# How we address the backend governance?
Focused to maintain the squads' autonomy and reuse the majority of our developed code, we have split our microservices into two categories: Wiz Services and Squad Services.

We've limited to Wiz Services only corporative business rules, somehow any business unit should use the service routes seamless. With that in mind, we had to enforce a higher code review policy and deployment.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/7atzip8cnf8pusorgshi.png)

As we need all DEVs to be able to evolve our Wiz Services, we've defined .NET Core as our standard framework for Wiz Services.

To address the Triple A need on every element connection, we've developed a SSO API, based on OpenID and JWT token. We did that someway the same SSO solution is used for a user or service identification.

Another auxiliary service is Wiz Log. This solution is focused to log our business events. Our main objective is to be able to keep track of some business events and to be able to analise that information.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/w2h9hx4m3qez1gohp3om.png)

I think that the Wiz Log can be explained in another article.

All of that is unecessary if we don't standardize our microservice code.

# What is the Wiz Microservice Project Standard?
We think that is worth to split the application in domain layers, that way we've made our interpretation of DDD (Domain Driven Design). We've split it in 3 layers, API, domain and infra.

I think that the success of a well-designed API depends on a good domain definition. The Domain layer is where we define what are the entities that our microservice will represent. If we take a CRM-API as reference, one main entity is Client and every client has some attributes that is common to all business units needs. That's the main responsibility of the Domain Layer.

The Infra Layer should translate the API entity to the datasource elements. Using the same API-CRM as an example, in this layer a client should be represented as an Account and Contact in Salesforce. This way, for any reason, if we need to integrate our API to another CRM, we just need to translate those entities to that CRM.

And finally, the API Layer is the presentation layer. It's where we expose our REST endpoints. By the way, we use RESTFull on our microservices, which improves our development velocity.

# Conclusion
I think we're on a good way to develop great solutions with governance and keeping a good velocity.