Wednesday, June 22, 2011

OBIEE + WLS

Something I've been thinking about for quite some time, I think I'm ready to jot them down.

In 10g, anyone with a laptop, free space and time could spin it up. That's awesome for people that want to learn the tool. It's awesome to get things up and running quickly.

The problem though, as I see it, it allows people like me to become "server" admins.

Let's couch it in DBA terms.

I can perform many DBA activities; install the database (now on Linux!), create tablespaces, etc. The basics. What I can't do, or lack right now, is the ability to plan for the future size and growth. I'm sure if I sat down for a little while and thought about it, I could come up with a semi-decent plan, but...

You need production DBAs, no, you want production DBAs doing this work (or at least someone with a fair amount of experience in this arena). My reasoning? I lack that experience of "what could go wrong" because I've never been tasked with, "this is your database, keep it running 24x7x365."

I live in a dream world where I (think) know everything that could go wrong. I don't.

With 11g and the WebLogic Server integration, I see a split beginning.

Now, I know a little bit about a lot of different things (kind of like my DBA skills), but the deeper I get into WLS, the more I realize I don't know much.

A recent episode involving security and SSO configuration has taken a trip through Oracle Virtual Directory (OVD), Oracle Access Manager (OAM) and a bunch of other things I know little about. Am I expected to be an expert in all these things as well? Sure, I'm curious and want to learn as much as I can, but is that a reasonable thing to expect? To me, that sounds like an Identity Management person.

Performance. Where do I even start? Apache seems relatively easy to manage, it screams on my single user system. I've never seen high volumes of traffic consequently I haven't had to build out a server farm. WLS is beastly. There are so many moving pieces, it's tough to know where to start. Is it OPMN, the node managers or is it the BI Server?

I think this is where the split will occur.

You will see a greater delineation of duties in the future. The development side, RPD (mappings), BI Publisher and Analysis (formerly Answers) and the Administrative side, which will handle making sure the server is tuned to peak capacity, SSO works correctly and it's sized appropriately for a given environment.

This is especially true when more and more products get released on the Fusion Middleware (FMW) platform...admin duties will fall to a sysadmin type.

That's my though, not especially well written...in my brain, it sounds great, on the screen, not so much.

7 comments:

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?

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.

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.

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.

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.

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.