It's becoming increasingly common for me to walk into the office and be asked I would be able to spare half an hour to install 250GB of RAID 5 disk in a development server.
Like many of our clients, my co-workers are confused by the roles and increasingly grand titles we consultants have given ourselves and its an easy mistake to make - try sorting out DA, DBA (everyone else), DBA (Microsoft), DBAA and IA as potential data related roles on your next project.
Personally I blame developers for this - if they had been satisfied being called Computer Programmers, this confusion would never have arisen. Instead they promoted themselves to Software Engineers, which meant the Systems Analysts had to become Data Architects. The Tech Leads declared themselves Solution Architects and the dustbinmen became Refuse Collection Engineers. We're in a spiral of self promotion and its quite comical sitting in project meetings where everyone declares themself an Architect. Soon there'll be nobody left to do any work.
Anyway, lets start trying to unravel some of this, starting with the inevitable confusion between a DA and a DBA. For the record, DBA and DA are completely different roles.
DBA = Database Administrator. Primarily a technical role, a DBA is responsible for the build, maintenance, performance, scalability and reliability of a database application or a database domain. E.g. you might get a SQL Server DBA or an Oracle DBA but rarely someone who does both well. A good DBA knows the internals of a particular platform inside out and should be a key reference point for anyone developing code against a database. Also the DBA should be intimately involved in the process of turning a logical data model into a physical data model. A SQL Server DBA would likely understand how to build a server for SQL Server RDBMS, Integration Services, Analysis Services, Notification Services and Service Broker. Would know how to install & configure the software. Know how to map software to hardware in the most optimal configuration given the hardware resources available. Would know how to configure storage and memory on each server for the application(s) being run; setup and configure backup and recovery processes for each server and for each type of database being hosted; configure the hardware for high availability and configure the software for replication; understand the data being hosted by the set of applications and performance tune the applications, databases and code accessing that data.
Conchango doesn’t really do “pure” DBAs. They are difficult to sell to clients, who invariably have their own. That means that the work a Conchango DBA would end up doing is very piecemeal – e.g. a short SQL Server health check, or a day performance tuning or a couple of days problem solving here and there. This was frustrating for the DBA and ultimately unsustainable in terms of billability.
Whilst someone picks the resourcing manager up off the floor, and the MD is looking for the blank P45's lets look at the DA role. I'll come back to DBA.
DA = Data Architect. This role is primarily non-technical. Your DA is the person on the project who has overall vision of the flow of data from source to target. They know where to get data from, where it’s going to, how the movement of that data will be accomplished. They’ll understand the project architecture and how data flows between the architectural layers. They will be able to advise on issues of data quality, should be very customer facing, should be able to understand the relationship between data elements across any number of backend systems, understand how that data will be integrated, know how to apply MDM, advise and direct data related development on the project, design data models from conceptual model, through logical data model, through to physical data model. They will use CASE tools to help with database design. All this can be accomplished with little or no overlap on the role of the DBA.
Because Business Intelligence projects are fundamentally data driven, the importance of these roles are fairly well understood within the BI domain. I don't think the difference is quite as well understood in the development domain and as we move towards increasingly non-technical parts of the company, the two acronyms become pretty much interchangable.
It's the same with many of our clients. When a requirement for a DA comes up, the tendency is to push a DBA forward for the role. That's not a great recipe for success, and what tends to happen is a large chunk of analysis and design work gets missed and has to be picked up by other members of the team during development.
Having cleared that up, allow me to complicate it again.
Jeffrey Yao, a regular columnist for SQLServerCentral.com discusses the role of the DBAA in a recent article. You can guess what the additional "A" stands for. And whilst I cringe at the arrival of yet another architect, the role he discusses is perfectly valid. If you can't or won't follow the link, I'll quote a snippet of his definition:
DBAA = Database Administrator Architect. A DBAA is a professional who is responsible for designing a solution framework that maximizes the efficiency of the resources dedicated to the data system administration to meet the business challenges, such as cost, performance, security and regulatory compliance requirements etc.
The main responsibility of a DBAA is to achieve the highest possible ROI with the available resource in the context of the various business requirements. The details of this responsibility may include:
Define the administration scope in terms of targets and risks / costs
Build up an optimized processes model which can maximize the ROI for the current resources
Pioneer in evaluating / choosing the right mix of technology
Explore / create innovative methodology to adapt to business environment.
Act as a facilitator / advisor for the stakeholders to best use the data system / asset.
This is the kind of person you'll get if you request a DBA from Conchango. You can still have your two-day SQL Server health check or an exhaustive examination of your SQL Server 6.5 clustered index strategy but the economics of consultancy requires the DBA to have embraced a more enterprise view of the world, usually within a particular domain (BI being the example I know best). Hopefully that puts the P45 back in the drawer for a while.
OK, nearly there. Things wouldn't be complete unless Microsoft put their own spin on things. So you can now become a Microsoft Certified Architect: Database. Or, as those that have qualified call themselves, DBA. That's Database Architect. Now looking at the curriculum, it suggests really techy DBA to me, but I guess with a $25,000 enrollment fee you're only going to put your best people through this and for that kind of money you're going to need a title to match, so I guess this falls between DBA and DBAA.
The other role mentioned in the opening paragraph is IA - the Information Architect. Information Architects are what Data Architects called themselves when there is more than one on the team and one wants to sound more important than the others.
However, in a last-minute twist, it seems Web Designers aren't happy with their self-promotion to Interactive Media Consultants. They can now also be an Information Architect - defined here as "the process of organising and presenting data to the user in a meaningful, clear and intuitive manner". That could be really confusing. I guess it won't be long before I walk into the office and someone with strange facial hair hands me a pritt-stick, a marker pen, and asks me to arrange pictures on a big piece of card.