Yesterday, I had a coffee talk with one of my external mentee (outside the organization) and he is joining a new employer next week as a data architect. He asked my advice. I started with a disclaimer; my views are not just for a data architect. I expect any architect who joins new organization to do the following. It can also be generalized as a mentoring advice for who joins new organization. The following were my spontaneous response to him.

1. Understand the core business of the organization. If it is a profit organization, understand, how the company is making money? Translate the business model into cash flow diagram in a highest level. Do not make assumption based on the generalized business practice or models. For instance, increasing the customer traffic may increase sales and profit in retail sector but it may not be the case for boutique luxury product or service offering organization. In the boutique luxury product or service organization, the focus may be to retain existing customer. Not to increase the customer base since the supply is very limited and unable to even meet current demand.
2. Understand the culture of the organization. Is the company culture is innovative, fast followers, conservative, aggressive risk takers, collaborative, bureaucratic, autocratic, open, hierarchical (control) and etc.
3. Do due-diligence, investigate, communicate, communicate and communicate with all the key stakeholders in the organization to accomplish 1 and 2.

After the short 30 minutes meeting, while driving to work and rushing to take my 8.30 am call in my car, I was thinking the following.

There are terminologies like canonical data model, Meta model, master data management, enterprise data flow, enterprise data bus, enterprise service bus, big data and etc in the realm of data architecture. Quite often, I hear from a passionate data architect about these terminologies in a way, I struggle to understand the tangible benefit. For instance, I hear the definition for enterprise data flow as, enterprise data flow is a structured method that record analyze summarize organize explain the key information which are illustrative to bottom line core business process with inbound outbound flow that indented for the understanding enrichment enhancement and education of key decision maker to make right business decision at the right time to improve overall objective of the business. I didn’t hear the above exact definition but I exaggerated a bit to make my point using Raju Hirani’s idea. Main goal of enterprise data flow is to show critical information to improve ultimate business purpose (like profit). I see architects engage in a prolonged discussion to define taxonomy, framework, methodology, process, tools, governance, stewardship, data quality, reference model and etc. All are great topics and leads into an intellectual discussion, but, sometimes, I noticed the discussion missed to address the ultimate purpose.

It is easy to complicate a thing but it is damn hard to simplify it. My expectation from an architect, including data architect, is to work really hard to simplify the architectural work.

I visualize a data architect as a money-ball architect. For those who have not seen the movie money-ball, the movie is about real life experience in a base-ball team Oakland Athletics where the coach hired Yale graduated economics student who was so passionate about the game and league. He studies the league rules, player profile and creates near optimal data model and analytics to run a successful professional baseball team in the league with lowest investment.

Any successful data architects are money-ball architects. Money-ball architect follows the rule, break the rule, create a new rule and break it until money-ball is identified in the massive multi-dimensional data domain, model the money-ball sub-domain data, identify the key business differentiator from the sub-domain and use it to improve ultimate business purpose.

Money-ball architect will start using canonical data model, Meta model, master data management, enterprise data flow, enterprise data bus, enterprise service bus, big data, taxonomy, framework, methodology, process, tools, governance, reference model (follow the rule). Identify the areas which are not directly contributing to identify the money-ball (break the rule) and drop those areas. Introduce a new concept which directly contributes more to identify the money ball (create new rules) and repeat it until the money ball is identified, modeled and used to improve ultimate business purpose.

To become a successful data architect, create a path for yourself to become a money-ball architect for your organization.