“By putting employees on mobile devices, we got about 30% more work out of them"
- F500 Pharmaceutical Company, Model Metrics/Salesforce.com customer

Many of our customers ask us about mobilizing their workforce. In fact, 80 percent of Model Metrics customers include smartphone and tablet adoption plans in their cloud deployment initiatives. Most need guidance on where to start – from devices to development technology to application design. Model Metrics helps enterprises develop mobile roadmaps to ensure a successful mobile cloud deployment.

We ask key questions early in the project to help decide how to best launch your mobile strategy. Picking the development technology is often the last step, not the first. Topics we discuss with your team include:

• Who are the users & what do they need to do?
• What are their job tasks prior to, during and after a customer interaction?
• What is your branding message and how does the field staff reinforce this message?
• What systems and hardware do they have today?
• Do you control the mobile device or do you support Bring Your Own Device – BYOD?
• Are users connected via WiFi or 3G? How often?
• If users are offline, what are “must have” capabilities? What could they live without until reconnected?
• If you expanded mobile access and capabilities, what could else your users be doing? What do office based field support teams do that could be moved to the field?
• What internal legacy systems do field staff use? Or need information from?
• What external applications do field staff use? Or need information from?
• Do they need transactional data or summary? Both?
• Are there new device capabilities that introduce new job tasks, such as GPS, camera, mobile mapping?

An example of using new device capability to streamline work is to pull the GPS location of the device (presumably in the user’s hands) and display the account the user is standing next to. Bypass typing the customer name and instead query the app based on GPS coordinates. Turn on the device, press “sales call” and up comes the contacts, account, opportunity and past sales information.

With this information, we can help you build a business case to secure executive sponsorship and a budget. Can you boost productivity by 5%, 15% or 25%? Can a rep or service professional cover more accounts or dedicate more time to prospecting?

Often, the first phase of the mobile deployment is a proof of concept. The proof of concept kicks off the design process, proves the technology works and gives stakeholders the opportunity to better understand the app. This is especially helpful if you have an exec on staff with what I call ‘iPad fever’. “iPad Fever’ is when an eager executive is ready to dish out the dough for devices but needs a real business case. More than once we’ve heard “We bought a bunch of iPads, but need a real business app, not just Dropbox, Gmail and Angry Birds.”

Comparing your needs to the available and rapidly advancing technology leads to the right short and long term decisions. Below are mobile app choices from Salesforce.com are listed below with their common uses.

Are you afflicted with iPad fever? We can help. To start developing your mobile cloud roadmap, contact us at info@modelmetrics.com.

Here are some technology choices to consider as of the end of 2011:

Chatter

Deployment: Standard UI. Apple, Blackberry or Android App store distribution. Used online only. No cost. Common Customer Use: Private collaboration with co-workers, partners, selected customers. Read and post links, comments, pictures, etc. We have built custom Chatter screens to embed Chatter features into other apps.

Custom Apps via SDK or APIs

Deployment: Custom UI for any device. Can be online and offline. Leverage ModelFX to design user experience consistent with your marketing and brand messaging. Deploy via weblink, mobile device management tool, or iTunes App Store. Cost varies based on scope, amount of configuration and integration to legacy systems. Common Customer Use: The sky’s the limit for mobile apps. Often used with hybrid custom and custom objects populated from legacy systems to enable mobile access to legacy system data. The Digital Sales Aid app for the iPad helps (1) get started fast (3-4 weeks from kickoff to live users), (2) prove value to executives and (3) introduce mobile computing to IT. Great app to improve quality and volume of professional sales interactions. Other custom apps include ROI tools, mobile lead capture, product visualizations and product demos. A customer presented the story of the largest corporate iPad project at DreamForce 2011 in October.

Mobile Dashboards

Deployment: iTunes download for iPad to view all your dashboards while online. No cost. Common Customer Use: Handy tool to view dashboards from iPad. No re-configuration of your dashboards needed. Not as flashy as RoamBI but for no expense it’s great basic access to reports.

Viewer

Deployment: iTunes download for iPad to view your Salesforce.com objects while online. No cost. Common Customer Use: Unsupported simple online viewer to your full Salesforce.com database. No development or configuration needed to deploy. Recommend revising screens to fit new screen real estate.

Mobile and Mobile Lite

