February 18, 2008 at 8:10 am
The articles on agile development are helping me understand the new product our company is developing. Coming from a simpler world with very poorly normalized databases, it's been a stretch to understand this new approach ( object oriented C# .net no stored procedures. Database viewed as a Persistence Layer -- select/update/insert/delete statements are basically adhoc generated by objects ) The developers and data architect hired to develop this new product ( browser GUI, sql backend ) constitute a new team within our company so we have the possibility that most of the legacy product team will be on the street within 2 years. Be that as it may the articles on this "agile" site are helping me see the advantages -- you can switch database vendors much more easily ( in theory ). Developers apparently need to know very little about the underlying relational database. DBAs may very well have a much smaller role -- in our case there really isn't a DBA at all except what I do in the area of backups and log shipping. The schema, indexes etc were all created by the development team.
If this is the future, those who want to be database professionals will ignore it at their peril.
http://www.agiledata.org/essays/culturalImpedanceMismatch.html
February 19, 2008 at 6:42 am
This topic must be a little on the theoretical side for database folks busy trying to survive day to day. I thought this forum would be less about technical details and more high-level. It may be that most are not running into significant changes in the way data professionals function in their organizations -- yet. Based upon the repetition of basic questions posted, it does seem that companies are trying to get by without DBAs, basically throwing the responsibility on a developer, systems staffer, etc.
February 19, 2008 at 7:14 am
( object oriented C# .net no stored procedures. Database viewed as a Persistence Layer -- select/update/insert/delete statements are basically adhoc generated by objects )
Having read only summary articles regarding "Agile" development, it seemd to me to be the method I had been using for some time.
I never read where not using stored procedures was a part of the definition.
February 19, 2008 at 7:27 am
There have been a lot of schools of Agile. David Poole recently wrote a fairly good primer on Agile development from the perspective of a DBA.
The thing is - like with many new things - there are right ways and wrong ways to implement them. Agile was conceived so that there's less of a disconnect between the user and the project requirements, so that the user essentially gets a better product. However - unfortunately, there are some who manage to take that method and twist it into "let the developers do whatever they want, and scr** the data layer". Of course - these were also the same schmoes putting out garbage code which would wreck a database in the old waterfall days as well.
I agree that there are lots of organizations with faulty understandings of Agile development and the tools out there, hoping to reduce or eliminate the DBA function. But it's a flaw in their thinking, and ultimately it's giong to lead to a failure of the Agile process, since they will often end up with something that doesn't scale or grow well since its data foundation is so unstable.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
February 19, 2008 at 7:45 am
I can't figure why any company would want to be able to get by without needing a DBA. They might eliminate the person with that title, but it isn't possible to eliminate the ROLE. Regardless of the person's title that is acting as the DBA, they will still have to be capable of performing the functions of the DBA.
It's always seemed to be the size and complexity of the db applications in use that would determine whether or not a company would have a person as DBA in house. Some organizations couldn't possibly get by without having a DBA with couple of assistants. Others will have a DBA that is also a developer. Still others will solely depend on their vendor(s) to keep them out of trouble.
Those aren't the only considerations to be considered. The data that is being secured often determines the organizational structure of the IT department. Do you trust your developers with your financial data, or with your payroll data? Do you have to secure your customer's records? Are you going to perform all of the security functions with C#?
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply