Omnichannel - Asset or Liability?

People tend to treat omnichannel as an asset and the next big thing. There is also an admission that omnichannel is somewhat an enigma. If it is an asset, it is still so much a "diamond in the rough" that retail companies, software providers, solution providers and system integrators - all are struggling hard to figure omnichannel and nail it.

Truth be told, I feel that omnichannel is not an OPPORTUNITY, it is a LIABILITY. Until someone builds a product that can provide the seamless experience that omnichannel purports to provide, I will like to plead that it is just a hype. 

I like to use a short story to explain this. A man had one watch, he was very happy looking at the shiny thing that told him time, every now and then. His experience was fantastic - all was well.

Then, we give him another watch. Now his focus moved away from using it to get time. He started focusing on why there was discrepancy between the two watches. However much we tried, even the seconds discrepancy looked egregious and nagging to him. His whole customer experience turned tardy and he wanted us to sort it out. So now instead of thanking us for giving him two watches, he was pissed that there is a few seconds' discrepancy between them. So much so that we was ready to throw both watches that we gave them and move to another guy who promised him just a single watch.

So, we now had a new challenge - how could we make both the watches so good, their alignment so smooth, their time so much in sync that the man would have a very seamless experience. 

Omnichannel is much like that - in the beginning of time, companies had retail brick and mortar stores and everyone was happy. Then this thing called "internet" showed up. There were some who said "we will sell things only through internet". Great - they were lucky. People called them Ecommerce guys, online retailers and so on. 

The original brick and mortar guys got greedy - they said "why can't we get on to internet?". Companies like Infosys, TCS, HCL jumped at this and assured the brick and mortar retailer that they could definitely help it get on internet. The retailer got on to internet thinking that he would start eating the ecommerce guy's lunch. 

The technology provider created another channel for retailer to make money. Everyone was happy. Then customer - let us call her Mary - who suddenly got exposed to the second channel started getting frustrated when the online channel of the retailer didn't recognize her despite the fact that she was spending so much in its stores. She understandably was just asking them to identify her as Mary whether she went online or she went in the store to do shopping. She started expecting world of the retailer but the experience was nowhere near that. In fact, most of the time, it seemed as if she was dealing with two different companies when in reality she was simply dealing with the two channels of retailer.

The retailer went to the technology vendor again. Vendor was lost, scratching their heads they decided to go to Guru of Gurus - Mckinsey. After much pensive introspection, Mckinsey came out with the term "multi-channel" that morphed itself into "omnichannel" with the passage of time.

Omnichannel was carved out as a huge opportunity. People created picture perfect view of omnichannel, but just on paper. There were questions on how to translate the paper view into practical technology.

At a high level, Omnichannel is merely three things:-

1) Profile persistence (of the customer)
2) Shopping cart persistence (of the customer)
3) Transaction persistence (of the customer)

If any technology vendor can make a tool or product that allows these three things to come together, we will immediately have omnichannel experience. It could be next big idea for a startup. However, it is easier said than done. Persistence means that data has to synced between different systems in almost real time manner. That means there has to be real time data integration between systems. In the absence of that, the persistence becomes batched and delayed updates to the backend system and therefore loses its meaning.

 In the absence of such tool or product, omnichannel remains as much a pipe dream for retailers, as it is a massive liability for them. Customers are unhappy that retailers don't recognize them well enough when they move from channel to channel in the realm of the same retailer.

Meanwhile, the original ecommerce guys like Amazon, Wayfair and eBay are having time of their lives - enjoying the sunshine since all they need to do is - worry and focus on one channel and make it the best.

The Three Sciences of Ecommerce

Ecommerce and Retail are exploding. In 2016, ecommerce and retail has been projected to be well over $ 1.6 trillion dollar industry. Intersection of Ecommerce and Retail and Big Data is the most happening intersection. People who are showing up at this intersection may not perhaps be fully aware but they would be considered pioneers many years from now.

Big data can make special play for many areas of the ecommerce and retail domain but there are three areas that are emerging as separate fields of full blown sciences in this space. They are Customer Science, Logistic Science and Pricing Science.

