Hub Designs Magazine

Transforming National Companies (Part 2) – Enterprise Data Architecture, by Dmitrii Kovalchuk

Part 2 in Dmitrii Kovalchuk’s series on building a data management program in Kazakhstan


We continue our project here on Hub Designs Magazine, called DMFSData Management From Scratch. This field report addresses Enterprise Data Architecture.

I’m going to share with you part of the story about how we developed our approach and the obstacles we overcame. There are still some things that are not clear to us, so I’d like to ask you some questions at the end of this article, in the hope of receiving your feedback and guidance.

Yours sincerely, Dmitrii Kovalchuk

Developing an Approach

From the beginning of this transformation program, our Core Transformation Team (CTT) has been responsible for writing transformation guidelines, based on the assumption that all portfolio companies should go through a Design Stage, to develop an enterprise architecture including both business and IT architectures, which in turn encompass an enterprise data architecture.

The first challenge we took on was the selection of an appropriate methodology or framework to adopt for the transformation. On, we found a great article, Survey of Architecture Frameworks, which describes about 70 different frameworks. After reviewing many of these frameworks, discussing them with consultants, and reading appropriate articles and books, we worked out the following set of artifacts, which we include in our Enterprise Data Architecture framework.

This graphical representation derives from the guidelines we developed, which we wrote and sent to the portfolio companies as a uniform methodology. To develop this Enterprise Data Architecture Framework, we used recommendations from the following standards/frameworks:

We also appreciate the help we received from the consulting companies that we mentioned in the Introduction article for this project. As an enterprise data architect, our team member Erlan Kadraliyev has read numerous books about Enterprise Architecture and Enterprise Data Architecture. Here are some references that Erlan finds useful:

Selling the Approach

In our approach, subject matter experts from different business functions have to be involved in the development of the enterprise data architecture.

Even though these people are supposed to be part of the transformation program, we met strong resistance from their side. Their leaders did not want to divert them from their core duties. They felt that IT professionals or system integrators should do all data architecture activities during the implementation stage. It was a brick wall that we had to break through simply because data architects cannot develop an enterprise data architecture without the active participation of the business.

So, to sell our approach, we involved a change management team, developed a communication plan and conducted the following activities:

I’m happy to say that we’ve accomplished a great deal in promoting cross-organizational collaboration. Several business stakeholders are currently working to define and describe their data requirements.

The Challenge of Finding Qualified Data Architects

The absence of data architects on the labor market here in Kazakhstan is the next challenge we encountered. We’ve discovered that “data architect” is a brand new profession for our group of companies. Based on research that I conducted, I found that people who understand data management and data architecture concepts are primarily working for banks.

Banks have a much higher maturity level of data management than industrial companies because the market demands it. Unfortunately, most of Kazakhstan’s advanced banks are located in Almaty, the former capital of Kazakhstan, and not in our city.

To overcome this challenge, we are headhunting data professionals from Almaty and even in other countries. I interview each candidate personally. Right now, I’m looking for a data architect for Kazpost, the national postal service provider of Kazakhstan.

We are also concentrating on educating our current IT personnel to grow data architects internally. We regularly organize TOGAF® courses and conference calls with western gurus. On a weekly basis, we conduct round tables with the enterprise data architects of our portfolio companies to share experience and discuss problems.

Questions for You

  1. Some of our companies have time and budget restrictions. What’s the minimum set of enterprise data architecture artifacts they should create during enterprise architecture development?
  2. How does the absence of an enterprise capability map negatively influence enterprise architecture (particularly enterprise data architecture)?
  3. What governance model needs to be built to support the enterprise architecture? Which team or business unit should an enterprise data architect work for, the data governance office or the IT department?

Please, tell us your thoughts in the Comments section below.

Next Month’s Report

Our next article will cover a comparison of Russian consulting firms that offer MDM implementation services. Currently I’m developing market research to help create a short list of potential contractors, so I’ll be sharing my expertise in this area.

You can read about the results of my research and my recommendations in the next DMFS Field Report – coming soon!

About the Author

Dmitrii Kovalchuk has worked as a data management consultant for more than ten years and has experience in data governance and stewardship, data architecture, data development, master data management and data quality management.

In addition to his keen interest in data management, he enjoys spending quality time with his family, as well as jogging, hiking and paragliding.