There’s quite a bit of hubbub over this. Meanwhile, life continues moving forward on its inevitable pace and deliberate path. The article that James writes also moves onwards, in a complete 90 degree tangent. He goes on to comment about Facebook’s poor usability, performance issues and fuzzy direction in what the company, the Facebook application, its platform and competency of its engineers. I thought the article would be coherent enough to follow along a statement, the background of this statement, the arguments to support this statement and be open for comments that support or rebut this statement. I find none of the above and ultimately deemed the article quite useless.

First of all, write a coherent article. Second, if you want privacy, flee to a mountain, disconnect yourself from the world, build a log cabin and live off the land while keeping company with your pet dog. Or better yet, do an “Into the Wild” affair and make do like Christopher McCandless did.

There are more things to be concerned about than the privacy of your personal information on Facebook. The government, the bank, the hospital, the department store, the coffee shop, the library, the cable company, the wireless carrier, the gentleman’s club, the bar, the grocery store, anywhere you’ve ever visited and dropped your credit card information or filled a form out has your personal information. And the things they do with it are no different than what Facebook does with it: sell advertising and market things to you. What you choose to do with all this traditional and electronic spam is up to you. You are all big adults now so choose how to handle this. There’s no nefarious plot that any of these organizations are going to abuse your personal information. To be honest, how much or how little information you place in the Internet, on sites like Facebook, will dictate how badly you get spammed.

Take your heads out of the sand collectively and just start living life. You can’t be concerned on trivial things like privacy data when there’s a world out there begging you to explore it in a physical human nature, not through bits and bytes in the ethernet. If you can’t stand to be without Facebook or Twitter, you are just as vulnerable to The Matrix as the Wachowski brothers’ movie makes you out to be. Time to unplug!

I haven’t had a chance to revise my resume in quite some time. It was up on the older blog site before I went and revamped this one. In most cases, I haven’t really needed to use a resume for my job placements in about 7 years. Most positions came by way of referral, which is a good thing. It’s also a risky thing because that indicates your reputation sort of precedes you in some ways, good or bad. And most of it has come from my time dabbling with OBIEE.

In the end, I’d invite you to browse around my LinkedIn profile for further information and detail on my past experience as well as what I’m currently working on.

LinkedIn

Since I do work for a social networking company, there are certain things I can embrace about the value of networking. I also have a certain amount of hesitation regarding privacy or the right to privacy. LinkedIn is similar in a way to my current employer in that it’s better to explore the network of professional contacts that you’ve had the fortune of meeting, working and interacting with along the way. And there’s a cookie crumb trail of where you have been that can now be tracked and, to some degree, verified based on the profile detail. This will do more for understanding any potential candidate’s work experience and abilities & skill sets than a simple resume.

The world is small, especially in specific concentrations of our field of Business Intelligence. If I don’t know someone who’s worked with OBIEE that I come across, I can surely find out in a short manner of time through contacts and the network they circulate in. And if you’re persistent enough, you just might reach out and get a better sense of a candidate than what is stated on a 2 page resume. Resumes can be doctored quite nicely. Hell, even LinkedIn recommendations can be misleading. There’s no better way than to make your own judgement based on all the intel you can gather. Hopefully the combination of resumes and profiles can help one make a better decision in who they choose to work with on their next project or job requirement.

It’s been a while since I last posted about anything remotely related to OBIEE or Microstrategy. I’ve had almost a year of picking up the Microstrategy side of the technology and gone through some headaches to get more accustomed to its quirks, strengths, weaknesses and workarounds.

Most of this post will deal with the Microstrategy 8 platform, not the 9 release that has been out about a year now. There are some features of 9 that will apparently level the playing field but I’ll go through the obvious things (to those who know one or the other or both platforms) first.

1) Multi-source: Apparently Microstrategy 8 only is able to leverage one database source to run OLAP queries from. In OBIEE (even before the Oracle acquisition when it was still Siebel Analytics), one of the main benefits it incorporated way back in 2003 was the ability to derive analytics through multi-sourcing. This meant that if you had a Data Warehouse built and you wanted to join some tables to a second (or third) source (such as an Excel spreadsheet with corresponding correct key joins), OBIEE would easily do this for you. All the work, however, occurs at the server level and this spells bottleneck if it needs to go against 2 sources of very large datasets. After all, OBIEE design necessitated the fact that you need to push as much of the analytics processing down to the database level. With Microstrategy 8, you would essentially need to go through the data migration process of getting everything into a consolidated Data Warehouse for this to happen. Microstrategy 9, introduced in 2009, has finally rectified the issue of multi-source and allows you to do this.