Customer science is likely to manifest itself in such huge dimensions that it is likely to touch almost every aspect of the business. One way to measure the success of this science would be to relate this science to best customer experience. The science will be all inclusive, in that, it will be super set of intriguing sciences like personalization, targeting, loyalty indices, Omni Channel experience, micro-segmentation, data driven experiences customization. All these sciences will be brought to give every customer a feeling of the store or online website created and tailored specifically for that customer. What can be better than that experience and walk away with a feeling that the specific store was opened and merchandized only for me? Nothing can top this. In essence, all these component sciences are becoming “need to have” as opposed to “nice to have” component sciences for Customer Experience. 

Since the start of the commerce in history, price has played - whether it was barter based as in the medieval times or currency based as in the modern world -  a very significant role in purchasing decisions in buying and selling trade. Therefore, it is natural that pricing science is assuming prominent and almost keystone attention. Pricing science is likely to include but not necessarily limited to price optimization, price modeling, location based pricing, “cheap NOT EQUALS good” strategy. MBA courses devote special focus on pricing. Big data analytics and predictive modeling are likely to give this special impetus.

Logistic science is again an all-encompassing term that includes Predictive Inventory provisioning, real time inventory and supply chain visibility, optimized shipping, supply chain analytics, feedback loop, cost optimization, demand prediction modeling and single view of demand. For those who live and breathe logistics in retail and ecommerce world, it is always clear that this is the space where we can get maximum cost optimization. This “taking out the cost” from operational expenses is the best optimization that a Etailer can do. It is also cheapest amongst all other ways of bringing down Operational expenses.

People can argue about Omni-Channel being the fourth science – however, I refuse to add that to these three majors. I had rather club omni-channel as part of customer science since, in the absence of customer experience, omni channel is just bunch of technologies designed to exist and operate in cohesive manner. It is customer science which provides the real value for omni-channel.

Though the price wars, over-store’ing in US as well as burgeoning foreign (read, Chinese) debt is going to make life brutal for retailers and ecommerce companies, it is also going to be the most happening space in coming years.  

A Centralized Team aka “The Only Grocery Store in the Town”

What are tenets of a centralized team? First off, what does that even mean? Centralized teams are those that provide “Horizontal support” - implies that the team is not providing support to one specific domain or parts of business, instead it focuses on supporting all teams in a very generic manner. The support then takes the shape of becoming a service as opposed to being a domain specialized niche service.

There are pros and cons of moving away from being a niche service provider to being a generic service provider. One obvious upside is that the team develops a “cookie-cutter” type of solution and uses the same solution to service any and every line of business. The downside is that this is detrimental to the team members themselves. They lose the touch to understand nuances of each domain. Their expertise is diluted to a point that the service would devolve into a commoditized service.   

Typically, in most companies of reasonable sizes, teams such as network operations, database administration, system and storage administration and data center have the opportunity to assume the role of central teams and provide horizontal support.

Why are such teams formed and kept as central teams? There are multiple reasons for that. For one, a central team has a critical mass so it can be administrated as a team as opposed to “onezy-twozies” who are existing as differently skilled persons in a team of largely varying skilled resources. Then there is question of performance appraisals - this becomes easier since you can compare “apples-to-apples”. The career paths are clear – you can have a clear career path within a team of 10-15 system administrators as opposed to one system administrator residing in a team of developers. This is the high order bit of why central teams are needed.

If we want to double click on details then, from logistic standpoint as well, it becomes easier – you can restrict superuser passwords, sysdba, system passwords etc within the team and don’t have to share it across multiple teams and lose the notion of password itself. Finally, best practices are very well shared, standards are set and implemented. SLAs are drawn and people have set expectations on the type of “customer experience” for a given task.

When we combined the DBA teams under one umbrella in 2009 – after trying for many years – I realized that there were more leaders, especially those whose DBAs were being “snatched away” from them, who wanted this model to fail than those who wanted to see it successful. So there was a political realm to the whole implementation. While one part of the management chain wanted this to happen, the other part was doing simply window dressing by playing along in meetings and using every miss by central team to highlight the fact that it was a failed implementation.

