It began as a good year like all New Years do. At least for Solix it did. Early on the year, we entered new markets – and continued that through the year with customer acquisitions in Eastern Europe, support of JD Edwards archiving and application sunsetting, support of DB2 on both IBM’s i-series and z/OS and strengthened our partnerships through our integrations with Oracle’s Universal Online Archive and HDS HCAP But it was a Bad Year. The US economy tumbled and the global economy crashed. Retailers have already reported the worst year in history and many lost their jobs and their homes. Bankruptcies led to the fall of many big names. For the IT industry, it was tough times as decisions took longer and there was pressure on prices and margins. It was an Ugly Year. The Mumbai tragedy was horrific. The scene of the ugliest carnage – the Taj Hotels – also happened to be one of our customers. We pray for all the victims and their families. Talking about ugliness, the Madoff scandal could not have come at a worse time.

I am sure we are all desperately looking forward to the New Year –and hoping that the worst is behind us. There’s a lot of hope and expectations. But it will be a U – rather than a V recovery, and we need to prepare ourselves for that. The new US administration, taking office on 20^th January, is talking about structural changes through a “ new energy and environment plan”. The gestation period may be long but the rewards would be ever lasting. Along with many in the IT industry, we too are doing our bit in helping to create Green IT Centers and we will continue investing in this area.

We will soon announce our new Release. It will have a number of industry-unique enhancements in Data Privacy, Long Term Data Retention, support of industry vertical applications and SaaS-enabled features. We will closely follow the trajectory of Cloud Computing. Still in its infancy, we do believe the current economic climate would accelerate its adoption. Once that happens, Data Management would become a critical support function.

In a difficult year, we grew. For that we thank our customers. Many of you were great references. And that means a lot in our business. To our partners – who enabled a market reach that otherwise would just not have been possible - we thank you for your support. To the Solix team – thank you for making our customers happy.

And this is to wish all – our colleagues, customers, partners a great year ahead of us.

It’s been a few years since the debate started on software licensing. And the consensus appears to be that acquiring perpetual licenses is on a downward trend. (I guess it’s still too early to call for its eventual demise). Customers are demanding fast and easily measurable ROI on their enterprise software deployments; the software industry is responding with either open source or utility-pricing.

Moving toward utility-pricing is not surprising at a time when the IT industry is going through structural changes. It started first with Application Service Providers (ASPs) or On-Demand, which some like to call; which mutated later to a Software-as-a-Service (SaaS) model. And lately there’s another trend emerging: Cloud Computing for infrastructure with a completely new player as a leader – Amazon.

All most interesting and something we had thought about when we were architecting our then new Release 4.0 back in fall 2006. We incorporated the basics to deploy our software in a SaaS environment, or at least make it possible for Managed Service Providers (MSPs) to offer data management services using our product on a rental basis on a pay-as-you-go model. The software allows metered pricing and is multi-tenanted.

Over the last eighteen months, we have developed this further and built maturity to it and now we have begun offering on a utility-pricing model, with one key difference. For a utility, you pay more as your consumption grows even if it is sometimes on a reducing rate per unit. In our case, the more you archive the less you pay - in absolute terms.

It’s a pricing model we believe would be attractive in current economic conditions and would be trend setter for rest of the computing industry, perhaps even for the utilities.

For us, it provides a predictable and steady cash flow rather than a series of bell curves of peaks during Quarter-ends and troughs in between. Having doubled our market share in the last two years, we believe utility-pricing will help us double our market share again –this time in 12 months; but more importantly would offer our customers a predictable ROI with their operating budgets when getting capital budget approvals is getting increasingly difficult.

For years, packaged solutions for Database Archiving seemed like a beautiful foster child that had to be adopted only after a home grown baby was attempted, perhaps conceived but finally failed.

With nearly 1000 customers around the world using packaged Database Archiving solutions, there’s now the industry accepted threshold of customer proof points. The good thing is that most customers have reported significant ROI from their archiving software to the analyst firms who have conducted customer surveys in this area. A most recent study has also shown Solix doubling market share in the last two years*.

