Author: pobalopalous

What’s the bedrock to your Social CRM Strategy?


Perhaps it is taken for granted, but Esteban Kolsky’s recent article on The SCRM Roadmap, is missing the requirement for a Social Media Participation Policy for employees. No matter where you are on his SCRM pyramid such a policy is vital. The first thing it does is give an employee permission to use their own initiative and participate in customer conversations.

Experts
There are few better experts on your products or services than your employees. Apple Inc. makes a point of highlighting these Geniuses and puts them to work in customer facing roles. With the advent of Social Networking, your experts do not need to have such a specific role, but can still be recognised for their contribution in making their company great.

Permission to talk
Your company doesn’t really have to have more of a strategy than permission to get started on becoming a social business. Moreover, a simple, publicly available guideline affords employees some protection from pressure to discuss or comment on topics that are not appropriate.

Guidelines
It can be made clear that while all company employees are welcome to participate in Social Media, it is expected that all who participates in online commentary understand and follow some simple but important guidelines. This really is irrespective of medium (video, blogs, twitter, etc) and could also be applied to more traditional communication mediums such as the press. However, I’ll stick to the internet based communication channels for now. These rules might sound strict and contain a bit of legal-sounding jargon. Some of the rules may be intuitive and considered basic common sense. However, please keep in mind that the overall goal is simple: to participate online in a respectful, relevant way that protects the company’s reputation.

A great list of sample policies from existing organisations, some of which are written with industry specific rules, is available at Social Media Governance. It is well worth a read. The following is a guide highlighting some of the dos and don’ts covered in most of these policies.

DO:

  • Protect confidential information.
  • Respect copyrights.
  • Be credible, transparent and identify yourself as an employee.
  • Be in a position to offer comment from a point of clear knowledge of the subject matter.
  • Avoid jargon by writing in simple terms.
  • Use caution. While not all company employees are official spokespeople, please use caution in your comments as reporters and analysts may report on anything included in your online postings. Also, once online, the comments are cached, distributed quickly and available effectively forever.
  • Secure approval. If you are an official spokesperson for the company, you must submit each posting to for review / approval before posting. If you are not a spokesperson, you will need to check with the company to determine if your blog and postings need to be approved.
  • Make it clear that your views are your own and do not necessarily reflect the views of your employer.

DON’T:

  • Comment on merger and acquisition activity.
  • Discuss future product offerings, including upgrades, or new releases.
  • Make growth predictions of any kind.
  • Break out revenue by specific product or country.
  • Use any inflammatory language or discredit others’ views.
  • Provide headcount numbers for any country, region, group or department.
  • Discuss customers that are not currently referenceable to the press.
  • Provide the number of customers for a specific product area.
  • Speak for the company.
  • Lie.

Even if your not sure what a Social CRM strategy is all about and your current strategy is that you have no strategy, a policy providing guidelines to employees on the use of Social Media is an excellent platform enabling employees and customers to engage in dialogue about your products and services. That’s the beginning of a beautiful relationship.

Your hosted application is a virus vector

We are all used to seeing SaaS as an acronym for Software as a Service. It also doubles as another acronym for the non-functional features of a SaaS architecture. When you’re providing a hosted service there are a number of non-functional features that need to be considered such as Scalability, Availability, Agility and Security. I’ll flesh out these concepts at a later date as they are all quite broad and encompass a lot of features. Security, for example, includes, but is not limited to ensuring the integrity of the system and the systems that connect to it.

One threat to system integrity is a computer virus. If your hosted application becomes a vector for the dissemination of viruses to your clients system it becomes a threat to your business, not just your systems. So, how do you test you hosted application to make sure infected files are handled properly?

At the beginning of this year I started working on Oracle CRM Sales Library OnDemand, which permits the uploading of documents to be shared with others in your organisation. It provides a rich set of social networking features that enables users to share, rate, review, and tag PowerPoint presentations an MS Word documents so that everyone in your organization can leverage the most effective sales materials. To share a document, or it’s contents, it must be uploaded to Sales Library and of course, the upload process involves virus scanning. In fact, virus scanning is the first step. Irrespective of the file type, before any logical validation takes place, such as supported formats, the file is interrogated by an anti-virus system. When a file fails the virus scan, the user has to be informed with meaningful message. So, while your hosted application does not have to be coded with anti-virus logic, it does need to be able to handle and report effectively, when a virus is found.

