Monthly Archives: January 2009

SAAS & Layoffs

With the economy deteriorating day by day and the layoffs increasing, my experience with on-premise applications got me into thinking some practical issues for SAAS adoption.

When an employee leaves a company on his own or due to RIF or Layoffs or Firing, whatever the case may be, the access to the internal systems are pretty much gone. Not being physically present within the office in itself restricts access to several things. One top of that, corporate firewall will prevent access to anything else, as soon as the VPN access is deleted. Ofcourse, some routine services like email and calendar are typically provided access to without first getting into the VPN connection. So, those kind of services have to be terminated as soon as possible to.

Infact, the process of termination is typically starts a few days prior and I know of some smart employees figuring out who is getting axed during a RIF by trying to do some HR transactions that would have typically got blocked towards the end.

Now what does it mean to using a SAAS application? Is your internal HR system integrated with your SAAS application such that when an employee is terminated in the HR system, the access to the SAAS application is also terminated? Now imagine a sales person being terminated but he still access to the sales force SAAS system and able to go home and download all the contacts and those of the other people working within the same organization or territory that are being shared?

So, here are a few user management features that every SAAS system must have. Before signing up with a SAAS vendor make sure some of these that are most important are available.

  • Bulk user termination. This is useful when several employees are being terminated at the same time.
  • Complete Lockdown. In SAAS solutions, typically there is always a administrator for each company. This admin should be able to place a temporary lockdown such that all the other employees of that company are not allowed to login. This would be useful if there is a need to prevent access to the system to all users for a few days while details are being worked out internally.
  • APIs to user management will help large corporations to build web service integration to tie it with their HR systems. However, it would be interesting to see what happens if one were to use two SAAS vendors, one for HCM (human capital management) and another for Sales Force Automation.
Advertisements

Leave a comment

Filed under SAAS

System.out and UTF8

Remember the post Why I (rarely) Hate Java? Well, this is another of those moments. I was trying to output a string encoded in UTF8 and it was displaying as ??? So, how am I supposed to fix this?

Well, I think, when Java started off, the designers perhaps didn’t bother about encoding. That’s why you see Streams initially in the java.io package and then the readers and writers. The later are aware of encoding while the former classes are not. And unfortunately, the System.in and system.out happen to be the stream classes. As a result, it’s not possible to do utf8 or other non-default encodings.

So, the way to fix this is

PrintWriter out = new PrintWriter(new OutputStreamWriter(System.out));
out.println(“some-utf8-string”);

Now, this should work just fine. And BTW, if you are trying to see the output in a linux console or using vi editor, you would still see the data as some garbage. One option is to open it in Firefox and make sure that the character encoding is in utf8.

6 Comments

Filed under Java

Open Source Doesn’t Lock You In?

Today, I saw a post on Craigslist with the statement

“We believe they should investigate vendor developed and or vendor supported open source accounting/ERP software to avoid lockin and associated cascading fee. ”

That got me thinking and writing this post. I am familiar with the technology and functionality used by a few open source softwares. And ofcourse, I am also familiar with the commercial ones.

The above statement on the craigslist post mentions “to avoid lockin”. Now, what exactly is concerned as a lockin to be concerned about?

Let’s see. Any enterprise application, be it open source or closed source, requires a few key components. And they are, the operating system, the database, the middle-tier server and finally the language to write the application. Those familiar with the LAMP (or WAMP) knows I am referring to for example, Linux, Apache, MySQL and Perl/PHP/Python combination. Ofcourse, it could very well be Tomcat for Middletier or Ruby for programming language. But the point is, that these 4 are the key components to build an enterprise class application.

Some of the open source products I have evaluated stick to a single programming language. Few of them offer database independence, but at the cost of not being able to make use of some database specific optimizations. But let’s ignore that for a moment. Now, what would a company evaluating for a enterprise software consider a lockin? Is it if all of the above key components are not interchangeable? Is it if only some of them not interchangeable?

Now, let’s look at each of the component.

Programming Language: Most open source applications are developed in a single language. And it’s not possible to start using one of those open source applications and all of a sudden, just because your internal IT staff is familiar with a different language, expect it to be available in that too. Ofcourse, chances are the IT department wouldn’t have picked an open source application whose language is not familiar to them, the same way as a CIO wouldn’t pick a commercial enterprise vendor unless he is familiar with that vendor in the past life or has a buddy working at the vendor offering all kinds of incentives however little they may be. But, what happens when the original IT staff moves out, downsized or moves into management roles? Who are going to handle your already existing open source application written in a language that is either alien or frowned-upon by the current IT staff?

Application Server: Most open source applications go with a java server or an apache module/cgi. This means, you are already committed to using one of them. It’s just that by starting to use one of them, your decision making has been made easy in the form a pre-requisite. I mean, would you question if your favorite open source CRM application says that it needs Apache to run it, “why can’t it work with my existing tomcat installations?”

Database: There are a few database independent drivers that enable applications to be written such that it’s database independent. However, remember that the open source application vendors don’t have the resources to test it with all possible combinations. While they can claim to be independent of any of the database, their testing and main-stream support is limited to only one of them. The one that most people just follow without questioning, yet thinking they have the choice to do whatever they want.

Operating System: Apache and Java server already make the operating system transparent in most cases. Most of the commercial vendors offer equally good support for multiple operating systems as their open source counterparts. Ofcourse, Microsoft is the only exception.

So, next time some one tries to tell you that by moving to open source you won’t be lockedin, think carefully what that really means to your organization. Infact, what really matters is to standardize these 4 key components within your IT infrastructure such that you get scales of economy.

1 Comment

Filed under open source, Open Source CRM, Open Source ERP

Check or Click In Selenium?

Selenium is a wonderful tool that allows scripting using a browser. Note that this is different from scripting in the browser. Essentially, it offers apis in multiple different languages (perl, java, ruby and python) to open a browser, and do all tasks that one could manually do such as filling in the fields, clicking links, submitting forms etc all done programatically.

One of the form controls is a radio button. Selenium offers apis to select a radio button. This function is called check where you can pass the element locator of the radio button to be selected. There is also a function called click to which one can pass a clickable element locator. My usecase was to select a radio button that’s not the default when the page was loaded. So, I simply used the check function and ran the selenium script but the result wasn’t as expected. It turned out that using click instead of the check function solved the problem. Can you take a guess why that was the case? Hint: It’s not a fault with Selenium.

The reason is that the radio button had some onclick javascript. The check api will not bother to generate a onclick event because, there is no click happening there. So, by using the click command, I managed to both change the radio button and also make the browser execute the javascript code that the application required to be executed.

2 Comments

Filed under Selenium