Then there were DBAs who were behaving as if they have been uprooted from their comfort zone and were struggling to find their roots in the new land. They were still attached with umbilical cords with their previous organizations and wanted to restore the status quo. This behavior can largely be explained as a sole fish or few fishes falling into a bigger pond and being scared, loaded with skepticism of how things will pan out.

As is fairly apparent by now, there were struggles, external as well internal, to nuke the central team even as we had just started forming up.

Most of the external fears and misconceptions were very reasonable – for example, will the service levels dip, will the team get same focused support from their earlier DBA or will that DBA’s effort spread thin across multiple other domains, will team get new DBA to interact every time so they have to end up teaching  from scratch, the idiosyncrasies of their domain to the new DBA. However, it would be naive to say all of the opposition to move towards central team was based on above reasons only - there could be the omni-present sense of "loss of territory" coming into play as well in that opposing behavior

While all this was happening, I became convinced and somewhat determined that if we have to be successful as a central team, we need to behave as follows:-

Imagine that you are the only grocery store in the town. By being the only place where people can turn to for their groceries or go hungry, it becomes important that following tenets be followed:-

• No Customer Turned back – we can’t turn back any partner team for whatever reason – least of all due to things being out of stock or not enough salesperson to provide customer the service (akin to lack of bandwidth).
• Queue system established – we will have to establish a queue system that gives a sense to the customer when will he or she gets the attention of salesperson.
• Length of queue (or wait period before service) is reasonable
• Service is provided with quality
• Service is provided with a smile (because you love to do business with friends)

Luckily, we had a very mature leadership team in place. We had discussions within leadership team that we will do our utmost to make this successful. We ensured that we would provide the best service to all our partner teams including the new teams that we absorbed into our teams. This was more of journey. Over a period of consistent engagement with us, the “noise” generated by external partner almost died down and was replaced by a sense of “we are better off now”.

There will always be people who for their personal interests will go against the grain of centralization. At some point, it is better to make the right call on those. There have also been team members who came from external teams who have turned out to be exceedingly better than our existing team members.

What happens if you fail to follow the tenets?

Most of the times, central teams walk away with the arrogance and impression that people don’t have choices and they will do whatever we tell them. When that happens, customer teams tend to behave somewhat analogous to flows of rivers. Like a river figures out path of least resistance and eventual flow, a partner team not getting required service from the central team tends to eventually figure out how to find that support. They will devise a way to get that service – in most of the cases, the solution will involve seeking help from teams outside of central team, forming their own team, engaging with an external vendor to outsource their support needs. All this leads to undermining and ultimately destroying central team, so it is always in the best interest of the central team to behave like the "only Grocery Store in the town" and follow the tenets mentioned earlier.

You Know Your Company Has a Data Problem When......

·         Your Business users don’t know where the data is stored...

·         Your data warehouse system lead doesn't know the name of data warehouse DBA's

·         A key customer is lost and no one knows why

·         Scarily large number of meetings are held to decide which data source is more accurate

·         Two reports about same metrics from two different data source give different picture

·         The impact of a key customer campaign is known only to one sales person who is on vacation the day campaign runs (or crashes)

·         To get simple report, you have to submit a bug ticket

·         A report of a customer campaign shows up days after the campaign completes

·         The question “how many customers we have” gets you different answers

·         The question “who are our key customers” gets you “deer-in-front-of-headlights” expression

·         Centralized Metadata??? Duh?

·         Business decisions are taken on “I think so…” logic

·         Each department wants to create its own marts and data warehouses

·         DBA's have no idea about purpose of their data warehouse but DB size is a bragging point

·         Getting older data is like asking Santa for a Ferrari……

·         No one has clear idea about who uses thousands of reports

·         Retirement request for old, never-used data warehouse is met with “…I don’t know, we get “lots” of reports….”

·         Data policies are not written

·         Data governance is non-existent

·         Data and Strategy are oxymoron terms

·         Data is not viewed as an asset

·         Data quality is major project

·         “Flying Blind” is considered an adventure….
·         Visualization is more important than data correctness
·         Data and data people are given second class citizenship….

"Where do you want to be 5 years from now?"