Deployment: Apple, Blackberry or Android app marketplace distribution. UI is based on your current SFDC pages. Typically need to build custom pages to appear well on mobile screens vs. PC browser. Designed for offline users. The iPhone app runs 2x on iPad, so you loose some screen real estate. No cost. Common Customer Use: Access to SFDC objects. Plan to configure special mobile pages in Salesforce.com to create basic mobile screens for your users (but don’t use VisualForce, as this does not work on these devices.)

Touch

Deployment: Coming soon. New HTML5 UI optimized for mobile devices.  Can be online and offline. Common Customer Use: Limited SFDC objects. Rumor is read only during first release in 2012. We expect to configure special pages in Salesforce.com to create appropriate mobile screens to fit the user’s screen size.

Are you afflicted with iPad fever? We can help. To start developing your mobile cloud roadmap, contact us at info@modelmetrics.com.

The one thing I have noticed in my time as a Force.com Developer is there is a fundamental difference between someone developing in the Force.com language or someone developing on the Force.com platform. Both have to figure out ways to work within the constraints of Force.com limits. People working with the language see the limits as a constraint but someone who works with the platform understands that constraints breed creativity. 

The fundamental difference is are you using best practices?

If you use the following in your Apex Code, whether it be controllers or triggers, then you are really working within the platform and using best practices. What I love about most of these rules as I see it is that they are already spelled out to us in the Apex Documents: 

If you have used all of the above or at least some of the above, then you can be considered a developer on the platform. They are all vital to making sure any application you build on the Force.com Platform accounts for any errors that can come up. Something as basic as someone adding a validation rule to the declarative side of Force.com can throw off all of your production code and cause the need for a rollback of data. One of my favorites is the for update used in SOQL queries. Its a great way to make sure that any records you are updating are locked from modification on the declarative side or the API. Many take for granted the possibility for deadlocking resources in the Cloud, but it can happen. 

The list above is not the end all be all of what it takes to develop on the platform. These are best practices as I see them and the list is definitely growing. 

If you have any question, comments, or anything just leave a comment below or reach out to us at @ModelMetricsInc

I get bored. When I get bored I code. Here’s an example:

 

Two hours later I had this: 

Which is all about this: 

This is my two hour Salesforce Chatter Air Application. Its simple enough functionality wise, all it does is:

• Login into Salesforce using Username, Password, and Token
• Allows a user with the Chatter license to update their Chatter Status (see code snippet above)
• Allows a user to see their current status
• Allows a user to see and refresh manually their Chatter Feed

The reason I created this AIR Application a few months ago was simply to drive my own adoption of Chatter. I was so used to using Social Network services like Facebook and Twitter from AIR applications that I wanted to see the same from Chatter. The awesome thing is that coming in the Salesforce Winter 11 release is a Chatter AIR application that puts mine to shame.

What allowed me to build the application out in two hours was really two things: the fact that all you need to do to update your Chatter status is to update the CurrentStatus field on your User record and the ability to parse quickly through the FeedPosts, FeedComments and FeedTrackedChanges from my Users NewsFeed. 

After making sense of the Chatter object model and parsing through it I was able to take the Feeds and any subsequent data that was needed and insert it into a really simple Flex DataGrid. 

A few text boxes, buttons and a data grid later and boom, AIR Application.

Keep in mind that only API version 18 and above will have access the Chatter objects.

Now this is the part of the post where I would provide you source code, but that’s really not necessary. In the time between when I built this AIR application and now there have been a ton of resources here at http://developer.force.com/chatter. What they have there basically blows out the water what I have and with the new Chatter Visualforce components if you do want to build an application on the platform its very easy.

Working with Chatter is very simple. The Visualforce components that are coming out and the fact that you can simply post your status on your User object really made the whole experience very smooth. I urge all Force.com Developers to get into Chatters metadata and platform offerings and see what they can do with it.

Questions? Reach out to @ModelMetricsInc on Twitter. 

Whats wrong with this picture?

There are a few things, but one thing that is obvious which is the basic part of this story:

1. This code and any and all Trigger code must be in classes. Triggers run with System Admin privileges and don’t take advantage of any sharing rules or any security restrictions. That is why Apex classes have “with sharing” in their declaration
2. The error message should be on the Stage field because its an error driven by the stage field.
3. The error message itself should be a System label so if it needs to be translated or changed it can be done without developer intervention.

Other than that its perfectly compilable and runnable code. It addresses whichever use case needs to be addressed and can be unit tested with relative ease.

The BIGGEST issue with this code is that it shouldn’t exist in the first place.

This is what it should be:

