Google, are you serious about Enterprise Apps or not?

I'm not seeing any significant improvements to Google's basic enterprise applications namely, Mail, Contacts, Calendar, and Documents. They started fast and heavy building out the features or buying companies with existing products but lately, it seems they're in almost maintenance mode. They're far from done and still (way) behind Microsoft Office. So, what gives?

I host my own domain (standard) on Google and use it for personal needs. I love the Calendar app, the sharing features in Calendar and Documents, and the corresponding apps for my Android phone (wish my iPad had the same apps).  There's enough functionality to satisfy me "the consumer" but not me "the enterprise user". 

For the enterprise, I look at every application from 2 perspectives, UI and API. You need both for a great UX. Users want a great UI and all their apps to work seamlessly together. Google's UI is improving, albeit slowly, but their APIs have stalled. There hasn't been any new versions in over a year now. The APIs were just OK to begin with so you'd expect to see a ton of improvements. Better support for structured data and a usable search capability are just a couple that come to mind. Can you believe that you still cannot search contacts using name, email, or phone #?

I like the idea of hiring a team to develop an application they've never built before. They're not bound by previous experiences so they can create a new (and hopefully better) experience.  BUT, at some point you'll need to hire some folks with experience to complement the team and build out the features users need. 

Are you developing API for your APIs (API4API)?

Huh!? Enabling automation of API consumption and adapting to application changes will play a crucial role in your API adoption. It's great to have your API's documented but it would even be greater if you allowed your API (metadata) to be introspected programmatically.

The new trend in applications (and API) is all about on-demand and self-service. Web 2.0 (Cloud) applications are more adaptable and powerful. Being able to integrate applications quickly will be key to their success. If you're only providing hard-coded documentation, then you're a speed bump to your application's success.

Exposing a set of standard metadata API for your APIs will allow developers to build tools to auto-magically consume your APIs and keep up with changes much more efficiently. Integration tool vendors often write connectors for applications which allows them to expose the various API in a standard way in their tools. Customers then use those tools to build out their integrations without having to worry about the low level details of every API call they plan to use. If you expose a standard set of APIs that would allow these tools to auto-discover your APIs and auto-react to changes in your application schema and services, your API consumers will love you for it!

When WSDLs were created, every one cheered for the fact that there was a standard way to describe interfaces. You can programmatically consume it and the very least, create stubs to provide/consume the service. It made getting started easier. Unfortunately, most implementation that I encountered only offered statically generated WSDLs that either only changed when the application was upgraded or required frequent exporting/importing to capture on-demand customizations. Painful at best. Now we have REST-ful services which are easier(?) to consume but you 1st have to read the often lengthy documentation to get started. I don't see anyone running to support WADL (WSDL equivalent for Rest-ful services). Do we need another static interface definition?

Forget WSDLs and WADLs! I propose, we create a standard metadata API for APIs (API4API). The key is to keep it simple so it will be adopted. All it needs to do is to describe objects and services you're planning to expose. For every service, defines the inputs and outputs. If you add more objects or services, a simple call would reveal them. It should also indicate the Authentication methods that are supported (e.g. Basic Auth, OAuth).

If your applications are evolving, If your application are customizable, then you need to give developers the ability to create dynamic integrations to keep up. 

Why Yammer can't compete with Chatter!

Security! I'm not talking about general privacy and security that all SaaS vendors provide like SSL, data center security, etc. I'm referring to much more granular level of data access control which is defined and controlled at the enterprise application layer. Most companies want to control data that their users access. Take a SFA system as an example. You typically see policies that allow sales reps to  see information about their own accounts and opportunities (only), sales managers to see data belonging to their teams, regional managers within their region, ... so on and so forth. So, you'd only want your users to see Enterprise "Tweets" that they should see.

Independent Enterprise Social Networking services, like Yammer, lack visibility into external system data and the data access control policies in those systems to control who should see what. Sure you can create logical groups and confine private posts to those in the group. You can even integrate in SAP, Salesforce, Oracle EBS, etc. as members of a group but you're still not going to know which specific data updates some one should have access to, at least not very easily and not without external and custom code.

Application administrators go to great lengths to set access control rules so it would be great if the Enterprise Social Networking service could enforce those same rules. Unfortunately, they really can't. First,  they would need access to the rules which is not easy to come by (not their fault). Second, they'd need a standard way of defining the external application objects and access control rules which doesn't exist today (again, not their fault). 

Chatter has an unfair advantage by being native to Salesforce. The same data access control rules you configure for your objects are also valid for Chatter feeds. Users can only subscribe to data that they have access to. No additional work required! However, Chatter will the have the same limitations as Yammer when it comes to data objects external to Saleforce. Salesforce does provide for the flexibility of adding custom objects and associated access control rules but you'll then need to make sure you synchronize the data with your custom object(s).

I'd say that CubeTree's sale to SuccessFactors was certainly a good move on their part. Once they're integrated into SuccessFactors, they'll be in the same position as Chatter but for HR related data objects contained within SF modules.

I hope you don't take this as a beat down on Yammer and like services but when it comes to Enterprise Social Networking, they're going to lack the necessary controls to be widely adopted.

Salesforce.com Chatter: Tips for Integrating External Enterprise Events

