I have worked in a wide variety of environments. Simple stand-alone machines, LANs, WANs, minicomputers, world-wide distributed database (early 1980s; before the internet), huge multi-node mainframe environments with large arrays of front-end and back-end minicomputers, plus some supercomputer exposure.
A company hiring a data architect should fully understand the consequences of their choice. Having assumed responsibility for putting major systems back on track because of poor database design, I have seen what the unqualified are capable of doing. Even if you have proper training, it is often experience that keeps you from making poor choices.
Whether the system is small or huge, there are still serious choices that have to be made. If you make the wrong choice it can be very costly to correct the flaw. The performance can degrade because of growth, yet this could have been solved by proper design in the beginning. I've seen people try to apply AI techniques (you are storing facts typically, not interpretations of facts), or over normalize, or under normalize, or .....
Beyond knowing the basics of data structures and the operation of a specific RDBMS, you will need to know optimization techniques - optimization via hardware, normalization, de-normalization, how to plan for system growth, how to efficiently turn OLTP DBs into OLAP DBs, how to migrate multiple sources of data together to form a new database (one might have a person's name as "D. Smith", another "Don Smith", and another "Donald D. Smith", maybe all the same people and maybe not), when do you horizontally or vertically partition a table, ....
You will also need to know how specific programming languages work to efficiently control the data and hopefully develop these controls into stored procedures.
When do you use triggers? When do you use referential integrity? What are the consequences of these and other features? How do you efficiently control access to data that maintains data integrity and security? What is optimistic and pessimistic locking strategies and why would you select one vs the other? How can you store knowledge without really storing the knowledge in a table or doing complex calculations? What do you index and how should the index be structured?
What works well in SqlServer, may not work the same in Oracle, DB2, Sybase, Informix, or MS Access, and vice versa. If you need to intermix RDBMSs, what are the consequences? How do you deal with distributed databases?
Have you considered real-time databases, time-series (regular and irregular time intervals), images (photos), sound clips? How do you search an RDBMS full of images to find pictures containing a llama?
How do you implement linear and non-linear recursion in an RDBMS? Why would you?
There are many things you need to know to be a Data Architect. A good Data Architect is beyond theory and is more into the intuitive aspects of doing the job. Data to a Data Architect is probably far more abstract concept than most people want consider.
Good luck. I wish I was a Data Architect even for a small company. It is a very fun and powerful position.