May 15, 2014 at 1:22 pm
I am having a lively debate at my company on the roles and responsibilities of DBA vs Information Architects (IA).
We agree IA's define source/destination; requirements and other items.
We disagree if IA's should be over DBA or the other way around when it comes to database design.
My take is that since I support it; i (we the team) should review their work and get an understanding of what they are trying to accomplish. Here, the DBA's support all databases (over 1000 sql instances). While IA's work on 4 to 10 SQL instances. IA take is the DBA are there to push the button, and help trouble shoot performance issues.
If you are an IA or DBA : and you have IA's and DBA's in your company : i would LOVE to hear what roles/resp are over lapped and where the line in the sand is.
Thanks!
Joe
May 15, 2014 at 4:13 pm
In general, if you have the name Architect in your role, I would assume you're, at least potentially, a step up over the DBA. I filled that role (didn't have the title though) at my last job and it meant I worked not just designing systems, but as a consultant to the DBAs, helping them with many of the more difficult problems. But, I'm wondering if your Information Architects are in the same realm. If the DBA is going to help with tuning a design instead of you helping them tune a design, we might be using the term Architect a little differently.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 15, 2014 at 4:39 pm
See, that is the danger of titles. They don't know the SQL Server technology as well. They don't know the underlying hardware, network, ect. The DBA team (here) has the expertise in the technology realm. What we don't have is the time to understand each database/schema/table as well as they do. Our IA's are responsible for 2 systems with 30 or so databases. There are 3 or 4 IA. The dba team (3 project/5 production) have over 100 systems and over 1000 sql instances. They know the business reason and function of the fields in the tables. My dba team implements their design and the conflict comes in when we start asking the questions of "why is it done that way?". We are also the one that redesigns indexes, maintenance jobs ... and their SQL statements / stats / ect when they can't meet sla for processes.
I hope there are many other replys. What i think i will find is that DBA (developer/project/production/system) has as many wide ranging roles and responsibilities as IA. Here, project DBA only have domain over Dev once in production. Before production, Proj DBA have full control over all levels. Installs/configuaration/tuning/ specs/ maintenance/ ect. Production DBA have the oppisite. On a day to day basis, much different roles. BUT, if anything in production breaks, all hands on deck. both the Production DBA and Project dba responsbile for the system work hand in hand to resolve the issue.
What I see, i think, is there should be both a division of duties and understanding of levels. You can have jr IA and jr DBA... sr IA, sr DBA. One position should not look down on the other as "i have this title" or "do what i say".
As an IA : where did your responsibilty begin? and end? Was there a hand off of the data structures and processes for promotion from dev - test - (qa/uat) - prod?
thx!
May 15, 2014 at 5:29 pm
Oh, sounds like what we used to call the Logical Modeling Team. And **** NO they weren't in charge of us! When I started at the company, the DBAs did backups. I came out of development originally, so, as a DBA, I absolutely believed in understanding what the business requirements were, what the development paradigm was, their code base, etc. The Modeling Team were the only ones who interfaced with the business at the data level. I changed that. Pretty much to the point that we largely eliminated the Modeling Team. They almost literally were like that guy in Office Space, he'd talk to the business people and then talk to the DBAs & Developers. He had people skills doggone it! Ha!
So no. I was originally titled just a DBA. Then, after a lot of lobbying, I became a Development DBA. Then, I was responsible for the system all the way to Production. After the successful deployment, I handed it off to the production DBAs who handled backups, monitoring, alerting and first level troubleshooting. I was second level troubleshooting. As I moved into the architect position, the job was basically the same, but instead of 8-10 databases under development, I was involved with much of the data decisions in the company. I really loved that job. But I love my new one more.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply