When we get firewood delivered, I usually poke around the pile to see if there are any interesting bits that might work better in my woodshop than the woodstove. The piece pictured below seemed to want to be a bowl. Unfortunately, as you can see it was difficult to expose the natural features and make it round. In turning it, I had to decide where to stop, as I was opening up more of the missing 80° gap with each pass. I stopped just before plowing through the undercut side, and ruining the piece. That left me with something between a functional piece and an artistic statement. Of course I’m sharing this because I see parallels to the discussion we are having at work.
Our current challenge is to decide which systems or parts of systems are going to be hand-crafted fat-client desktop applications (the stuff Microsoft has labeled ‘legacy’), which are going to end up in SharePoint and which will land on a phone or tablet. This is heady stuff, but like my bowl, I think our results will be defined by balancing our goals between form and function.
Desktop vs. Browser – Despite the legacy stamp, I can’t imagine anyone choosing to run transaction processing systems in a browser. I might enjoy the novelty of processing a transaction in a browser, but I can tell you from my experience with our expense reporting system, performing multiple transactions in a browser is painful. On the other hand, viewing certain reports in a browser as opposed to on paper has definite appeal. Of course we still need printed reports in some cases, but fewer than we have had in the past. Fortunately SharePoint and SQL Server Reporting Services (SSRS) lets us give that choice to the user. In between those extremes will be the functional elements that we can break away from the full-blown transaction. For example, allowing an underwriter to mock-up and request one of a few changes to a policy would make sense for several reasons:
- To add at these features to our rating system would be difficult
- These types of transactions occur less than 1/10 as often as complete rating transactions
- The component transactions appeal to several people and those people travel
Browser vs. Mobile – Notice that I’m not starting with Desktop vs. Mobile and for clarity, when I say mobile, I mean native mobile apps, not simply exposing a browser-based application on a mobile device. Until we get well beyond the point of the tablet replacing the laptop, I don’t see tablets or smartphones being the domain of transaction processing. I’m sorry, as much as people are all hyped up about being able to run full-blown Windows on a tablet, they aren’t going to replace laptops or desktops for processing transactions. You might be able to get everthing running, but who wants to work like that? For the foreseeable future, there will be a distinct difference between apps and applications. Apps will be rifle-shot accurate programs that allow for handling specific tasks from anywhere. Applications will remain shotgun style programs that cover a lot of ground from the comfort of a desk. Starting an automobile claim from an accident site, with a picture and a minimum of on-scene information is easy. Processing a complex cash receipt covering multiple transactions in multiple currencies isn’t going to happen while I am:
- Using a handheld device, or any device that prevents simultaneously viewing several legible windows/widgets
- In the absence of a horizontal work surface
- Using a tenuous or unsecure Internet connection
- More than 50’ from a printer
As with browser-based solutions, there are tons of opportunities to break out specific functions to mobile apps. The approval process is a great example. Approval is a rifle shot function, and it has to happen when it has to happen – a perfect match for a mobile device.
As I have mentioned in recent blog entries, we have been investigating SharePoint’s capability to fill the “in browser” circle of the Venn diagram I am imagining, and I am very happy with those capabilities. The key to SharePoint’s awesome potential is its ability to connect to the back-end data and the myriad ways it can manipulate and render that data. The person marshaling the transactions may want to be at a desk, the person approving a single transaction can use their phone, but the person who has an interest in the initiation or the results of those transactions will be very happy in a browser.