Data Architecture Reviews

When you are leading large Transformation initiatives, Business Process Architecture, Technology Architecture and Data Architecture are 3 keys aspects of the overall strategies. In this article I want to emphasize on how important these for overall success and some rule of thumbs for consensus building on Target state proposal. I will back up my statements with some specific examples in Investment Asset Management industry, as that has been my focus from last many years. But basic principles here can be easily applied to any industry verticals.

Before we start it is very important to understand that any large organization have 3 types of Business Systems and Technology Components.

1. Systems of Records or Master Systems: These are the systems which are Point of Entry for Domain specific data from external sources. They are responsible for doing Data Quality Check, standardizing data from multiple sources, enrichment and Mastering of the Data. Mastering typically comprises of creating Golden, Silver and Bronze copies of data coming from multiple sources by applying Hierarchy resolution. They will also be responsible for generation of domain specific Master Identifier which is Environment and Source agnostic. For instance, in Asset management Technology architecture, Security/Instrument Master plays key part.
2. Data Integration Platform: These are the systems or platforms which are responsible for integrating multiple Data Domains, transforming it as necessary and implementing Data Management Functions. They can be strategic or tactical in nature. They also provide abstraction layer for its consumers in the form of Views, APIs, Warehouses and Data Marts.
3. Business Capability Centric Applications: These are either home-grown or Vendor supplied Products and cater to specific Business Capability and it's processes and Functions. Their Data Requirements are very specific to Business Use Cases. Due to past challanges they may have lot of technical debt which needs to be addressed.

Now with this much context in mind, here are few things which are very important to consider for beginning your Data Transformation Journey.

• Choose the right set of stakeholders in the discussions. You want all the right players involved at very early stage in order to avoid friction and disagreements later on. Make sure you have Technology, Data management, Operations and Business Team involved. Each of them can bring unique perspective from Requirements, Data, Process and Technology point of view.
• Have all the assumptions which needs to factor in regarding current state or Target state of Data, Processes, Requirements, Systems and Technology. These provide people with right context into the proposed Data Architecture later on.
• Clearly list Business Use Cases you want to solve for. They can be current state or aspirational.
• With multiple Systems of Records, Data Platforms and multiple consuming applications, current state to Target Future state transition may not be straightforward. One may need one or more Transitional states for Source to Consumption Data Integration and Interfaces. Make sure that is called out clearly with Domains and Sub-domains of data flows. It is very important to call out how System, Data Interface, Integration and Flow landscape changes from Current State to Target Future state.
• One of the Key Guiding principle of Data Architecture Transformation is standardization through Canonical access of the data. This can be achieved through Source Agnostic and Consumer Agnostic Data Model. Conceptual Model depicting domain level entities, their relationships can go a long way. This area will lead into Data API Design and Dat Warehouse design in successive iterations.
• Decisions and Questions. If any high-level decisions or agreements are made in these discussions, they should be clearly documented along with any open questions.
• Make sure all standardized Business Data Quality rules are identified with the help from Business and Operations stakeholder. They are close to requirements and Business Processes in general.
• Last but not the least, is identify stakeholders which will sign off on all the details. They will largely be leaders from same organizations which were identified above.

With a right focus and agenda these initial discussions will be steppingstone towards larger consensus building and will lead to detail and iterative design and planning discussions. In next few articles will talk about specific Data Domains in Asset Management and overall approach.

#dataarchitecture #datastrategy #dataquality