Consulting

DESIGN AND IMPLEMENTATION OF A COMPANY-LEVEL SERVICE ARCHITECTURE

/* A case study on implementing company-level service architecture, as well as changing monolithic ties without breaking anything. */

project overview

The client was looking for a successful digital transformation across their entire service architecture. The client was a large IT Distributor company and had more than a few hundred different IT systems across their operations. Our job was to develop and integrate a new system with integrated services that provided access to data and operations to them in the end systems. Our aim with this was to hide the complexity behind simple API contracts and all the while break the monolithic relationships of systems integration inside each other.

challenges

One of the main challenges was that the company used Microsoft Dynamics 2009 as its primary ERP system. This system was deeply imbedded, and in terms of integration with existing systems, there were several ways we could go about it:

  • Integration directly into the ERP database
  • Use of SOAP-based self-written services
  • Using REST-based self-written services
  • One-way data exchange from ERP to end systems, calling via HTTP
  • Integration via sending email notifications (both ways)
  • Integration via file exchange

All of this was practically undocumented, not checked by autotests, and poorly monitored.\

/* In addition, the company was missing Enterprise Architects’ competencies, as well as Senior Developers who could set high standards and requirements for new integration services. */

Project details

As a part of the pre-project research, our specialists highlighted the main business processes and data points such as orders/stock, reserves/prices, and data directories. These processes were the main points of integration with their systems and were where the highest number of potential API consumers were possible.

With this, we developed their main concept and service architecture, while establishing the “rules of the game” and basic requirements for their service description, technology standards, infrastructure, stack, fault tolerance, and scaling requirements.

For this project, we also had to draw up a proposal to bring on a resource plan for hiring employees who could form an integration team and thus have all the necessary competencies for developing the project further.

The following list of participants was obtained:

1
Architect
1
Dev Lead
2
Business Analyst
3
Senior Backend Developers
2
Auto testers
1
Devops

Through our client’s internal HR and with help of a few of our consultants we chose the necessary candidates and arranged technical interviews for recruiting into InHouse development.


As a result, after 1.5 months the desired team of people had been recruited and we launched the Scrum team, which then developed the integration services in the company according to our product approach, which in turn allowed them to develop their own systems within the company.

Proposed technical improvements

From scratch, we built a fault-tolerant infrastructure inside the company based on:

  • Kubernetes
  • ArgoCD
  • GitLab
  • Harbor
  • Vault
  • Ceph
  • EFK Stack (Elastic Search / FluentBit / Kibana)
  • Prometheus
  • Zabbix

Main approved development stack:

Backend: .NET
Testing: PyTest, Selenium
Logging: structure logging(JSON)
Metrics: Prometheus
API Gateway: NGNIX, YARP
Database: PostgreSQL, MongoDB
Full-Text Search: Elastic-search
Cache: Redis
MQ Broker: RabbitMQ
Proxy: Nginx
Architecture description method: C4 Model

Project results

  • Hired a team of 10 people

  • Create and maintain InHouse fault-tolerant infrastructure based on k8s

  • Implementation of DevOps best practices

  • More than 40 business services of varying complexity in the company’s catalog, with integrations between 25 different systems of the company (including RPA-based automation mechanisms)

  • Average t2m of a new integration service API = 2 weeks

  • More than 90% of code is covered by test

  • 99.9% SLA

  • The team can work autonomously, the external presence of CallCTO curators is not required

industry
Enterprise
Stack
k8s, .NET, DevOps, Autotesting
Duration
2 years

Contact

Have a project in mind?
Let’s Discuss!

By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage and assist in our marketing efforts.