The story always is that Surgeons cut, Doctors diagnose, and Coders code. There is always the temptation to cure every and all issues with code. Its what we know how to do well and its what makes us different from others. But none of this means that, as a Force.com Developer, it should be the only weapon in your arsenal.

At Model Metrics we enforce the necessity of Salesforce certifications. For anyone who does Apex code or works with the API we require that they at least have the Force.com Developer certification. If you have either taken this certification or the Dev 401 training you know all they talk about is the declarative portion of Salesforce, not custom.

Something we take for granted is that it needs code. Force.com just as a declarative platform is very powerful and even the most complicated use case can be fulfilled with just clicks.

If you were to come to me and say “I want to lock this parent record with a Checkbox and I want all of the subsequent child records, hundreds of records across eight different sObjects, to be locked as well. A coder will tell you “Sure, we just have a trigger on each of those sObjects, all eight of them, and query against that parent record to see if it is locked. If it is, don’t let them edit the record.” A Force.com Developer SHOULD tell you “Sure, we just have to put validation rules on each child sObject that looks up to that checkbox through the parents lookup field.” The difference in development and support time between the two is staggering. The coder will take a good long time to create eight triggers and subsequent unit tests and make sure they work with any current code existing in the org. The Force.com Developer will do eight validation rules and it will take them an hour. Maybe less.

Now if you were to tell me “I need to do a check across all child records” or “I need to do a callout to an external web service” then OK code it is. Of course keep in mind you can’t do a web service callout from a trigger(yay @future tag!).

There is always the temptation to code first, ask questions later. Force.com Declarative is easily maintainable and doesn’t require any engineering knowledge to work with(but we are more awesome with them!). Apex and the Force.com API allows a Force.com developer to fulfil those use cases that the declarative portion can’t address. Its easy to differentiate between Declarative vs. Custom. Setup a devorg, read the Salesforce books, and take the Developer certification. If you can do that, and you know how to code that’s not IF THEN ELSE, you're a Force.com Developer. 

Theres a few rules that I've learned while working with Salesforce/Azure/Amazon Web Service/Google App Engine that everyone should follow:

1. Manage your DB read/writes - It may seem beneficial to do a write then a read for the latest data, but manage the data in cache so you don't waste precious resources. Many Cloud providers lock down your DB read/writes, keep those limits in mind.
2. Be mindful of memory - All of the cloud providers, especially Google App Engine and Salesforce have limits on Heap size. Refresh your lists, make sure your heap time is properly managed. Everyone provides some form of garbage collection, but they won't watch your resource limit for you. 
3. Always cache your public pages - All of the provides have a hard limit on bandwidth. If you don't have proper caching, you'll hit your limits and lose money when you don't need to. 
4. Make "More Hardware" your last resort - As software engineers we usually prefer to say "Toss a few boxes on, cluster it, and boom were golden". When it comes to the Cloud resources = money. Unroll loops, deallocate memory how you can (clear list and maps OUT after they aren't needed), and be mindful of memory leaks. 
5. Triage scheduled jobs - Scheduled jobs are those special processes that happen when you need them to happen but be very careful. If the cloud goes down and your needed job doesn't happen, you could be in a heap of trouble. If its REALLY necessary then have a manual process or a servlet setup that can be run later on to make up for that missed job. 
6. PAY ATTENTION TO ENVIRONMENT UPDATES! - When your Cloud provider releases a new SDK, updates your environmental variables, or makes a change in any way, KNOW ABOUT IT. Cloud providers are constantly upgrading their product, and since its in the Cloud they will update it and you will need to deal with it. There is no "OK this app works with Tomcat 5.5, so we don't really need 6.0." No, they will give you 6.0, and your application could crash and burn. You may need to make some changes but so what, get with the program or get off the Cloud. 
7. Someone else built your security - Every cloud provider has their own security setup. Now you don't have to build one, great! But it keeps changing, not so great! How your provider chooses to manage your apps security, authenticated or unauthenticated, can and will change. Like before, pay attention to security updates. Make sure your app is XSS and XSRF safe even if your provider makes that guarantee. 
8. Is your application Cloud Ready? - Your Java application uses Struts. You wan't to use either Google App Engine or VMware's vSphere. Uh-oh, GAE Java uses Spring(sort of) and vSphere uses SpringSource. OK, should you rebuild your app or go over to another provider such as Amazon Web Services? Know this before you start refactoring.
9. Know your costs - If your app needs to grow, the Cloud can accommodate………….at a cost. Its hard for a developer to see dollar signs when they need something done but you need to learn that with great power comes great responsibility. If you want to start your own Cloud ISV, make sure your income statement keeps those growing Cloud costs in check. 
10. Remember: You're Sharing - You could have three boxes, you could be with three other people on a single box, you do not know. Keep in mind that if you screw up big, it can affect alot of people. Safe virtualization techniques by your Cloud providers can prevent this from happening from the most part, but take some of your own precautions. Most cloud providers don't allow for any real multi-threading, but if they do remember the following: avoid deadlocks and race conditions. These aren't just kernel issues, they're hardware issues and can do some real damage to other peoples applications. 

Nearly all of my recommendations are the the same as if you were designing a C application for a router. Be safe, be secure, and watch the expenditure of money and resources. Keep these things in mind and you will have a great experience in the Cloud. 

Model Metrics is fortunate enough to work with three really interesting – and really different – companies in the Cloud Computing space: Salesforce.com, Amazon Web Services and Google App Engine. The question I get most often is “What’s the difference?”

It’s a fair question, so let me answer it using a food analogy.*

Amazon Web Services – AWS – is a bunch of raw ingredients: flour, egg, vanilla – everything you need if you want to bake a pretty decent cake. But you have to know which ingredients to use, how to combine them and how long to cook the whole thing for.

Google App Engine – GAE – is a cake mix. It has most of the ingredients but you have to add some and do a bunch of work. You have to add eggs and oil, stir, bake and frost. You do that work using their recipe and you do indeed get a pretty tasty cake.

Salesforce.com – SFDC – is a fully baked chocolate cake.** And you get to pick the frosting. You can use the frosting it comes with out of the can or you can make your own. And if want vanilla or fudge marble, you can probably make that happen too.

What will be interesting is to watch how the different players in this market try to climb the food chain to be more cake like. AWS and GAE may never choose to create a full cake the way that SFDC has but, then again, they might. I’m pretty convinced SFDC will keep their lead in this area for a long time to come.

After SFDC, I’m most interested in AWS – there’s a lot of real power there. For the next few years, there will be some really interesting work done in fork lifting applications from some dirt bound deployment to AWS.*** Organizations looking to gain instant benefit from Cloud Computing can by simply deploying a bit differently than they do today. AWS is a great destination.

That’s my cake analogy. Hopefully it gives you a taste for the flavors of Cloud Computing you might take advantage of. ****

–

* Food. Yum yum yum. If you’re coming to Dreamforce 2009 and are looking for food, come find me and we’ll go get something. You’ll probably need to remind me of this post.
** True signs you use an iPhone too much: you try to insert a period using a double space. As I just did here. Three times.
*** GAE isn’t a great option for this – GAE works best for new development.
**** Get it? “Taste?” “Flavor?” Awesome, I know.

Posted a couple of minor updates to Cloud Converter, mostly small bug fixes that affected the metadata explorer feature. If you already have it installed as a web tab in your org, there’s nothing you need to do. You automatically have access to these. Enjoy!

Had an interesting challenge the other day: all the best last data migration plans were failing. Why? The tool of choice — which one is not important — failed. What to do?

I used Cloud Converter. Quelle surprise, right? I could have used something else, but it’s some decent code that I’m familiar with — so I used it. How?

I first did a test to be sure the API was working using a SalesforceSession object. Why test? Well, you never know. Why the Cloud Converter provided "SalesforceSession"? It’s easy. One line of code or so with a valid user and I established that the user was good, that the API was functional and that the user had rights to the API.

Sweet!

Then I moved to the source documents. I had two kinds: Simple CSV’s and Complex CSV’s.

Simple CSV’s were easy. I added a standard Java FileReader to the sample code, pointed it at the file, and split the data into component parts. Then I built a collection of "Sproxy" objects, added the SalesforceSession to a SalesforceDAO and executed an upsert. Start to finish, about 5 minutes for the first file.

Complex CSV’s were tougher. The difference between simple and complex was that the data contained commas. I know, this seems like it should be relatively easy, but at the time I was drawing a blank. So I imported those Complex CSV’s into Excel, saved them as Excel files and then used another Cloud Converter class, ExcelConverterService.

ExcelConverterService reads an XLS and breaks the data in the cells into a collection of type safe objects. Then I did the same thing I had done with Simple CSV’s: iterated through the data, added it to a Sproxy collection and threw it at the API.

Eh voila – instant data load.

Truth be told, I would rather not have had to do it this way. But when all else failed, it was nice to have an extra tool in my kit.

You can find Cloud Converter over on Google Code or on Developer.Force.com.