Solix customers for Database Archiving range from Asia, Europe and North America in diverse verticals like Discrete Manufacturing, Telecom, Logistics, Federal and CPG running packaged ERPs/CRMs like Oracle E-Business Suite, JD Edwards, Siebel, BaaN and custom applications on Oracle and other Databases. All of them reported a high ROI.

While we have had market validation – from both customers and analysts - our challenge is to provide even a higher ROI than what our competitors offer, and that’s where innovation comes in.

Our most recent innovation was what Sai referred in his last blog: our integration with Oracle Universal Online Archive. With this integration customers will get unmatched higher security, retention management, storage management, Records Management, and auditing to the archived data. The Compliance Officer can have a good night’s sleep, confident that archived data cannot be modified. This is what only Solix offers among Database Archiving vendors. And we are confident, that customers will now see exponentially higher ROI as they adopt this integrated offering.

* This compares market shares as stated in Gartner’s September 2006 Report versus their October 2008 Report.

This caption coming from an archiving vendor, I would not fault the reader for thinking that this blog would again be about archiving and extolling the virtues of making production databases smaller. Yes, big (and getting bigger) production database size is not good, and one needs to archive little used historical data to make it smaller and make the business operations – not just the IT – more agile, more energy-efficient and more compliant with the need for immutable records management.

However, this will be about what I sometimes hear from customers that they feel a big vendor is always a safe bet. Having read the economist E.F. Schumacher’s 1973 seminal work, “Small is Beautiful,” I have confidently countered that; and happily, on most occasions, I have been able to convince them.

See the history and see what’s happening now. A venerable big institution like Bear Stearns went down. So did Enron. And now the two big mortgage companies are being bailed out by the US Government.

Let’s look at the Technology Industry. Once upon a time, long, long ago there used to be a very big company called DEC. Some of their products still survive, but not the company. During the best days of DEC, a small company – Oracle Corp - emerged to launch a RDBMS. Oracle later acquired DEC’s Rdb, and Rdb still survives on Oracle’s price list. Understand that in the early 1980s, Oracle – the small company then – had to fight the Goliath, DEC for RDBMS business on VAX/VMS.

And sometimes successful big companies enter a business only to get out of it later. GE, Honeywell and Xerox are good examples of this. All had at some point of time in their illustrious history been in the computer business. I daresay, only students of technology history remember this!

Having worked earlier for two organizations that were near start-ups when I had joined but became (and still are) the leaders in their field – and in parallel seeing what were then considered the Goliaths in the industry - either completely gone or struggling or out of that business, I would like to make the following observations:

• It is necessary for the small company to prosper and get bigger; there are no two questions about that. Too many small companies became history (and history does not even remember them) simply because they could not overcome the first minimum threshold of adequate customer acquisition and profitability.
• Once they acquire a certain size, it becomes necessary (but that’s not sufficient) to grow out of being just a niche player. See what happened to Netscape and Ingres.
• Perhaps the sufficient condition (unless there are serious management issues) is the fact that the big company just cannot afford to miss the technology bus. If they are late getting into that, it may be just too late to catch up. DEC missed Unix. Ultrix was just too late and not good enough.

Now coming to why GE, Honeywell and Xerox got of the computer business. It made good business sense. It was good business sense for IBM to divest its PC business. They exited in spite of the mainframe (GE/Honeywell) or Workstation (Xerox) or PC (IBM) markets being very good at that time because in this product line they were not number one or two in the industry; it was not major revenue or earnings earner; and they did not see this business as a prerequisite for success in their core areas. In fact it was the same reason why DEC gave up Rdb; the RDBMS market was very robust. But for DEC, this product line was not core to the success of their mini computer business.

So before deciding that bigger is safer, I would suggest looking at the two fundamentals of necessary (are they niche?) and sufficient (are they current on technology?) conditions of survivability of the big. And then one needs to ask if the product line is indeed strategic or even peripheral to their core business. Because, if it is not you can guarantee that sooner rather than later, it will be shed off.