Once you have this logic in place, you have to be able to test that the behaviour of your application is correct. Now, you don’t want your development or testing environment to be using files with viruses to test with. In fact, your organisations anti-malware system would probably prevent you from storing the files anyway. Thankfully, the European Institute for Computer Antivirus Research has a solution. For testing the anti-virus error handling logic in our application we attempt to upload a file with just the EICAR test string as content.

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

The above is not a virus, but is a test string for anti-malware systems. In unit tests, this can be used as the only content of an InputStream. You should provide a dummy implementation of your virus scan system when unit testing too. Remember, you’re not trying to test the anti-virus software. You want to test the behaviour of your application when the anti-virus software reports a virus is found. When testing the deployed Sales Library application, the text file can be saved with a .ppt or .doc extension and then uploaded. The only content of the file should be the test string.

I have yet to find an anti-virus system that does not comply with this EICAR anti-virus test string. A simple test in your own environment will reveal if your anti-virus software does or not. I suspect that it will, and you can proceed with confidence that your hosted application is handling contaminated files properly for the protection of yours and your customers business.

Sanity check your ORM

Have you ever had your application completely crash under load and wondered why something that just worked fine yesterday can drive you mental today?

Most of the time an Object-Relational Mapping package is the right solution for your applications to interact with a database. It does not matter if it is free, commercial or home grown, you will generally find that it reduces the amount of code. Moreover, the application code is better designed and easier to test. Depending on your chosen solution, you may even see performance improvements with caching and database specific optimisations.

However, you may also find substational performance degradations when the data volume increases. It is important to remember that no matter how sophisticated your ORM package is, it may still produce inefficient SQL statements. If you had SQL statements embedded in your code you would review that as part of the code review. So if you are going to hand over a critical operation such as the generation of SQL statements then these need to be reviewed.

Your application can become a performance crime scene. What can you do to prevent it? Early analysis.

The execution plan, sometimes called query plan or explain plan, for an SQL statement will provide insight into how the database will act on the SQL statement. It is available in most databases and is a useful tool to determine the efficiency of the statement. For example, an execution plan can indicate what indexes would be used. When code is being reviewed, the execution plans for SQL statements should also be reviewed, in much the same way that the running test classes would be reviewed for correctness.

I learned this the hard way when I found a delete operation took too long and eventually timed out in a test environment that had a high volume of records. A review of the code showed a nice, clean object oriented design and a very simple, easy to understand ORM configuration. The application in question was used to manage financial documents. It had the concept of a ChequeBook, one or more Cheques in a ChequeBook, but also that both a ChequeBook and Cheque were a Document. The class diagram in this article illustrates that relationship. The relationship was also reflected in the database with corresponding tables. The ‘type’ attribute was used as a discriminator for the two concrete objects: ChequeBook and Cheque.


The problem arose when attempting to delete a ChequeBook. The ORM could delete the Cheque records using the parentContentId easily enough, but since there was no corresponding column on the Documents table, the ORM then produced this innocuous looking statement.

DELETE FROM DOCUMENTS
WHERE TYPE = ‘CHEQUE’ AND
ROW_ID NOT IN (SELECT ROW_ID FROM CHEQUES)

Appears quite innocent at first, in fact it might even be thought quite a clever attempt to clean up all records on the DOCUMENTS table that should have a corresponding CHEQUES record but doesn’t. In the development database with only a few hundred CHEQUES, this performs ok. Push that up to a few thousand and you soon realise the problem with doing this blanket select statement on CHEQUES even if it does use an index.

In this case I had to code around the ORM with a hand crafted SQL statement. I could have just invoked remove() on each Cheque entity, but for large ChequeBooks this would have produced a lot of SQL statements. Another approach could have been to use a stored procedure but that would not have been easily portable.

The key lesson learned though was to sanity check the ORM before it drives you crazy with it’s unexpected eccentricities. Check your ORM documentation to see how you can get profile details of the SQL statements generated. Go to your database server and get reports on SQL execution plans. The ORM is effectively another developer on your team generating SQL statements. Know and understand what it is producing.

A new decade for Enterprise Java Applications

We are coming up on the 10th anniversary of the EJB 1.1 final release. When you take a look at the J2EE specification and the Enterprise Java Application programming models and frameworks that are out there now you begin to appreciate what an important step the EJB specification was. Not so much for what you can do with it today, but how it introduced a paradigm shift.

A more recent paradigm shift is cloud computing which effectively puts the application container, in a container. One to watch is CloudFoundry which provides a pay-as-you-go platform using the SpringSource application server. This is a Spring base java application server which is built on Apache Tomcat. The CloudFoundry makes this platform available using Amazon Web Service infrastructure. Although still in beta, it is available now.