Post reply

Guidance required for becoming Database Architect

  • January 6, 2016 at 5:44 am

    #307430

    Hi,

    I am currently working as SQL Server Developer.

    I have total 8 years of experience as SQL Server Developer.

    Worked on SSRS,SSIS, Data modeling, performance tuning and optimization

    I want to lead my carrier path to become Database Architect.

    Can you please give suggestion what steps should I take to achieve my goal.

    Also which books will be helpful for me.

    Thanks,

    Bhushan

  • January 6, 2016 at 7:19 am

    #1849843

    It sounds like you have substantial experience with the Microsoft technology stack, so you should have that base covered. To become more of a database architect you want to read books that take a step back from programming and internals and instead discuss database technology more generally in terms of the full lifecycle enterprise solutions, including things like: data warehousing, ETL and data access frameworks, non-Microsoft technology (Oracle, Hadoop, MongoDB), and probably even project lifecycle methodologies like SCRUM and DevOps. This is what you do, if you want to be a real database architect.

    Books published by the Kimball Group or Bill Inmon are definitive when it comes to data warehousing. You'll want to become familiar with both approaches.

    http://www.amazon.com/Ralph-Kimball/e/B000AP5ULY/

    http://www.amazon.com/s/ref=dp_byline_sr_book_1?ie=UTF8&field-author=W.+H.+Inmon&search-alias=books&text=W.+H.+Inmon&sort=relevancerank

    Also, O'Reilly publishes a lot of good books; too many to mention, but remember to focus on books that cover the entire platform and not just programming.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • January 6, 2016 at 8:47 am

    #1849884

    You have the basic tools to do it if that's what you want in the MS Stack. Experience with database technologies outside of SQL Server and SQL in general would help, Oracle and/or MySQL would be helpful but they're all similar enough that the differences are more technical than methodology. On that note try to understand the overall business impact of changes you are making as you'll be expected to interface more with business users and likely interact across multiple technologies in and out of the microsoft stack with results likely measured more in terms of business results than technical results.

Viewing 3 posts - 1 through 2 (of 2 total)

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