Many times, I have been challenged with the clichéd career question – “where do you want to be 5 years from now?”. Most of us when posed with this question make the mistake of somehow boxing ourselves in the current company, industry and domain. For example, I can easily think of myself as where I will be five years from now and sure enough, I will limit my thoughts to being at Yahoo, even after 5 years from now. I would try to hold a crystal ball and forecast that I would be doing such and such thing at so and so position and role. Not many of us do think that this may entail leaving our current job, company and domain and be doing something else. We can't even forecast how many jobs we will hop or change in these five ensuing years.

 I didn't really pay much attention to the underlying actual theme until I had a very good and somewhat scrutinious discussion with Mark Morrissey, our SVP of Production Engineering at Yahoo. Another person who help ignite this discussion with his insights is Sarang Kirpekar, DVP, Sears Holding and a very good friend. I thank both these gentlemen for their insights into this discussion.

I realize that as you are growing in your career – it is likely that first few jobs are spent in wilderness. You are very lucky if you are Mark Zukerberg, David Filo, Jerry Yang, Larry Page, Sergey Brin and so on. For, then your first job is your last job as well. But most of us meander and waver through first few jobs and then land into something that we consider our calling. For example, you may work for a web hosting company, then a clinical trials company and then land up at some stage in an Internet company like Yahoo.

While you are traversing through these peaceful first few jobs, your focus is primarily on gaining your technical skills. These skills are in your domain – your domain could be DBA, programmer, system administrator etc. So you join as novice DBA then transition to junior DBA. After few years and hard work, you get to call yourself Senior DBA. Few more years under your belt and you call yourself a DB architect. Yet few more years, you start considering yourself the best thing that happened to databases since Oracle 6.0. Sure, not all have that big an ego and vanity. :)

I call this specific period of gaining your chops in technical domain as X Axis or horizontal skill band. I also call this as your first love. Ok, not first love but, at least, second love.

While traversing through this career land, you also navigate through multiple vertical domains – retail, ecommerce, health or internet etc. While moving and learning nuances of each of these domains, you fall in love with one that challenges and excites you the most. You may also end up calling this as your third love.

I will refer to this as Y axis or vertical domain band.

Once you have discovered both X and Y axes for your professional life, it is like you have arrived. Yes, it is indeed that. You have now got hold of your x and y coordinates of professional life or at least handles that will enable you to take your career further.

I also call this discovery as “discovery of professional graticule”. Be glad if you are able to achieve this - Why? Because many of us pass through professional life without having discovered or achieved this professional graticule. Without this, you are like a rudderless ship which may have immense horsepower and steaming ahead on all engines, alas, without accurate directivity! 

Hopefully you are not one of those unfortunates and have discovered your professional graticule. Once you have discovered your professional graticule, the professional journey is very easy. All you need to do is move the horizontal bar on vertical scale making your graticule move up. I have tried my best to summarize this in following diagram.

Professional Graticule

As you grow in your career, remaining within your professional graticule, the professional graticule box progresses. For example, from a manager through director and finally to an SVP, this professional graticule marches on as shown in the figure below.

Progress in your domain via your professional graticule

Sometimes there are small setbacks. These setbacks are due to your desire to chase money as opposed to professional excellence. So you end up taking a pay cut, throw away your rank & standing and join a startup. Nothing wrong with that. It is just that during this period, your forward march on a graph seems somewhat arrested – it may well be compensated by the forward march in your bank balance, so no complains J.

What is the point I am trying to make in this discussion?

The point is very simple and somewhat obvious – the sooner you discover your professional graticule the better it is for your career and professional life.

Like I said earlier, many a professionals pass through an entire professional lifetime wandering from one job to another and in the course of that journey going through different vertical domains. Some people, like Jack Welch, may call this “all round development” but I call this as plain journey into being an executive as opposed to being a specialist. GE is one company that still encourages its leaders to become good executives by having gone through the myriad rungs of leadership in various industries in GE’s portfolio.

Navy also somewhat encourages that – you command surface ships – graduating from smaller missile boats to missile corvettes to frigates, destroyers and cruisers (in that order, perhaps) and then if you are lucky, command a battleship and an aircraft carrier before becoming fleet commander and eventually Naval chief.

I am of the opinion - and you need not really take it as the best of the option - that one should figure out one's professional graticule and then focus all his or her energy on that graticule and growth in that X and Y intersection. This gives you the most positive growth since you are very directional and not really meandering from one career to another.

