Pavel Vlasov

Cover Letter
Linked-In Profile
Web site: Nasdanika

Over 28 years of experience in Information Technology with 25 of them in the Financial Services industry, which includes 20 years in banking.



Citi Global Consumer Group

Senior Vice President, 2005 - Present

During my time at Citi Global Consumer group I worked in different parts of the CTO organization.

Engineering & Architecture

My current role is a Chief Architect of Developer Experience with immediate focus on improving developer experience for Java developers on OpenShift.

As part of larger Developer Experience efforts we’ve established a capability to develop and deliver a connected1, role-specific2, cross-referenced3, hyper-local4 visualized5 and interactive6 developer experience “as code”7 in a form of journeys8. We’ve also documented OpenShift new solution journey using the above capability.

Our Developer Experience portfolio also includes the following items:

Some of the above capabilities are already available for consumption while others were prototyped and await productization.

To prioritize our pipeline we use developer personas with goals and we align our efforts to persona goals. Developer personas and their goals are defined using a variety of techniques including analysis of survey results.

As part of the Developer Experience efforts we’ve established a concept of the knowledge continuum similar to the TOGAF Enterprise Continuum with thir-party documentation being most generic, documentation for internal libraries and services being in the middle, and journey activity documentation being most to specific.

I’m also participating in several company-wide efforts, e.g.

Product owner of Citi Cloud Platform Integration Services domain.

June 2017 - July 2019

Product owner of the Cloud & Integration Services team. The team owned more than 30 software platform components used by application development teams. The components owned by the team were organized into four “pillars”:

When I became a product owner the previous product owner moved to another position within Citi taking the most of the team with them. The remaining 3 people had been with the team for a few months and one of them eventually left the team. People who joined our team were totally new to Citi. So the new team of 8 developers plus the product owner and the scrum master had to quickly get a grasp of what we came to own. We achieved it by “dividing and conquering” - each component was assigned a primary and a secondary owner. The owners created and deployed to the Citi intranet Maven sites for components they own. The sites featured component overview, Java API documentation, roadmap and changelog pages. Microservice sites also feature generated REST API documentation.

We’ve also created and deployed a Maven team site for the team which lists components grouped in categories (pillars) and sub-categories. Component listings provided links to the component sites. All the sites have the same style. The breadcrumbs of the team site and the component sites provide a uniform experience of main site/child site.

The primary target audience of the component/team sites were developers and architects who use our components. The component/team sites had releases tied to sprints.

In addition to the component and team sites we’ve set up a team wiki where we capture and refine team processes, e.g. the component site publishing process. The team wiki’s target audience was the team, although some other teams have started following our processes as well. The wiki evolved continuously.

In this role I wore two hats - a product owner and a dev lead of the Productivity pillar. Worked with the team “customers” to understand their needs and built roadmaps which then were elaborated into features and stories in the team backlog. Before a start of a new sprint stories were prioritized and assigned to the team members with capacity and skillset in mind.

In addition to the team wiki I’ve also established and maintained a wiki for the architecture organization where multiple teams contributed.

Application Modernization

September 2016 - June 2017

In September 2016 I left the R&D team to become a lead of the Application Modernization domain of the Citi Nexus Platform. The focus of the team was to provide solutions for conversion of monolithic applications into micro-services.

One of the monoliths which we worked with was a Java Web Application project with:

The above metrics do not include dependencies, just the application per se.

First we started with Sonargraph-Explorer to get a feeling of what we were facing. Sonagraph is a very nice tool but because of the huge number of classes involved in the circular dependency “black hole” we needed a more advanced tooling.

First we created an Ecore/CDO model of the Java language which included not only declarative things as in the java.lang.reflect package, but also call trees, field references and bi-directional inheritance references. After that we created a model loader which leveraged ASM to walk through the bytecode and populate the model.

Once we had the model and the loader we created a model-driven web application to browse loaded models in order to get better understanding of the codebase - “Analysis repository”. The application used PlantUML to visualize the model via class context diagrams and method sequence diagrams. After we loaded several modules the application repository had about 2 million objects - packages, classes, methods, fields. The performance was not lightning fast, but acceptable and the repository database was about 250 megabytes.

Using ASM we also created a code instrumentation tool which would take a jar file and data collection endpoint URL as input and output a jar with bytecode instrumented to report call trees to the endpoint. We’ve also added a data collection endpoint to the Analysis repository.
Collection of runtime call tree information was intended to complement static analysis by recording reflective calls.

The next step for us was creation of an Eclipse plug-in for module extraction. Given a number of entry points (classes, methods) the plug-in was able to extract a sub-set of the source project codebase traceable from the entry points. In classes the plug-in would only extract class members traceable from the entry points. E.g. if a class had a hundred members but only ten of them were traceable from the sources the plug-in would extract only those ten.

The plug-in used the loader module and Eclipse JDT to analyze source code, and JDT refactoring capabilities to extract the code into a new module.

The plug-in was implemented as a multi-form editor with one page/form presenting a source checkbox tree allowing the user to select entry points. Other pages/forms collected additional extraction parameters. Module extraction configuration was stored in JSON with transparent loading to an EMF model and saving the EMF model to JSON. The editor used EMF Data Bindings with TransactionalEditingDomain to support Undo/Redo of complex model manipulations.

We’ve set up a team wiki where we documented our work and also collected “how-to’s” for different technologies which we used - JDT, JFace Data Bindings, EMF, …

Research & Development

Shared Technology Services

Focused on integration components using JMS, J2EE Connector Architecture, Tibco EMS and Tibco BW.

Sawgrass Integration Architect

Sawgrass is a Citi Cards call center application. I was responsible for the architecture of the middleware components which included:

In parallel with the primary responsibilities I also participated in the following efforts:

Technologies used:

iGate Global Solutions

Technical Architect, 2000 - 2005

Bank of Moscow

Head of IT Department, 1999 - 2000

Managed 4 IT professionals who supported the branch’s computer park (70 desktops and 4 servers), network and telecommunications. Supported/administered hosted applications and developed custom applications and modules.


Senior Specialist, 1996 - 1999

Managed telecommunications, electronic fund transfer systems and development of branch-specific software.


Software Developer, 1993 - 1995

FoxPro 2.6 development.


Novosibirsk State University - Master of Science in Plasma Physics, 1988 - 1993



  1. Journey activities are connected to each other with transitions and calls. Generated context visualizations previous and subsequent activities - “You are here”, so to speak. 

  2. Activities are performed by roles. Support of simple activity to role reference as well as RACI matrix. 

  3. Bi-directional references between activities, tools, roles and deliverables. 

  4. Infinite nesting of activities allows to create highly focused activity documentation. 

  5. Generated state diagram visualizaitons with ability to manually edit generated visualizations and manually create visualizations from scratch. 

  6. Generated state diagrams have clickable activity shapes navigating to the clicked activity documentation. 

  7. Journeys are defined with YAML and Markdown stored in a source control system. Documentation is generated with a Maven build. 

  8. Journey is a directed graph of activities performed by roles using tools and consuming and producing deliverables. Journey is a subclass of activity and as such journeys can be infinitely nested.