The job as a DBA is the job. That's been my view for a long time, which is why I am always concerned about the staff when I interview. The people I work with make the job good or bad. I can always handle the job, which is often very similar in many organizations. I might do more tuning in one place, or more infrastructure management in another, write more reports than the last gig, but the skills and techniques are very similar in many positions.
I have also found at some, maybe many, companies there isn't always a full time need for a DBA, or architect, modeler, etc. Instead, there are periodic ongoing needs for those skills. At one position, I was negotiating a deal to only be employed 3 days a week, planning on spending the other two at another company consulting. I was about ready to implement my plan when the first company lost funding and went out of business. Since then, most companies haven't entertained the idea, even when there wasn't necessarily a full time need for a DBA position.
I thought back to that job when I read this piece on flash organizations, where the idea is to bring people together for a project or (relatively) short period of time to do some work. I have seen similar project teams in larger organizations, but those teams are limited to the talent within the company. A Flash team would bring contractors together for a project, perhaps with employees. Certainly consultants or contractors are sometimes used today, but they often aren't seen as part of the "team", or at least, they aren't treated that way. That disparate treatment often means that there aren't necessarily shared goals or the same focus among everyone in the team.
If you'd asked me to consider flash teams a decade ago, I wouldn't have thought that we had the management maturity to accept outside help for many types of work. However, the advent of cloud services (and more adoption than I would have thought), along with the use of pull requests and agile development services have me wondering if this might not be the type of things we see more often, especially for software. I could even see this for specialized skills, such as data science and ML model training.
I do think that this type of work is harder for data professionals to walk into, since intimate knowledge of the meaning of data fields and their relationships is important. Coming up to speed on the way a business uses data can be easy when you start,but there are often edge cases and the complex ways in which business people often use data takes more time. I would expect time spent as a flash data professional would be front loaded in trying to gain an understanding of the environment. However, perhaps that would mean that there would be better documentation for future projects. Maybe even an ER diagram or two that actually matched the database system.
Steve Jones from SQLServerCentral.comJoin the debate, and respond to today's editorial on the forums
