Data Architect v.s. Business Architect

[yvonneyang]

I am a self-tought IT person in a business area, so I don't have official IT recoginition (and pay) yet but actually doing IT jobs.

Now I am facing a potential internal promotion which may lead to the path of Business Architect/Project Manager. But I've been planning my current position targeting Data Architect and I am not quite there yet (I am also not sure how likely I can get the recognition without official IT background).

I hope to get some advice about the potentials of these two careers in comparison, as well as the barrier-to-enter.

Thanks in advance!

 

[CognosProfessional]

Excellent! Get enrolled in some courses right away for it.

CP

 

[packdragon]

Project Manager is definitely a step away from IT. If you enjoy the stuff you are doing now and are interested in Data Architect, then you should head in that direction. You might not like being Project Manager as much. It's less technical, and you deal a lot more with the clients. You need to be more of a people person than if you were Data Architect.

I too am a self-taught IT person. I'm in a very small company and my role here has shifted dramatically in the last year or so. They recognize what I'm good at and give me more of it. However to make myself a little more "official" I'm planning on getting a certification. In my case, a Microsoft certification since we are a Microsoft house. I don't think it makes me any better at my job, but it will definitely get me some more recognition and credibility as an IT person. You don't have to take classes to get it, just study on your own and pass the tests.

- Zoe, that's ZOH-EEE, get it right please
- Just a little ol' MCP at Solien Technology
-

http://www.solien.com

 

[mutant]

Want to be a data architect, then start with the following concepts:

1) set theory/discrete mathematics
2) first-order logic
3) predicate calculus

Some good books:

1) Weiderhold's Database Design
2) Ullman's Principles of Database and Knowledge-base Systems (2 volumes)
3) Ince's An Introduction to Discrete Mathematics, Formal System Specifications and Z
4) Dijkstra's Predicate Calculus and Program Semantics
5) Ceri's Logic Programming and Databases
6) Fitting's First-order logic and automated theorem proving

I don't recommend you buy these books, unless you are really willing to learn mathematics.

To be really good, you will need to understand the relationship between the two main branches of mathematics: set theory and logic. Relational databases grew out of the set theory branch. If you recall, hierarchical databases came first. Then came network databases, which could represent both network and hierarchical data structures. Relational databases followed and they could represent relational, network or hierarchical designs. The next level beyond relational is deductive databases. These databases can represent deductive, relational, network and hierarchical data structures. Deductive databases grew out of the logic branch of the mathematical tree. Understanding how deductive databases from the logic tree is associated with relational databases on the set theory tree will give you a complete understand to be a great data architect.

I guess the big question for you is: how much do I really want to know? Remember, a data architect is a very power position in the organization and a bad data architect could potentially destroy an organization. A data architect is managing one of the organization's most valuable resources.

 

[yvonneyang]

Thank you for all your responses.

mutant, I guess you may be a true Data Architect. Unfortunately, I don¡¯t see many people with the title out there share the same level of knowledge. That is why I think I can do the job at least as good as they do, or even better.

However, my challenge is that no matter how much knowledge I aquire, our organization (not small but big enough to get simple things complicated) really don't have Data Architect role, therefore I rarely got opportunities to apply the skill. Even when opportunity surfaced as I can see it, I had to educate the whole new concept to other developers and IS management (in a politically correct way), and it took me way more time and effort to sale my idea than actually do it. Going out of my organization where a formal Data Architect is recognized and needed, e.g, in most data warehouse shop, most positioitions posted for Data Architect require prior experience (here comes chicken and egg issue) and formal IT education, although what entails in the job description is to know how to use a software like Erwin, which is no-brainer's game to me.

I fully agree with mutant that a Data Architect should be a very important position (that is also why I am interested in it). I was a astrophysics major, and for a long time, I suspect there must be a school of theories for data achitecture and database design as you suggested. It is not industrial programmer's expertise, but mathematitian's, and should be applied by business users (domain expert) with solid mathematical background. Obviously, my view hasn't been shared by the industry yet....

Any practical suggestions for me to move ahead? I have no problem for self-education or even getting a certificate if it is necessary, but as I said, there is more than that to get the job. Maybe it's just "as good as it gets".

As of Business Architect, it seems less "famous" than Data Architect now, and its reponsibilities often the time are categorized under Project Manager, which is a loosely used term nowadays. Again, as for organizing and designing data models, I believe there is, or will be, intellegence surrounding organizing and designing business models. But for now, true Business Architect seems even more remote than Data Architect in the job market. Like packdragon put it, what it is now is a step away from IT, but maybe also a stepping stone to higher managerial role to some people?

I appreciate more comments, and it is nice to chat with your guys!

 

[mutant]

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.

 

[yvonneyang]

Thank you, mutant,

You seem to address more of physical data modeling techniques now. I agree that a data architect should have a wide range of knowledge about RDMBS, but should it also be relying upon DBA's expertise? Most businesses and information systems operating today don't even have a good logical model, at least it is the case in my org., and it is why every system implementation and modification was so costly...

Also, I only see big companies requiring Data Architect. Small companies probably burry the duty under system analyst or DBA, or whoever end up actually doing it, with or without knowing what he/she is doing. Is my observation right?

I'd like to hear how you moved to (or gain yourself a title of) Data Architect from what you were doing prior to it, if you don't mind.

Thanks,

 

[yvonneyang]

Thank you, mutant,

You seem to address more of physical data modeling techniques now. I agree that a data architect should have a wide range of knowledge about RDMBS, but should it also be relying upon DBA's expertise? Most businesses and information systems operating today don't even have a good logical model, at least it is the case in my org., and it is why every system implementation and modification was so costly...

Also, I only see big companies requiring Data Architect. Small companies probably burry the duty under system analyst or DBA, or whoever ends up actually doing it, with or without knowing what he/she is doing. Is my observation right?

I'd like to hear how you moved to (or gained yourself a title of) Data Architect from what you were doing prior to it, if you don't mind.

Thanks,

 

[mutant]

Migrating to Data Architect? I never held that title. I am more at the level of Data Mystic.

Beyond a BS and MS in Computer Science with a heavy emphasis in Mathematics, I started as project lead on a world-wide distributed database project that was failing by the previous incumbant's inability. Also, helped with some stand-alone CP/M (pre-DOS and IBM PC) database projects. Worked in a huge data center supporting E911 and related OLTP systems on a multi-node mainframe environment - as a resource manager (real cool, yet stressful, position). Picked up another failed client/server project and put it back on track. Stayed with that organization and was able to pretty much do whatever I wanted. Killed off another of their failed projects and replaced it with this super-optimized db design and integrated an Excel front-end for their auditors to do read-only access. Did some really spiffy multi-dimensional databases, but could never get funding to put into production. Then was enticed off to help with real-time and a very complex OLTP RDMBS on the Sun platform - realized within six months that the person that designed and lead the project didn't have a clue about db design. Currently supporting DB2 on the mainframe - systems software position.

Most of my knowledge with data goes back to my college experience. My major project in college was optimizing conjunctive and disjunctive queries on a massively parallel computer.

Even having the knowledge about Data Architecture doesn't guarantee that you will find a position to apply the knowledge. I have been pretty happy doing what I have done, with the few exceptions of having to work for some really idiots for managers. With my contacts, I could probably find a position more aligned to Data Architect if I wanted a change. Most likely, I will do this system software stuff on the mainframe for a couple more years - it has it's own challenges and builds up a completely different set of skills that are hard to get. Not many mainframe shops that are willing to train you well, but there are plenty that will hire you if you are skilled.