If you want small changes in your life, work on your attitude. But if you want big and primary changes, work on your paradigm.– Stephen Covey
Reflecting back on last week’s Enterprise Data World, the most prominent take-away for me is the fact that data architects must adapt to a changing data and database world. Gone are the days of solely working on relational databases and the ERD. Heresy you might say, but that is the paradigm shift data architects need to embrace. Here are five observations that support this assertion.
- Data modeling is more fluid. – Data architects live with this reality daily. The traditional waterfall development methodology has given way to many variations. Many force us to choose between being bottlenecks or facilitators. Making this paradigm shift requires data architects to maintain the integrity of our work while delivering artifacts in a way not-so-standard to our methodology. The tide of changes in development cannot be curbed but needs to be embraced by our community. Open your mind and eyes to these new methods adapting your work to be in concert with the development team.
- A new breed of data architect is needed. – Data architects are the go-to data experts in their enterprises. This skillset has great value but new database technologies require us to expand into a new paradigm. The agile NoSQL and big data world has a need for a development team member who happens to be savvy about the principles of data structures and design. Projects entrenched in unstructured and schemaless data do not start with a data model but do need that data architect-like team member who understands the data. This paradigm shifts data architects into a much more technical tool savvy role that has them delivering “data models” in ways to best reach their fellow teammates.
- Data architects need to understand relationships. — Data modeling has long been a profession where data architects cross team and departmental boundaries. The successful data architect plays well with others. There is a paradigm shift that asks us to delve deeper and understand the cause and effects of our involvement in an initiative. Timelines are short. Resources are short. Patience is short. Data architects must respect their teammate’s constraints as much as their own. This means that we must be more open to bargaining and searching for a common workable solution. Spend a few minutes thinking about a coworker’s request before responding. How can you be the best team player?
- It’s more about the story. – I have been a longtime proponent of the data architect being the storyteller of the data. Data architects need to shift their paradigm to embrace more storytelling tools rather than rely solely on the ERD. It is a more purposeful look at our audience and understanding how we can best convey what story their data is telling. Data models definitely have a role. Sometimes it’s as easy as a subject area view or annotations on the model. Other times it is more about the metadata. A good story has setup on what the data is going to speak about; the context on how the data is used and the questions to be asked; the options we have to make this data story a reality; and finally the call to action where we come to understanding on how we will move forward. Learn to tell the story and things will be good.
- Look more to the business. – For most of my career, I have had one foot, maybe a half foot, in the business community. However, my paycheck and boss resided in the IT community. My work involved the business but was targeted to IT. I guess that was because it was the physical data model and DDL that were my primary deliverables. Time marched on and I became a more metadata oriented person. The paradigm shift I am seeing is a move of data architects from just that slight foot in the business door to a more accountable presence with the business. As our work moves beyond the ERD and data models, it expands more in the back end of the project. It is the data architect’s work to deploy and make metadata accessible to the business that will help the enterprise understand the traditional and untraditional data assets. The data architect’s work is transitioning to full lifecycle involvement with a role of helping the enterprise understand their complex expanding data assets.