Ask Slashdot: Changing Career From OLTP To OLAP Dev 129
First time accepted submitter xby2_arch writes "After spending over 12 years writing OLTP applications (Java EE/JDBC/ORMs), I decided to dabble in the OLAP world. I had decent DB skills, considering most of my previous projects had involved data modeling and coding using Stored Procs, etc. Yet I hadn't designed or implemented any dimensional databases. Luckily for me, I had enough relevant domain knowledge to land a developer job in a data warehousing project. The work was enjoyable enough that it motivated me to spend that extra time and effort I needed to cope with the different dynamics of coding in the OLAP realm. In my past life, data volumes weren't the primary concern (instead, transaction volumes were), here, everything was about data. ETL/Integrations present another set of problems you generally skirt in a typical web/app-tier developer role. All in all, it turned out to be a non-trivial, yet worthwhile transition. I am certain that there are plenty of seasoned developers out there who plan to make a similar move (or have made already), who see data as the next chapter in their careers evolving toward becoming Enterprise Architects. I want to hear what's holding them back, or what helped them move forward. What should be considered a prerequisite to make this switch, and what are the risks, etc.?"
No barrier at all (Score:5, Insightful)
Moving from one specialized type of programming to a closely related type of specialized programming is pretty straightforward. Apply for such a position and you wont suffer compared with other candidates. Or, if your current employer needs something new done, do that new thing. You're not talking about a major career change here. Programming is programming. Even moving from something like standalone application GUI programming for windows in C# to back-end web service programming in C++ on Unix isn't that big a deal. If you can program, you'll pick up the new tech/language/idioms as needed and notice the striking similarity in the work you actually end up doing.
Changed Job (Score:2, Insightful)
So you changed job from one thing to a highly related thing. Great, but why tell us about it?
You totally lost it on '...evolving toward becoming Enterprise Architects', Seems you have been hanging around the buzzword management types for far too long.
Re:Eh? (Score:5, Insightful)
My guess is its a subtle attempt at a philosophical statement that OLTP and OLAP are such wildly different problem domains that it may as well be like trying to horizontally jump from being a fluffer to being a farmer, despite them starting with the same letter and occasionally being confused, at least on /.
Personally I disagree with that viewpoint. You're still in the realm of high performance computing, blah blah blah. They have different enough needs that maybe they need to be separate groups underneath separate supervisors, or at a big enough firm, maybe separate depts, etc, but I'm not seeing a huge fundamental difference. Consider yourself lucky to be at a firm that separates those roles at all. In the last decimal place the problem solving techniques are going to be different, but I'm sure 99.9999% of it is the same, which is probably how a OLTP guy got a OLAP job without the HR filter of "must have 9245 years experience with this specific version of software" filter which theoretically caused this whole discussion. I'm sure a guy who can figure out OLTP can probably figure out OLAP rather quickly and vice versa.
Admittedly I've spent probably a hundred times more career effort on OLAP tasks than OLTP tasks, but very few firms have the luxury of full time personnel for those jobs, so I've spent most of my time doing other stuff.
If anything, I'd say take some more risks. You fail at a OLTP task and customers and sales and marketing scream and data might be lost or corrupted permanently. You fail at a OLAP task and, eh, the TPS reports are released a little later today, we'll survive... Admittedly OLAP stuff is usually a lot more complicated that OLTP, which means you're used to poor / no documentation, maybe you should be worried about doing more documentation of OLAP stuff.
Maybe another way to describe it, is fail once at OLTP and you get fired, fail repeatedly badly enough at OLAP and the company goes out of business before they figure out to fire you?
Re:Define, please? (Score:4, Insightful)
While it's a fair point that Wikipedia is an obvious starting point, I would have to say that the article on OLAP seems to suggest that OLTP is a synonym for OLAP, and the article on OLAP is short but dense. I'm left with an impression that there's a distinction being made between two approaches for constructing end-user interfaces to databases, but what the distinction between OLTP and OLAP is still unclear to me, and I don't have any idea why the distinction would be so significant as to constitute a career transition.
OLAP (Score:3, Insightful)
From my limited experience, the OLAP community is small and/or behind walled gardens, the tools are poor and closed source, and potential employers are only interested if you have experience in *their* BI tools (Pentaho, Microstrategy, Cognos, etc). Microsoft appears to be the only one trying to establish a theoretical basis for BI, but their efforts are starting to show age despite their being so much more that can be done in the field. Finally, you will be misunderstood by the majority of Rails/PHP/Web developers: The same one who think Key-Value stores and NoSQL are the height of modern technology.
That said, BI can be technically satisfying. If you get down to the SQL/MDX you will appreciate what a database can do; which allows questions to be phrased succinctly. I have seen too much code written in procedural languages (Javascript being the worst of them) that are many lines long and run atrociously slow, that can be restated in SQL (or MDX) simply, and run a 1000x faster. I love that fact there are no loops!
From a business perspective, you have much more exposure to management and other departments: You will have improved visibility in the company, and your worth will be inflated - as you will be the one that satisfies management's appetite for more information to help make decisions.
nope. (Score:4, Insightful)
i grew over it.