2) Temp Table shenanigans: Microstrategy 8 LOVES to create temporary database tables to distribute some of the processing of the data into smaller query chunks. The thought process is that if a bunch of smaller queries were pushed to the database level, they would be processed faster and datasets would be returned back to the iServer analytical engine to render the results back to the user. The problem is that the final query (or queries) is dependent on the temp tables being created in the first place. There is a sequential process that seems less effective in terms of processing fairly large queries. Of course, if you design your Data Warehouses with too many records in your fact table, you deserve to suffer long query times! (Remember to design for efficiency also!) OBIEE is a little more straightforward in terms of generating the appropriate queries (it will split up into multiple parallel queries for returning different levels of aggregated metrics if your report is displaying granular, sub-totals and grand totals). And you don’t have to follow the temp table madness that can occur with Microstrategy queries, where I’ve seen up to 8 temp tables built to serve the purpose of a single report. Clean up of these temp tables can get ugly if there aren’t taken care of. (I don’t believe Microstrategy actually drops them once they have served a dashboard/report purpose.)

3) Visualizations: Since one of the strengths of Microstrategy is in the visualization of dashboards/reports, this means that depending on the deployment type of dashboard (you can have interactive dynamic HTML or Flash versions as well), the rendering of all permutations of data (meaning for all the prompted values on a dashboard, it renders all of the combinations and sends the XML data to the web client) can lead to some heavy wait times on the iServer engine side to complete before the results are displayed to the end-user. This is part of the pixel-perfect features that Microstrategy touts as a prime selling point. With this, however, I believe the flexibility adds much to the complexity of some dashboard/report designs that users and developers can go absolutely nuts developing complex dashboards with a huge amount of permutations of data that can be shown on the it. Since OBIEE is a lot more rigid in the way it renders the dashboards/reports (you only have the standard UI that OBIEE provides or you can hit the highway), and by using dashboard prompts, you are actually requerying the Data Warehouse to generate another visualization of the data that has been selected, it’s actually more efficient in “breaking things up” from a rendering perspective.

I’ve got a few more points to make but I think I’ll save that for another time before boring you folks with the details. Again, please post your comments and criticisms of my observations. I welcome them all.

Having had a little more exposure to the Microstrategy application stack, specifically Version 8, I find they are fairly similar platforms. The differences end up being how to create Microstrategy (MSTR) Projects, which are essentially Logical Models within the Business layer in OBIEE. Metrics & Facts take on slightly different meanings within the MSTR world as they are fairly flexible in nature. The organization of things in multiple folders within an MSTR Project is a little daunting and confusing at first but makes some sense if you just focus on everything relative to the Project itself. If you extend the concept of MSTR Projects to a single OBIEE Subject Area, then you can make the association.

The MSTR analytical engine is fairly similar in that it will try to determine the most optimal query to construct based on the definition of the MSTR Project objects. The architecture of the physical data model requires a little bit of a different approach.

One thing I started to investigate was the fact that Microstrategy likes to snowflake tables off dimensions. This is a little different than the nearly complete normalization of dimension tables within the Oracle Business Analytics Warehouse data model. I’m going under limited exposure on the reasons behind this but I believe there are cases where snowflaking, let’s say, a type table off a dimension may lead to some design approaches to the fact that that make it easier later on to create aggregates that join to the snowflake table at a higher level of granularity than referencing the dimension table. The MSTR analytical engine chooses the approach table to join to the proper granular fact table through its own implementation of aggregate awareness.

OBIEE has had aggregate awareness for quite some time now (at least 5 years) within its main server engine. It also was a little more intuitive to define at which level of granularity the Logical Table Sources were defined for and referencing the appropriate hierarchy column within a dimension to determine which LTS to query against. If an appropriate column within the normalized dimension table exists to join to the aggregated fact table, this design decision allows OBIEE to implement aggregate awareness in a much more efficient manner.

I’ll dig more into how the Microstrategy analytical engine handles this with the configuration in the Project.

Another difference is that the metadata resides within its own schema whereas the OBIEE metadata resides in a single file. There are pros and cons in both methods. With an older BI platform product I worked on over 10 years ago called Information Advantage DecisionSuite (RIP IA!), it was very similar to what Microstrategy’s approach is in terms of centralizing the metadata storage in a database schema. Migrations with metadata stored in a file vs a database means that it is a little more cumbersome to conduct within Microstrategy. In OBIEE, it requires copying a single file into the target server. Within Microstrategy, the Object Manager needs to push the changes from one environment to another, meaning that it needs to do database reads and writes from one metadata schema to another, in another database as well (if you architect it according to best practices and separate the target server metadata in another schema or database instance altogether). This, however, ensures that proper measures and checks & balances are done via the platform to preserve the integrity of the metadata components.

