blog/EPAM Anywhere/personal story/from a business analyst to a service architect in a neural networks project: the EPAM Anywhere way

from a business analyst to a service architect in a neural networks project: the EPAM Anywhere way

6 min readpublished 23 July 2021updated 26 January 2023

At EPAM Anywhere, we constantly expand career horizons. We encourage vertical growth in a specific domain as well as horizontal development in adjacent fields. For one of our specialists, Badara Bazarov, the role of a Business Analyst doesn't end with gathering a client's requirements and turning them into business features. Recently, Badara shared his experience working as a Service Architect on a project with neural networks.


The customer is a bank that wanted to modernize its automated systems (monolithic architecture) by migrating to a more productive, efficient, scalable and user-friendly suite of independent services (microservices architecture).

The task of the development team was to create an architecture of modules designed to automate business processes that would process client requests in the new system. The challenge of the project was the existing infrastructure that consisted of a combination of ready-made and custom solutions ‒ neural networks in particular ‒ which needed to be used as a part of the solution.

Badara Bazarov has been working in the IT industry for 12 years, specializing in the automation of business processes in the banking and information technology domains. With the FinTech project described above, Badara wanted to step beyond his Business Analyst role and take on new responsibilities as a Service Architect.

Service Architect at EPAM Anywhere: typical responsibilities and methodologies

The role of a Service Architect at EPAM Anywhere includes the following responsibilities:

  • analysis of the requirements for the information system
  • development of concepts for data integration
  • development of technical and project documentation
  • implementing the interaction of software and hardware components; and
  • management of microservices architecture development

Methodology of service architecture

As with business analysis, service architecture has standards and specifications that must be followed. The most popular standards in service architecture include the Zachman Framework and the TOGAF Standard. Simply put, service architecture is a design framework that can be applied anywhere: from enterprise projects to daily tasks like vacation planning.

Badara reworked these popular standards and created a simple 8-step checklist, breaking down the process of service architecture:

  1. Understanding business goals. Critical questions at this stage include: "Why do we build the product?", "What benefit does it bring to end-users?", "How does a client sell their product or a service?" and "Is the product profitable?" Keep in mind that business goals may change due to internal and external factors; it's crucial to stay on the same page with stakeholders and track changes.
  2. Requirements analysis. It's not enough to understand the mechanisms by which the product or service is sold. You must also understand how to implement the product and its functionality.
  3. Component requirements. After business process definition, we consider component requirements to avoid reinventing the wheel, and to identify functional and non-functional requirements. Badara notes that requirements analysis should also include feedback from end-users to ensure a 360-view of the system you're building.
  4. Implementation requirements. At this stage, we determine the timeframe and resources necessary to implement the solution. Typically, service architecture is planned a year in advance with quarterly decomposition of tasks. Service Architects must be capable of long-term planning and ensure that new functionality is rolled out every quarter.
  5. Constraints analysis. There are technical and organizational (e.g. human resource) constraints that must be considered in advance. Constraints analysis provides a roadmap to enhance product development. For example, a Service Architect can decide to decompose functionality and shift some components of the scope of work to the next deadline period, prioritize deliverables, and develop appropriate features.
  6. Architectural solutions. By evaluating project requirements and constraints during earlier stages, the Service Architect develops a complete picture of the components, interfaces, and APIs that must be developed from scratch or modified to deliver a workable solution.
  7. Risks analysis. Technical and non-technical risks are characterized by their impact and probability: the lower the rates are, the better. However, a levelling mechanism must be identified or developed for each risk to decrease or eliminate its effects.
  8. Results analysis. Ultimately, it's essential to evaluate the processes, identifying things that could have been done better, and which actions could optimize architecture building in the future.

Key artifacts in service architecture

There are three key artifacts in the work of a Service Architect:

  • Service architecture of blocks and modules that represents the relation of components;
  • Business process diagrams to understand system requests and their parameters;
  • Data storage models. A logical data model can be sufficient to determine how objects will be connected to support pre-defined business scenarios.

Must-have soft and hard skills for a Service Architect

Badara outlines several soft and hard skills essential for a Service Architect. Among soft skills, Badara highlights:

  • networking skills to communicate with, and obtain feedback from: customers, a development team, end-users, and other stakeholders
  • curiosity, to pursue knowledge of cutting-edge technologies, their working principles, business opportunities, etc.
  • a blend of synthetic and analytical thinking, to see the bigger picture, trace the relations between objects, and delve into the specifics of a system

Critical hard skills include:

  • hands-on experience with UML and BPMN diagrams
  • functional decomposition
  • database design

Hear from Badara

At EPAM Anywhere, you can select the role of a Service Architect as one of the career opportunities for senior-level Business Analysts. With our clear career roadmaps and skill matrix for each professional level, it's easy to see your long-term growth within our company.

"One of the most significant needs of humans is freedom and EPAM Anywhere is not only about working opportunities, it is also about work-life balance. Here, I have the freedom to choose where to be and to decide how to manage my working process in the most efficient way.

This flexible approach is helpful for the pursuit of hobbies: one can live at the seaside and hone surfing skills, or change cities and countries to meet new people, experience new cultures, and so on."

EPAM Anywhere flag at Elbrus

"My hobby is alpinism - climbing mountains - and my last trip was to the Caucasus and its peak of Elbrus, 5642 m – the highest point in Russia and Europe, a symbol of strength, pride, and courage, and an aspiration point for many climbers to achieve their goal. Traveling in mountains is a great journey with a series of decisions and sequential and logical actions that lead to the achievement of your goal. That’s what we do in our work too. 😊

I organized my work schedule at EPAM Anywhere in a way that lets me come to the mountains in advance, to check the place, and prepare myself for the climb to make my attempt successful. This is how EPAM Anywhere helps me to achieve my goals."

P.S. We always welcome skilled Business Analysts and Service Architects to our team, so check our available vacancies and send your CV. We'll get in touch with you promptly and find a suitable project to put your skills into practice!

Our special thanks for the contribution to this post go to Badara Bazarov, Business Analyst, EPAM Anywhere

get the latest tech insights, career growth, and lifestyle tips right in your inbox