It’s happening right now as we speak. In some cases, Small Is Beautiful. That’s why Schumacher’s book remains a classic even after thirty five years.

One would think, given the attention it has been getting for nearly a decade, that by this time every large IT Department would have done a thorough due diligence of its security systems and would have instituted necessary controls. Apparently not, if one reads the continuing regularity of security breaches. Take the example of a few weeks back - about an insider’s flagrant abuse to his employer’s computer systems. This news of hijacking is even more frightening than the occasional breach in data theft from insiders.

The good news is that both can be stopped. The bad news is the “ostrich-like” approach that most organizations take – it can’t happen to me, till it actually happens. A CD with sensitive data left in the airline seat pocket is deemed extreme carelessness and the person reprimanded for it. What’s glossed over is the fact that he should not have been allowed to have that data in the first place in his CD, thumb drive or on his laptop. It should never have left the security of the server in the first place.

Secure thy network and your data. It’s been said so many times before that it now sounds hackneyed, except for the lurking fear that tomorrow you or I could be victims with our personal data in the hands of a felon.

Think now about this hijacking incident. If he had not been arrested, he could have deleted some data, and added some, depending on his prevailing state of mind (if he was momentarily insane) or did all of above and modified for criminal purpose, if he was truly malevolent. Imagine if this hijacker was also part of a sinister network and you get the picture!

Of course, a home can be robbed even after locking all doors and windows and installing alarm systems that are kept in working conditions. But at least we know that the probability is minimized. I could say with 99% statistical confidence that security breaches are happening to those organizations that have not undertaken any form of due diligence of access, operational and IT security and consequently have failed to implement a comprehensive security system.

As an IT vendor focused on data management, we are deeply concerned and have decided to do something about this. We are introducing this week a package configured to mask up to 39 columns of sensitive data in non-production systems of Oracle e-Business Suite. It’s pre-built and an out-of-the-box solution. If you want to secure corporate and personnel data in a week in your Oracle eBusiness Suite non-production environments, call us now.

There’s an apocryphal story I heard about a CIO who asked his DBA to surreptitiously archive one month’s data from his ERP each week, starting with the oldest data stretching back five years. The DBA archived to the point where the oldest historical data was being accessed by any functional user. As expected, the DBA archived three years’ data and the functional users never noticed. The question then is why did he have to move the data in a covert manner?

Business owners – the true owners of the data - are usually the most reluctant when they hear the word “archive”. They think data will be moved offline and access will be lost – never mind the fact that they rarely, if ever, access it at all! Perhaps the solitary word “archive” is a misnomer. Some prefix it and call it “active archiving” – meaning the data would still remain active - while others refer to it as “near-line archiving” – where data would be moved to near-line storage and still be accessed online. And there are some who avoid the word “archive” altogether and call it “data relocation”.

Whatever one may call it - once archived, moved or relocated - business users – and not just CIOs and DBAs - see immediate benefits in terms of application performance improvements. One such customer, a BaaN user on Informix Database, ran into serious issues whenever the application hit the table limit size. The system would be down for several days seriously impacting manufacturing schedules. With Solix EDMS, which supports BaaN Archiving, the customer now moves closed historical data to a separate database, resulting in:

• Improved application performance and stability – which in turn, helped to maintain their manufacturing schedules
• Reduced future hardware costs through space reclamation after DB size reduction
• Reduced downtime associated with frequent database maintenance
• Reduced backup and restore downtime.

A non-believer may say a swallow does not make a summer. Customers like Forbes Marshall and TRACO, in engineered-to-order manufacturing, deployed Solix EDMS for Oracle E-Business Suite archiving to trim their DB size in Bill of Material and Order Management systems on their production servers and experienced immediate benefits in the shop floor through better application performance. These examples prove the point that Archiving helps to avoid a hit on the company’s top line revenue figures.