I’ll post some more thoughts as I come across them. Feel free to poke holes in my observations though and comment on the comparisons. More to come!

Will this be the vision of the future in downtown San Francisco on an old structure that has outlived its usefulness? Here’s what it is replacing currently:

An old, Great Depression-era building that has seen its share of use over the past 70+ years when it was built in the 1930s. Wondering if the new terminal building, with all of its eco-friendly approaches to having a low impact on the environment, will be sustainable going forward. Do we even know what “sustainable” really means when we’re tearing down structures repeatedly within each century? The only thing that’s holding the test of time are old Victorians and Edwardians within the city. How much longer before they also get torn down to be replaced with a modern concrete structure?

I had this up on my previous version of my blog so thought I’d repost this here to help those of you looking/searching through the digital channels without having the Comcast tuner and digital cable package. They don’t seem to work outside the city (I can’t tune into these @my gf’s place in San Mateo) but I believe that you would still need some type of external tuner hardware (like a TiVo DVR) to decrypt these channels. Comcast has started to encrypt their QAM channels with some light encryption and most TVs with the digital tuners built into them do not seem to have this capability of light decryption. (Someone correct me if I’m wrong on this.)

—-

I’ve worked with a few BI tools now and one of the most frustrating things, in my opinion, about having too much freedom is that it bogs down the true nature of what we, as developers, try to deliver. If there’s a specific layout template that has been designed, it SHOULD make it easier, right? In theory yes, in practice, you still have all those reports, elements, widgets and components that make up a dashboard to place within the template. As an individual that craves instant gratification, it is enormously frustrating to have it delayed, delayed and delayed yet again because things don’t “look right” when they’re put together.

Why can’t we develop BI tools that have customizable themes (a la WordPress blog themes, for example) that allows web developers the freedom to have customized stylesheets, sections that can be programmed in a way that works for the business within the context of their internal/external web application environments and allow the BI developers to be just that, BI developers instead of Web developers. To be honest, BI developers really stink at being Web developers (most of them anyway).

Think about it this way: Does Microsoft Excel give you the freedom and flexibility to layout their spreadsheet, toolbars, look-and-feel and placement of menu items? Sure, to a certain degree. But it all still looks like Excel at the end of the day, instantly recognizable and still eminently usable. I see BI applications as no different than Enterprise applications like Excel. If you want to incorporate components of your BI development into an intranet or portals, leverage the Web Services components that should come standard with all applications these days. Leave the web page design jobs to the User Interface junkies who’ve studied web design & usability (a la Jakob Nielson or Steve Krug).

Here’s the “unofficial” mascot of my blog, Frisco, the American Eskimo dog. He’s a miniature Eskie, a shelter dog which I freed from a dog shelter in Maryland, “Sneakers” style. (Have you seen this movie yet? Get it on your Netflix queue if you haven’t already.) He’s a bit yappy, over-protective, neurotic to the bone and super hungry all the time but he still smiles like that when he’s gotten to know you after a little bit of time. The kid makes me laugh half the time. I hope his antics will lighten your day from time to time as well!

1. you get bored with it
2. I get bored with it (again)
3. the blog posts run into legal issues and I’ll be forced to shut it down

I am hoping for c) because that would mean that I’ve ranted and raved about some topic which is quite controversial but has drawn the attention (positive or negative is fine) and criticism to be worthy of scandalous status!

Most likely, I’ll end up blogging about topics that are fairly mundane and uninteresting to the majority of the readers who happen to stumble upon here (yes, all 8 of you!) and bore them silly with my non-witty prose. In all honesty, it will be the beginning of a personal journey as I embark on a separate path in life that will likely surprise those of you who know me (that narrows the 8 on here down to 2). I’ll continue to blog about professional topics that I’m involved in with my current role @Facebook.

I managed to be lucky enough to work here after the common stock has become worthless to employee # 800+ (everyone knows if you’re beyond employee # 100, the likelihood of owning your own Lamborghini Gallardo – I’m not greedy – is close to nil). The work, nonetheless, is quite interesting and the pace dynamic enough that things can get accomplished in a matter of hours. But there’s just enough work politics and red tape to allow you to feel right at home (after consulting for many years at old-world institutions) and move along on projects in 3 month spurts.

Data Warehouse, Business Intelligence, ETL (pronounce this “etel”, like “metal” ), my love of tinkering with my car, golfing (yes it IS a sport damnit!) and whatever interests that fancies me. (If you don’t like it, go get your own blog.)

I hope you stick around and if you happen to see some Google Ads, please go ahead and click them to help me out in paying the bills. Companies don’t pay what they used to and I don’t get the perks of consulting any more, where the client picks up the tab for silly expenses like $12.95 soup + $5 delivery charge to your hotel room.