In one case, you are “Jack of all, master of none” and that is perfectly acceptable and understandable. In another case, and where you stay in your professional graticule, you tend to become “jack of one and master of that very one”. Pick your choice!

Big Data - Background from a Time Traveler

Count me in as the biggest cheer leader of Big Data bandwagon. I agree, it is very ironical if you know my background. Some will call me traitor as well, especially those that are more loyal to Oracle and other flavors of RDBMS than Oracle corp itself is. 

For years, even during the days in the Navy, I was Oracle's huge protagonist. Oracle DBAs could be singled out in the crowd - the guys who wore their attitude on the sleeves and a pony tail to back it up. Oracle and Uncle Larry could do nothing wrong. Those were really the heady days when Oracle was leading head and shoulder ahead of the rest of the pack.

To top it all, around 2005 or so - Oracle 10g made its debut and Oracle RAC (Real Application Cluster) grew beyond 9i's infamous oracm cluster software and into  a much more robust crs cluster software. Everyone was high on Oracle. Oracle could do everything. To the extent, that anything that could not be done by Oracle should not be even tried in the first place. Why? Because it simply didn't make sense. Oracle was the pied piper and most of us from database fraternity followed it blindly. Oracle could do no wrong. In historical terms, "Sun would never set on the Oracle empire".

However, soon we realized that Oracle was fallible, after all. We had a 130 TB data warehouse on Oracle and this is year of the Lord, 2006, when we suddenly started seeing SLA misses and performance issues. ETL jobs would take enormously long and then Reporting jobs would run endlessly. For more than six months, many ace DBAs, Network administrators, Storage Gurus, SysAdmins and Engineering architects broke their heads - many a times at the verge of killing each other but every time we brought the system to a good state, the data volume would push the envelope and we would see the SLA misses. It was as if our destiny was taunting and teasing us. The cycle would just play itself again - encore!

We were hoping Oracle development team will add more punch to the RDBMS software. But Alas, Oracle did almost nothing - they would not even take a look at DBMS_SCHEDULER (Oracle Native job scheduler). The scheduler was woefully short in handling special needs of data warehouses - no way to provide resources allocations, prioritize SLA over non-SLA jobs, re-nice job priority, and so on.

It almost felt that we were left with under-performing weaponry and left to fend for ourselves at the mercy of far superior enemy, the Big Data explosion.

While we were having challenges of our own and were in a very reactive mode, the world was changing around us. Jeff Dean, Sanjay Ghemawat et al decided to play spoil sport and worked out algorithm for Big Table, the distributed computing and storage framework for Google's Search indexing problem.

Since Yahoo was also in the business of Search (this well predates the search-deal-with-Microsoft days), Yahoo decided to look around and find its own man Friday. Doug Cutting turned out to be "da man". He was working on Nutch and was trying to implement his own version of Big Table, perhaps using the same schema family.

Doug Cutting, Mike Cafarella (then an intern but now a very famous professor in Univ of Michigan, Ann Arbor) and team were, meanwhile, working in the background on this alternative which would almost immediately provide panacea to all our problems. They took sometime to get their work out of the door when, Hadoop, as we know it, was born. Named after toy elephant that Doug's daughter had, Hadoop was, au contraire, no toy - it was the giant beast who easily bested Oracle even while it was barely born.

We created our Hadoop clusters in Yahoo - first as research and development grids and then production grids. The developers within Yahoo reacted to Hadoop's emergence as  if shepherds heard the news of Jesus' birth from Angels. Almost overnight (slight exaggeration), we saw most of the event level aggregation jobs moved to Hadoop grid. The baby elephant easily beat the hell out of seasoned Oracle software. The jobs that would take 9 hours on a 10 node Oracle data warehouse started completing in less than an hour. The developers had tasted the first blood, there was absolutely no turning back.

We could neither see nor understand what Hadoop was doing for us and the rest of the world. It had ripped off the ceilings, limits and shackles that relational databases had imposed on us for a long time. This freedom was most welcomed by those in analytic world, for they were emancipated suddenly. They were stunned by insights they could get from Hadoop based processing and data. The age of Big data was upon us. However, it would be sometime before the term "Big Data" would come into being.