Integrating external events can be very straightforward (from Salesforce.com's perspective). Here are a few tips to help get you going quickly.

1. Every parent object in Saleforce is Chatter Feed enabled. By default, the standard objects have been configured to create Chatter events (or feeds) as result of creates and updates (of certain key fields). To make changes, go to Setup>Customize>Chatter>Feed Tracking. You can configure feed tracking for each object (custom included) to track changes to standard and custom fields. For more information, check out this link.

2. Any existing external data integration into Salesforce can instantly be Chatter enabled. Simply go to the feed tracking page for the object of interest and enable tracking for the fields you're updating.

3. For child objects like the Opportunity Line Items, you'll notice that there's no feed tracking capability. This makes sense as you would typically want to track an Opportunity as a whole and not just individual line items. If you're updating the line items with external data such as a "Ship Date" from your ERP, add an extra step to your process to create a Chatter Feed post for the line item's parent opportunity. It's a simple Create call to add a single record to the FeedPost object.

4. Avoid creating additional custom objects and synchronizing external data if all you're interested is being notified of updates from your external applications. It not only creates more work to create and maintain the integrations, it will also require users to subscribe to additional data objects. If you only need to present data from the external systems to the users, consider building a quick mashup instead.

5. Avoid creating a User Update or Post on behalf of an external system as it will potentially bypass the security rules you have in place and may expose sensitive data to your entire org. Since users can only subscribe to Chatter events for data they have access to, it would be a best practice to create feed posts associated with specific data objects.

Application Echo: Common Bi-directional Synchronization Side Effect

You set up 2 integration flows running in opposite directions that capture change events in 2 applications and replicating it to the other. Sounds easy enough, till you deploy the integrations and make a single change in one application. The 1st integration flow gets notified of the change and updates its target application. As a result, the 2nd integration flow gets notified of the change and updates its target application. Which causes the 1st integration flow to see the change....so on and so forth till you finally pull the plug and break the cycle. How do you stop this infinite application echo from happening?

You can implement a method which queries the target system 1st to see if the data in the target is different from the source and only apply the update if it is. While this seems like a good approach, it's not very efficient. It requires an additional query and field by field comparison for each integration flow which can be the cause of performance issues and can certainly put additional load on the target applications.

A simpler and less costly method would be to create specific user credential on each application that is only used by the integration flows to login. When an update triggers the flows, a simple check to see who last modified the record will let the process know to proceed or to stop.

What's a connector?

Connector is one of those over used words when talking application integration these days. Depending on who you ask, you’ll get different interpretations.

Application developers typically talk about connectors as the piece in between that connects 2 different applications together. For example, Salesforce to SAP connector which was commissioned by Salesforce to sync accounts between the 2 applications. When application developers refer to connectors, they usually are talking about specific point-to-point integrations that only implement 1 or more limited use cases.

When application integration developers talk about connectors, they are only talking about the piece that makes the calls to one application. It usually involves wrapping the APIs exposed by an application and exposing it in a uniform or standard way within the integration platform. It’s usually (but not always) use case or module  independent. In case of Salesforce and SAP, you’d have 1 Saleforce and 1 SAP connector. If you build an account to customer sync, that’s just called the integration which will use the connectors as means to get data in and out of the applications.

Connectors are some times referred to as adapters but that doesn’t change the meaning.

By the way, if you're looking for the Salesforce to SAP connector, it's no longer available from Salesforce.

Cloud-based Message Queueing and Persistence

I think given the choice, most developers rather deal with synchronous vs. asynchronous processes. It’s just much easier to wait for an immediate response and continue down your path vs. having to queue requests and set up a secondary process to poll for replies, perhaps correlate them to the original requests and then process them. However, since you can’t always control every application you need to work with, you will find that having a place to temporarily park messages for either later processing or pick up is necessary. You some times need UPS to retry delivering your package and some times you rather go pick it up at the distribution center.

As an example, if you ever worked with Salesforce’s Workflow and Outbound messaging feature, you’ve probably had to figure out a way to deal with storing the Outbound Notification from Salesforce while your Great Plains , Oracle EBS,... instance is down for maintenance. Salesforce’s Outbound messaging service will only retry a finite amount of times and then the notification is lost so having a place to temporarily store the notification until your application is back on line can be quite necessary.

For most use cases, you have plenty of options for persisting your messages, from simple database tables to more sophisticated message queueing software. If you’re looking to reduce internal IT costs and headaches, Amazon Simple Queue Service (SQS) can be a good option too. It’s simple to set up, it’s fully managed, and it’s very inexpensive. You have several choices of geographic location for the service, US East/West, EU, and APAC. The API is straightforward enough and since it uses standard Cloud-based protocols (RESTFul and SOAP WS over HTTPS), you can be up and running in no time. 

Amazon SQS uses a distributed architecture with multiple queue nodes and as most Cloud-based services go, it some times takes a little time for all the nodes to sync up and have the expected response to your request. Here are some of the behavior I noticed while playing around.

• There was almost always a delay (10-30secs) in availability of newly created queues. I would create a queue and then use the list queue service to see if it was there. Same was true when I deleted queues. They showed up in the list of queues for 10-30 seconds after I had a confirmation of deletion.
• Message retrieval seemed some what random. I would send a number of messages in a row and then try to retrieve them. I would get my messages back but in what seemed random groupings. I never lost a message so that was great news.

Overall, SQS was very reliable and as long as you don’t care about ordered delivery and you don’t that have messages that are > 8KB, it’s a viable Cloud-based choice.

Microsoft’s Azure platform offers a similar service which I haven’t played around with but it looks almost identical to Amazon’s SQS. I guess borrowing is the best form of flattery. The operations seem to be identical (1:1) to SQS and here’s a direct quote from their documentation: 

"A queue can contain an unlimited number of messages, each of which can be up to 8 KB in size. Messages are generally added to the end of the queue and retrieved from the front of the queue, although first in, first out (FIFO) behavior is not guaranteed.“ 

So pretty much the same as Amazon's SQS. It's great when your competition doubles as your PM.

If you’re looking for a Cloud-based message persistence service to complement your Cloud-based integration platform, Amazon SQS and (probably) Microsoft’s Azure both offer worthwhile solutions.