Architect vs. Administrator

  • I suppose this should be under the career section, but I couldn't decide what sub-category to put it under.  oh well.
      I need to hire someone to work in a (.net) programming team who is an expert at data modelling, and has the ability to implement schemas and stored procedures via SQL.  Simply from my experience, I expect this person to have a programming background.  [Perhaps] Interestingly, I am not nearly as concerned with the individual's ability to maintain the database or adminster it once it is in production; performing backups, writing DTS packages, utilizing OLAP, etc.  I already have somebody who does that (DBA), along with a portion of the data modelling.  What I think I need is a Data[base] Architect.  Is that what I should say in the job posting?
      I'm curious to hear people's thoughts on this.  For years I have filled this role (Architect), and was always referred to as a DBA.  What do you think?
     
     
  • I would advertise for a Senior DBA/Database Architect. Explain the duties clearly in the job section. You'll find a lot of folks bearing either or both titles who do schema design, requirements analysis, etc.

    K. Brian Kelley
    @kbriankelley

  • So, if one were to rank these positions, would you put a Database Architect above a generic DBA?  I'm not trying to supplant my current DBA, just augment, with a different set of skills.
     
     
     
  • That's a hard call when it comes to DBAs/data architects but typically an architect is thought of as above an administrator.

    K. Brian Kelley
    @kbriankelley

  •   I find this interesting and I'm curious to know if anybody else has input. 
      The way I see it, the typical DBA (a position I'll soon be resuming) is more technical and familiar with the specifics of a certain product.  He or she would be called upon to monitor system performance, respond to crashes/outages/lock-ups, and maintain proper backups.  Mostly an independant role without much group interaction.
      On the other hand, I envision the Data Architect working with users and programmers, bridging the gap from requirements to implementation, educating and coaching developers, while working hand in hand with DBAs to ensure optimal system performance.  Requiring a good deal of human interaction, with more logical ability that is less measurable. 
      Does this sound accurate?  And does the abstract ability of the Architect make him or her harder to find?
     
     
  • I think you are right on the money with your thinking.

    I think of a Data Architect as someone that will interact with business users and business analysts in the logical data modelling phase. That person will then turn that logical model into a physical model which will be implemented and managed by a DBA.

    In a large organisation, they will also be responsible for the enterprise data model and policies. They are responsible for ensuring that new systems conform to these policies and encourage the reuse of enterprise's data assets. If the organisation is large enough they may be referred to as an Enterprise Data Architect.

    This is one of the few examples in the new world of "Architect" job descriptions (I've been in this business for over 20 years) that makes sense. For instance, I've no idea what an "Enterprise Architect" does, though I admit this may just be ignorance on my part.

  • Most "enterprise" architects are really application architects, meaning they design application systems. Infrastructure architects (like me) design the physical structure, servers, security, etc. Network architects (of which some infrastructure architects are also) design the communications systems. For instance, the gentlemen which sits next to me at work is the network architect. Together we combine to design the security architecture, especially at the perimeter.

    K. Brian Kelley
    @kbriankelley

  • I've done a fair amount of browsing around the web and books on the subject of "architect" within IT. Basically, there are so many different definitions and interpretations that the term is meaningless. You may want to post for 'administrator/architect' and then just spell out what the actual duties are for your position.

    The one common thread seems to be that architects are designers, while administrators are more concerned with operations and maintaining a viable environment/capability. Both of these include doing "redesign," "evolution" and "adaptation" duties in the design arena.

    I've seen the term "data architect" mean anything from a data administrator to an enterprise data modeler to an ETL/EAI/EII/replication technician.

    David Lathrop
    DBA
    WA Dept of Health

  • Hi Josh,

    I wrote some about differing DBA roles at http://sqlservercentral.com/cs/blogs/andy_leonard/archive/2005/07/30/86.aspx. Although it's difficult to generalize, I think you're looking for more of what I describe as a Developer DBA.

    I think the advice above is excellent: Mark makes some good points, and you can never go wrong listening to someone as smart as Brian Kelley!

    Good luck in your search.

    :{> Andy

    Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics

  • you can never go wrong listening to someone as smart as Brian Kelley!

    Any chance you can convince my kids of this?

    K. Brian Kelley
    @kbriankelley

  • I see that many countries still have these jobs filled by different person.

    Here in Brazil the DBAs normaly do both jobs with the same frequency.

    It´s impressive to me how things go different in the same job from a country to other.

     

    tks all

  • Any chance you can convince my kids of this?

    LOL! I'll trade you - you convince my kids and I'll convince yours!

    Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics

  • This is an interesting thread. My main focus is what I consider to be a database or data tier developer. That's probably about 15% true modeling and architecture, about 80% coding in T-SQL, and about 5% managing my product's metadata and traditional DB administrator tasks (backups, logins, permissions, maintenance, etc.) I never know what to call that.

    The data modeling and architecture is certainly the most delicate and important, because if you don't get that right, the project dies a slow death. But that's a pretty small slice of my time. The coding is also important, but there are usually different ways to code the same sproc, function, trigger, constraint, etc. My project also uses a ton of metadata that interacts with the code to expand functionality, that is tricky to get and keep right. But you never see job descriptions that deal with these terms or concepts.

    We're still in SQL Server 2000 (with an archaic JDBC access layer) but if we were in .Net, I'd also focus on modeling the low-level business data objects and their getters and setters, to optimize the data access.

    Perhaps the essential distinction, IMO, is that an architect or a developer does a fixed quantity of work in building or modifying a fixed set of functionality, and is then finished. Contrast an administrator, who has an ongoing operator role that will always be necessary for the maintenance and operation of a DB system (at least one of any size.)

  • you can never go wrong listening to someone as smart as Brian Kelley!

    I'm still trying to decide if I should listen to a pink-bunny-eared ferret! 
     
  • My humble opinion!

    I think the duties of a Database Architect and Database Administrator were at one time all held under the role of DBA. Since then, IT industry has grown and realized that there were way too many responsibilities on what they called their DBA. So the duties were then split sort of, one dealing more with the architecture of the databases from design through interaction with applications written for the particular business. The architect working more closely with the business analysts as well as interacting with the applications developers to be sure that development of applications and their interaction with databases goes smoothly and in line with standards and performance.  The administrator then can concentrate more on maintenance, performance, security, and uptime of the databases from a production standpoint knowing that a database architect was completely involved in the design of what is being move to production and not having to worry too much that the database(s) were designed by developers or developer/dba.

    I think that a database architect is concerned with all these things as well, and is designing the databases at the development level to be inline with standards and expectations of the database administrator for release to production. I think that the architect was once an administrator and has gone through the ranks of junior DBA, Senior DBA, and has now moved into a position of Database Architect.

    Merrill Nelson | Senior Database Architect

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply