“Chief architect” has long held meaning outside of the realm of the engineering and construction of physical buildings. Yet from managing different technologies or systems to interacting with and pleasing a range of different stakeholders, they still have many of the same challenges. And today’s chief architects are facing more of them than ever before in trying to build a high-quality system that will allow their company to seamlessly make the switch into the age of AI.
One of the most challenging aspects of building an AI stack is that, well — there isn’t one right way to do it. It depends heavily on, naturally, the nature of the business. But it also depends on some more personal characteristics — some architects are more visionary (focused on what’s to come) vs. pragmatic. Some are more focused on the new-and-shiny, while others lean more towards stability.
Here’s a look at the different types of data architects out there and how each one might approach the creation of a central data platform differently depending on their tendencies.
The Sensitive One
The Sensitive data architect approaches the needs of the platform by assessing the needs of each individual user. (S)he would consider each subgroup or each persona (data analysts, data scientists, software engineers, etc.) and choose a solution for each of those that best addresses their specific needs.
If there’s one thing the Geometrician likes, it’s diagrams and compartmentalizing. So for an approach to a data platform, would focus on splitting it into specific components and choosing the best solution for each one of those individual components. That might mean finding the best solution for data cleaning and wrangling, then finding the best solution for model building, the best solution for putting in production, etc.
Long-term sustainability is the name of the game for The Keeper. That is, building a data platform that will work for now, but also for whatever happens later. (S)he is also concerned with the sustainability of the assets built on the platform — that is, generally, how can rework be minimized? For example, a Keeper would tend to favor architecture that creates containers for models in order to better facilitate their long-term preservation.
The Pragmatic data architect is driven by immediate success. For him or her, the right way to build a platform is focusing on specific use cases (that are actually being worked on now — not that might, possibly, someday, happen in the future), and building the platform out incrementally based on each use case.
For The Holistic, the focus is always on the quality of integration and synergies between the software and the humans using it. For example, a Holistic would ask questions like: how can we build something to avoid unnecessary work? How can we improve the work being done by each team member by enabling them to better divide and conquer? This type of data architect is most likely to look for a solution that bucks the more traditional functional diagrams and tools.
OK, So Is There a Best Way?
You may not like this answer, but in a nutshell: no. Again, it really depends on the type of business and the product or service they are working to deliver as well as on the structure of the overall organization. For example, there might be some legitimate cases where The Geometrician’s approach makes the most sense, splitting up the data pipeline and addressing each piece separately.
However, that being said, my experience in working with organizations (especially at the high level, like talking to the CEO or the CIO) is that overall philosophies and objectives most closely align with those of The Holistic. That’s because this tends to be the most productive in terms of aligning the organization around data initiatives. But in general, I’d also say that taking a little bit of inspiration from each of these different types is a good approach — after all, the very wise Euripides said “The best and safest thing is to keep a balance in your life.” And if he were alive today, he’d probably also say it applies to the enterprise.