Analytic fraternity suddenly realized that there was nothing to restrict their imagination except limitations of their own competence and flaws of their mind. The world of Analytics and ware houses would never be the same again.

What Jeff Dean, Sanjay Ghemawat, Doug Cutting and many others who followed them did - whether knowingly and deliberately or unbeknownst to themselves - they had unleashed upon us the age of Big Data. I would certainly say that these were the people who should be called the fathers of Big Data.

Meanwhile, we, the loyal Oracle DBAs,  were generally in denial or ignorant phase. What is this phase? It is believed that any new technology has at least two different reactions from its target user base. There are those that are new to both existing (aka older technology) and new technology or product. For them, new is better - they immediately take to new technology as fish takes to water.

The second user base is those who are deeply entrenched in older technology or product. For them learning something new is like giving up the handicap they have over these newbies and learn the new technology afresh. So there is a reluctance….Now let us take the view of those that are heavily invested in existing or older technology - these people hate the new technology - they had much rather that new technology just goes away and vanishes. Perhaps they go to sleep wishing that every single night. They are likely to pass through following phases:-

Phase I - Ignore the existence of new technology.

Phase II -Luke warm acknowledgement
Phase III -Continue to push old technology with more Ad/Marketing dollars

Phase IV -Create FUD (fear, uncertainty, doubt) related to new technology

Phase V - Run behind the charging caravan and see if they can catch up

Phases of Learning

The believers of old technologies actually end up providing use cases and some type of quality assurance testing for new technologies. How? They keep pointing to flaws in the new product and technologies and developers of the new technology continually remove and resolve those issues.

There were few enabling things happening at the same time when Big Data containers were being invented. Smartphones like Palm Treo, Blackberry followed by iPhone and Android devices were showing up. These smartphones and devices had started pushing the limits on data volume that was being generated. In turn, the  backend data containers started bursting at the seams. So to a time traveler, who is now blessed with the power and wisdom of hindsight, it would become clear that right at the moment these hadoop processing and data containers were being invented, people were already waiting with tons and tons of data to pour in. So, in somewhat naive sense -  Hadoop and its cousins like Big Table, DynamoDB, NoSQL systems - these systems and technologies were put in production before they could even enter beta phase.

Just so that I keep this discussion honest, I want to assure that I not moving the timelines even one bit. Around 2009, I saw the "light on the mountain" and got "converted" - we realized the power of these new technologies and what they were doing to analytics and insights world. Meanwhile, many in the world were still perceiving Big Data as a hype.

I suspect the dust settled around 2010 or so. People realized and surrendered to the real power of Big Data. It was also realized that this was not a hype like "Y2K" - it was hear to stay. Companies have not looked back in the race to push data into these new data stores since then. 

