I fully agree upon this. In comparison with OBIEE 10g the complexity has increased a lot. As an OBIEE specialist it will be challenging (or impossible?) to fully understand the broad range of products and technologies which are related to OBIEE 11g. So yes, you may need a single specialist for each domain. But my question is: will this also fit in your client's budget?
 

A very good question.

My suspicion is that as the Fusion products get released and adopted, OBIEE will be a very valuable piece of all that, but the administrative side, the WLS side, will simply shift and may no longer be an OBIEE specialist skill. Obviously it's great if you have that skill, and many of us will have some of them having moved from 10g to 11g; I bet people who take up OBIEE starting with 11g, will have specific roles and won't get much exposure to the administrative side of things.

chet
 

All of these various components are going through typical product life cycles, and the people with knowledge of them follow along. There is not a one-to-one correlation of the functional jobs and what companies think the functional jobs should be.

So you wind up with a lot of people who have some idea of how each thing should work, and a few people who actually understand the things. At the beginning, the vendor will push out some technical knowledge along with the marketing spiel, training some number of technical people in standard ways of getting the thing working. Some very small number of external people will have the knowledge and skill to figure it out (the Mark Rittmans of the world), and they become in demand. Seeing the demand, a lot of flaky consultants will also put themselves out as experts, which they comparatively are if they've managed to get it working once on their laptops.

Meanwhile, customers will be making their own staffing decisions based on the spiel, which often translates into overworked IT or db people getting tasked, sometimes with some appropriate training. Early in a product life cycle, you simply won't have anyone who is the equivalent of an experienced production dba (and you see the funny job postings from hr droids who don't get it, at companies who try and fail to get it working or working well).

So yes, you have a delineation of duties, but the reality doesn't support it.

And of course, some products just aren't made right. SSO as implemented for all the online Oracle corp uses, for example - it simply forces Single when it should have Multiple.

On the train this morning, I overheard a funny exchange. The fellow apparently is IT support at a large fast-food organization headquarters, and had pointed out that the builds the PC group was making were failing on many PC's, so he asked to watch them do a build, just so they could figure out what was wrong. This apparently provoked a huge turf war. It was entertaining to me because I've seen the exact same thing happen for a mass Oracle client roll-out a decade ago. The problems never change, just the product details, and yes, the tech stack is getting more complex. Hiding the complexity in a cloud can only make it worse.

Kudos to people who share their knowledge on the net, it's the only thing working against these kinds of problems. There's a downside to cookbooking (allowing people to do tasks without understanding), but if it at least gives people who care to figure it out the ability to figure it out, that's good too.

It's unfortunate that there is an economic advantage perceived by vendors to not share the knowledge freely, accurately and concisely. Making certifications a profit center sure doesn't help either.
 

I think your split isn't coming, it's already here. :) It's been my experience that if it has "Oracle" on it, eventually someone with authority will, rightly or wrongly, decide that it's their DBAs' job to admin it. If the installer has an Oracle splash screen, the sysadmin tasked with installing the software is eventually going to stop by the DBA's desk and demand^W gently, politely ask for help. And regardless of which link in the chain eventually breaks (SSO/IDM, OAS/Weblogic server, app, RDBMS), the "Oracle admins" DBAs will be tasked to look at it first.

Fortunately, I mostly groove on that sort of stuff, and like learning how all of these pieces are glued together. It still gets a little frustrating, though, when I'm repeatedly told that "App/service XYZ is down again," when in fact a flaky pile of software further up the chain is just preventing access to a reliable service that's humming merrily away. :)

Those magical, end-to-end-of-stack-expert job descriptions Joel mentions are a hoot. I keep waiting to see if someone's managed to slip "...and must be a ballerina" into the requirements.
 

@joel

You really should do a guest post...I love hearing your thoughts.

I agree with much of what you say.

I just wonder, in the larger organizations especially, if WLS will become the centerpiece of the "middle" layer much like the database is at the "data" layer. OBIEE in particular will become just a piece of that "middle" - perhaps akin to APEX.

I certainly hope I fall into the camp that will learn it, through whatever means necessary, and become "good enough," just like I can manage a database "well enough" for smaller organizations.
 

@john

you should do a guest post too...oh wait, you already did. :)

i've noticed that as well, and not always in a good way. it makes sense though, databases, especially Oracle are incredibly complex and require very smart people to properly administer.

why wouldn't you ask for their help?

I'm certainly glad I have a broad background with Oracle products. I've played with OAS, the DB and other components. While I'm not an expert at any one of them, having exposure to them has made this a little easier.
 

Who needs guest posts, that's what hijacking comments is for! ;-)

I don't blog much because a blog post appears to me to be the root of a discussion hierarchy, and I find the back-and-forth of a network discussion much more interesting. Put another way, I'm reactive in my opinions.