Archiving is a pain killer for an organization, not a vitamin providing a short term panacea. If the CIO is the custodian of company data, let him Archive it. Archiving achieves business agility with a high ROI and should be a top priority project in a recession-hit economy.

Nicholas Carr presented a thesis five years ago that IT no longer provided the differentiating competitive advantage and therefore no longer mattered. Since then, he has been proven wrong many times over with billions of dollars spent on new IT initiatives, simply because there was a positive, if not high, Returns on Investment (ROI) on most enterprise-wide IT projects.

There is always a scrutiny every time a CIO presents a project for approval. Being a relatively new discipline, Database Archiving had been one area that got relegated to a lower priority simply because there were few implementations and even fewer evidences of hard numbers on ROI.

A few years ago, at an Oracle Conference, a customer hammered “Why Aren’t You Archiving”? He presented a convincing case with a strong ROI. As with all new technologies, there’s a tipping point for adoption to accelerate. That tipping point may have just happened.

Gartner’s June 2008 Report on Hype Cycle for Storage Software Technologies has unequivocally stated that the ROI for implementing a Database Archiving solution is “exceptionally high”. It further goes on to add “When database archiving is used for application retirement (with retired data archived to tape in an XML format), the business impact can be even more dramatic”.

This Report could not have come at a better time. With the economy near to a recession, it underscores what we have been saying all along. Archive to not just improve application performance; archive to improve business agility. Archive to not just reduce storage costs; archive to reduce energy costs. Archive to not just ensuring data retention; archive to insure against an expensive litigation. The high ROI is indisputable.

And for applications retirement, the Solix archiving solution with its core as a metadata based repository, we not only move legacy data to a XML format, but we can also move it to the new database of the new application, before we finally retire it to a Tier 3 storage. Archiving before upgrading or migrating reduces time, implementation costs and carrying over “dirty” data.

A Depository, implementing anti money laundering laws, recently sent rejection letters to many capital market investors who have to be registered with one of the two depositories in India. The reason given: computer glitch. Isn’t that familiar? We heard the same thing when one of the largest Banks acquired a credit card issuer in 2005. A number of affected customers even blogged about their bitter experiences. The Bank’s IT problems started earlier when it had acquired another Bank in 2004, and they were struggling with integrating the systems, which first meant a rip-and-replace of the acquired Bank’s system. The subsequent acquisition of the credit card issuer compounded the IT integration problem.

On the other hand, last week, I heard a completely different story after visiting a tax collection department. A merger of two municipalities and adding more sources of tax collections meant their systems needed change. No glitches this time. There wasn’t a single complaint of citizens getting a wrong tax notice or a valid refund claim being rejected.

This got me thinking. Why should a Bank or a Depository – with vast resources and experience in managing large systems - run into a problem while a government agency with limited capital budgets and a bureaucratic set-up get it right?

I don’t believe there’s a simple answer to this. But the tax collection agency’s approach may be revealing. They adopted the principle of application modernization rather than rip-and-replace. It may surprise a few, that a government organization is an early adopter of application modernization; not so surprising if one considers that a rip-and-replace is always more difficult for them from budget approval aspect. This tax collection agency over the years has been modernizing what was once a client-server application to one that is web-driven and event-driven; their entire business process began changing from late ‘90s with the advent of the Internet, merger of two municipalities and adding more sources of tax collection. They never had an application switch over downtime; they did not have to go through a BPR or user retraining. For most, it remained business as usual.

The reason for complexity which perhaps explains the difference as well between the mergers of the two banks and the municipalities is that commercial organizations in the same industry and region are likely to have completely different business processes. On the contrary, Government departments in the same state and country are likely to have similar business processes. In my example, while the tax departments of the two municipalities were running applications from different vendors, their integration was simpler compared to what two commercial organizations may go through even if, hypothetically, they run the same ERPs and core banking systems. If they are different, and if they run on different databases, then what the Banks did – application retirement for one - may seem near inevitable.