What are the different things being dumping into the Big Data containers? Let us take a look at a small sliver of the total data generated online (figures as of 20101, data courtesy - DOMO.com -http://www.domo.com/blog/2012/06/how-much-data-is-created-every-minute )

• Email users send more than 204 million messages

• Mobile Web receives 217 new users

• Google receives over 2 million search queries
• YouTube users upload 48 hours of new video
• Facebook users share 684,000 bits of content
• Twitter users send more than 100,000 tweets
• Apple receives around 47,000 application downloads

• Brands receive more than 34,000 Facebook 'likes'

• Tumblr blog owners publish 27,000 new posts

• Instagram users share 3,600 new photos

• Flickr users, on the other hand, add 3,125 new photos

• Foursquare users perform 2,000 check-ins

• WordPress users publish close to 350 new blog posts

We recognize all these companies as big data players - they are "spewing" all this data into some storage, somewhere so they can make better sense how people are using their products, refine those products, make them further attractive for users, in turn accept more data from more users and continue on the kaizen path or path of continuous improvement. Of course, this improvement comes with underlying vested interest of finding some way to better monetize the products - if not today, then at least some day in future.

This data generation is leading to "data pollution". Why do we call it data pollution? In the absence of great tools to store, process and make sense of this data, we are just involved in a good model of trucks of data loads being shipped from one system to another, one datacenter to another, one container to another. There is a hope in every mind that is involved in this transportation "value chain" that someone else knows how to extract value out of this data. There is also a faint hope that "somebody" knows extremely well what is going on.

In short, we are clueless but hope somebody better know how to make sense of this.

There is virtually a "data race". Data size is a good bragging point for storage folks, Database administrators and data community at large. Without good and meaningful analytic hovering over big data volumes, the big data is really of no use to man or beast. In fact, I would call it terribly expensive "garbage dump" if you are storing huge data but not getting meaningful and actionable insights from it.

I will cover further on Big Data enabling technologies that are the "partners in this crime" in my next blog.

ErrorDB - a Case for Robust Error Handling Platform

While people love to hate Oracle, there are few things Oracle does exceedingly well. Or let me be more specific – there are few things that I personally love in Oracle core RDBMS.

One of them is the standard error messages that we use in Oracle. The messages are very standard and there is a very good coding mechanism for coding different messages from different layer of Oracle. Let us take a look at different codes that Oracle uses for sending error messages to the users of Oracle. Oracle has almost 50 plus such categories, below are only those categories that are typically seen by DBAs in every day life.

·     

•          ORA-00000 to ORA-62001 – Oracle Core RDBMS problem
•          EXP-00000 to EXP-00113 - Errors related to Exp (data export utility)
•          IMP-00000 to IMP-00401 - Errors related to Imp (data import utility)
•          SQL*Loader-00100 to SQL*Loader-03120 - Errors related to SQLLDR(data loader utility)

Why Oracle uses these error messages? Simply because Oracle wants all people to understand and talk in common language. So when Satoshi Ikoma, a DBA in Tokyo, Japan, who doesn’t understand English as well as Jim Corbett, his company’s DBA in San Francisco, California gets an error “ORA-01555: snapshot too old: rollback segment number 007 name "UNDOTBS-04" too small”, he understands this exactly as Oracle intends him to understand it despite the fact that he doesn’t understand English as well.  The error means same thing to both Jim and Satoshi San despite the fact that both of them are at different level of competence over English.

If you whisper ORA-00600 (Oracle Internal errors for the uninitiated ones) in a DBA’s ears who is in deep slumber, perhaps after unmentionable number of beers, you can get him to immediately jump, sober up (to sobriety tests totally passed) and almost hyper ventilating. 

ORA-00600 Message

Why can’t we use the similar error reporting mechanism for our applications? The error reporting mechanism in some applications is somewhat mature but most of them have very “intuitive” error messages, like 0, 1 or 2.

When a service engineer or operations center duty person receives an alert stating “EDW job 4403 errored out with error -1”. This means that either the service engineer starts digging around in knowledge base documents to figure out if someone has been kind enough to mention what -1 means or he starts praying that God miraculously dawn him the wisdom to figure out this error code.

Like I said above, many applications are far ahead of others on this curve. They not only report a very informative error message but also have different coding.

How can we have all the applications to follow a very loose framework which also becomes a platform?

Creation of an error reporting platform could be our answer.

Imagine if we have a something like ErrorDB. It could provide a framework that applications could use to register their application with. Once registered, the applications could use meta data tables within ErrorDB to insert rows for each error the application can throw. ErrorDB can perhaps be like RolesDB, nodereg or CM3 or any other platform that can be used by all applications in an organization.

The application error could have following:-

• Application Error code
• Description of the code
• Suggested resolution code

The ErrorDB application could provide APIs to register, set, get error codes which applications could then use to show error in somewhat better and user friendly message.

ErrorDB could also have a CLI that could be used by service engineers who are more geeky than normal users.

Having a very mature ErrorDB will allow people who are supporting the applications to understand and learn application almost instantly. There is no “blackbox” left thereafter. 

Troubleshooting an issue will be so much better. We won’t need “exorcists” to come and wave the wand to figure out the issue. In other words, diagnostics becomes very easy and simple.

It would also improve operability of the application. Developing an application that is always enigma for not only for support engineers but also many a times for the very developers that developed it. It may satisfy someone’s vanity but it leads to wasteful human cycles.

Extending the application becomes way easier when the error codes are easy, decipherable and remediated.