Who is Altan Khendup?

A professional technologist that dabbles in innovative and interesting uses of technology, Mongolian history, philosophy and cooking ethnic foods.

Often described as part philosopher, scholar, technologist, and mentor Altan likes engaging in stimulating conversations with professionals, tackling problems in a hands-on and collaborative manner with technology, and enjoying the company of good friends and family.

 

My Twitter Stream

Entries in Enterprise Software (2)

Wednesday
Sep022009

Application Consolidation - The Enterprise Quandry 

One of the most natural actions for any company is to cut costs during tough economic times. Also the most common actions in large companies is what I call the dreaded "consolidation". Basically this is the activity that attempts to reduce a company's large portfolio of applications to a smaller set. Logically and fiscally this makes sense in terms of elimination. If you can actually reduce your portfolio through true elimination you can really save on costs.

However, this is not as straightforward as it appears. I am going to forego the larger management and operational views of the activity and rather focus on the lower level implementation which tends to be glossed over in these discussions.

Usually when large companies speak of consolidation, it is usually looking at making savings on redundancy. This is especially true of companies that have gone through mergers. For example a company that has merged several times may have in fact have many redundant applications such as ordering, provisioning, HR, etc. At some point consolidation focuses on these applications and attempts to merge them into one.

The issue for large companies happens to be the size and hence complexity of this approach. In my experience this exercise is fairly ponderous for even smaller companies. When you get to organizations with tens of thousands of employees or more, this is not so simple mostly because the amount of data in the applications are vast as is usually the infrastructure and support personnel to keep them afloat. One classic case I have run into is the predicament related to ordering. In many cases, especially in merged organizations, ordering applications tend to address different segments of the customer base. For example in a large telecom there would be one ordering application for broadband, one for wireless and one for land-line. The ideal would be to consolidate all of these into one platform.

Now comes the hard reality. In this scenario, each application services tens of millions of customers, billions of transactions, cover hundreds if not thousands of servers across multiple data centers, hundreds of terabytes of data, and more than likely has hundreds of individuals servicing them. Consolidating these applications into one platform is daunting. Mostly because such a move puts companies into areas that are not necessarily their strength which is expert technical infrastructure management. How do you move all the data? How do you merge the applications such that functions are available to all parties without having to extensively retrain thousands of customer service representatives? If you leverage existing hardware or reduce it, how do you manage such a large distributed application on big iron from big vendors? For example, tackle simply the database level which may be from a major vendor such as Oracle. In some of these cases of consolidation companies push the vendor's ability to deliver a solution potentially merging all the applications could be well over 800TB worth of data. Imagine the sheer magnitude of moving this data en masse which is how most shops know how to tackle a problem of that size.

Usually after hitting the brick wall of reality, many compromises are made to applications that can span years which result in paring systems down enough such that they can actually be shut down and rolled off. However, this works for only the smallest of applications or the least used ones. The larger ones which are still being used actually account for the greatest potential for savings and present the greatest of challenges. So in most companies actions, they tend to leave their consolidations to the smaller or medium sized applications that while achieving savings do not deliver as much as first thought.

Hence many technical groups within these large companies are intrigued by cloud, data management, and large scale infrastructures common to certain internet companies. Unlike some of their smaller cousins, larger companies do not have the luxury of growing into the problem. They are there all ready. The hope is that by looking at more innovative approaches, their own technical professionals will be able to implement solutions that can best address the business need to cut costs while insuring their applications can continue to meet the growth and functional demands.

Tuesday
Aug182009

Enterprise Software Needs To Be Simpler

Over the past week I have been working on a project with some professionals in an effort to help their employees get a better explanation of certain technologies. Specifically the recent case involves the difference in SQL operations between MySQL, Postgres and Oracle. 

My assistance has been mostly involved with virtualization planning and implementation, some remote access testing, overall review of infrastructure, and technical troubleshooting. One of the main pain points has been with Oracle or specifically the steps to install and properly configure it. The group while generally well experienced had been mostly experienced with Open Source based software such as MySQL and Postgres. Oracle was reasonably new in that they only had a few years of experience as opposed to longer experience with the other software.

The fundamental issue happens to be what is considered "easy" between typical Open Source and enterprise packages. MySQL and Postgres are pretty straightforward and easy with an abundance of good documentation. Oracle on the other hand is not as straightforward requiring quite a few configuration steps that are not necessarily easy to follow. Even the documentation which is quite extensive is not the most straightforward in terms of finding specific information. There is no wiki site per se. However there are quite a few walk throughs and guides that do help depending on your platform.

The commercial Open Source packages are the result of a collaborative effort between the participants of the community. It shows in a lot of what is delivered. It is easy-to-read, easy-to-find, easy-to-follow, compact, concise and effective. The same cannot be said for larger enterprise software such as Oracle. It is large taking a lot more storage space, more complex which requires more planning to implement, and less "easy-to" as it's roots trace back to more closed community approaches where enterprise customers had to deal with degrees of user-friendliness. 

The issue with the approach especially in times such as these is that the lack of ease-of-use is pretty much a huge barrier to adoption. With increasing competition from all fronts, enterprise software needs to focus on lowering that barrier. That barrier means more time and expertise resulting in higher costs and lost opportunities. There is significant debate as to whether Oracle is actually needed especially for internet shops other than perhaps to run internal payroll or help desk. As more and more companies start to compare notes with each other for insights as to how to operate better, many stories about the use of software such as MySQL, Postgres, Hadoop, couchdb, and others rise very quickly. 

I have used Oracle among many other enterprise software applications for years. In comparison to the progress made to their commercial Open Source competitors they have not moved fast enough to address this barrier of adoption. I can see how this barrier impacts technology professionals views of such applications. Younger professionals coming out of college are more prone to use Eclipse, MySQL, Java, and other technologies to improve their techniques and solve problems. Very few actively go out of their way to learn large enterprise technologies because they dislike how long it takes to learn and the lack of relevancy of that software if they decide to move to different companies. Also many experienced professionals are not necessarily the best teachers with many not having the patience nor the skill to pass along knowledge to make the process of learning easier. Hence, more and more professionals entering the technology field are less concerned with enterprise software as opposed to exploring commercial open source. As this trend continues technology groups within an organization will find themselves under increased pressure to adopt more current practices and open source technologies or find that they will lose their appeal to talented employees who will leave for more interesting opportunities at other companies.

In the end if enterprise software wants to improve, it has to get back to appealing to more technology professionals across many generations while delivering value by solving problems. If this barrier continues to be present, as the more experienced professionals move onto retirement, vendors may quickly find themselves with customers who really do not care about their products due to past experiences; such how much of a pain the product was to deal with to get something done.