Archive for March 2010
Although we aren’t targeting mobile clients for our first couple of releases, we are architecting the Accpac 6.x series with mobility in mind. This blog posting isn’t meant to layout a roadmap for our mobility support, but to talk about what we are doing to support mobile clients and why. Mobile devices are proliferating. By mobile device, I mean anything you can carry around with you and stay connected to the Internet, from cell phones to iPads to netbooks. Typically these devices are connected to the Internet via cell phone carriers, or through WiFi hotspots.
The first key to our mobility support is Internet Browser independence. On regular PCs, most people run Internet Explorer. On mobile devices, almost no one uses IE. The most common mobile browser engine is WebKit an open source technology that is at the heart of the Apple Safari, Google Chrome and RIM browsers. Other popular contenders are mobile optimized versions of Firefox and Opera. For Accpac we need to ensure we work well in all these environments.
Generally we are taking the approach of running well in a mobile browser rather than developing mobile applications for each platform. If we were to do this we would need a version of Accpac for the Apple iPhone, iPad and iPod; Microsoft Windows Mobile; Google Android and ChromeOS; RIM Blackberry; Palm OS; Nokia Symbian, etc. This proliferation of mobile platforms has led to fierce competition and moved the technology ahead in leaps and bounds. But it makes it hard for software vendors to natively support them all. Plus there is the added complexity of dealing with all the separate application stores and all their rules and regulations. For us its way easier to be a well behaved Web Application that runs well in each device’s native browser.
The first thing is to handle hugely varying screen sizes. You can get racks that hold 6 large screen monitors and hook them up to your PC to get a tiled giant high resolution display, then at the other end of the spectrum, there are cell phones with huge computing power, but tiny low resolution screens. We certainly don’t want to optimize all our screens for 320×120 resolution and have a postage stamp sized screen on a big screen regular PC monitor. Our regular screens actually work fine on devices like the Google Android, but you have to scroll around quite a lot to get to all parts of the screen. In the Accpac 6 architecture the screen layouts are contained in separate XML files, unlike our previous VB6 technology where the screen layout was part of the program file. This allows us to maintain a repository of different XML files on the server and have some intelligence to serve up the correct layout based on the circumstances. It then becomes much easier to have minimal low resolution versions of the screens along with the regular ones. Plus all these can be customized. It might even eventually be necessary to produce medium resolution version for devices like the Apple iPad. On the other hand, the screens on these devices are getting better and better, but there are limits to what the human eye can discern. After all no one wants a giant cell phone, the smaller the better, so at some point improving the resolution doesn’t help.
We also need a minimal version of our main program Portal. Probably something with just a few big buttons to run a handful of screens, then when pressed each one takes up the whole screen with no Portal frame around it. Mobile users might even just run the screens directly in their Browser from their favorites menu.
Another difference in the mobile market are the input devices. No mouse and you are lucky if you have a qwerty keyboard. Touch screens aren’t as precise as a mouse and we have to have bigger buttons and controls or the user can’t select or manipulate them. New input devices like motion censors are present. What does it mean to Order Entry if someone shakes the iPhone? Does this mean clear the order and start over? Basically to work well on these devices we need to figure out what all these new metaphors mean to our Accounting Applications.
When we architected Accpc 6 to run in any Browser, the goal wasn’t so much being able to run in Firefox on Windows, it was more about extending the reach of where you can run Accpac screens, including PCs like Macs or Linux Netbooks, tablets like the iPad, or all the small cell phone based devices like the Apple iPhone and Google Android.
Quite a bit of attention has been turned to reducing the Total Cost of Ownership (TCO) of Sage products for Sage customers. Does this mean Sage needs to reduce prices? Does this mean Business Partners need to reduce prices? Paradoxically the drive to reduce TCO has nothing to do with reducing prices. It is all about making sure that there is true value in everything the customer is paying money for. TCO also goes beyond just the price of the software, M&S and implementation costs; it is also the cost of down time, the cost of learning the software and the cost of inefficient processes. Within Sage all groups are mandated to look into ways to reduce the TCO for our customers.
This blog posting is about how this is affecting development. What problems we are looking to address. Some will be addressed quickly and some will take longer. This blog posting is specific to Accpac development, but each development team at Sage is working on these same sorts of TCO issues, just each product has a slightly different set based on their unique heritage.
The most visible area that customers complain about TCO is the cost of upgrading from version to version. There are many aspects to this and a great opportunity to reduce TCO here. To be fair, a lot of these problems were caused by development in the first place. Often to shorten development cycles we could push some work from development off to the channel. For instance requiring that all batches be posted before upgrading, saves development and QA time, since we don’t need to convert the data in the unposted batch files; but shifts the cost to the channel who now have to charge to make sure all the batches are posted as part of the pre-upgrade checklist.
Hopefully with 5.6A you can see some first steps in making the upgrade process easier. These include:
- Shipping all modules together at one time, including all the language translations.
- Installing all products from one single installation program.
- Combining product updates into a single install for all the applications.
- Allowing you to run data activation as one process to convert the database for all applications in one shot.
- Providing free training, to help customers get up and running on the new version quickly.
- Providing better documentation on all the changes in the new version so there are “no surprises”.
- Bringing in a large number of customer databases to test database conversion. Plus testing database conversion as part of the controlled release program.
Going forwards in the new versions we are going to be working hard to identify problem areas and address them. Note that the following list isn’t a commitment to do all these in 6.0, but you will be seeing them over the next few versions:
- Making reports upgrade safe. Allow you to skip the step of verifying and re-testing all your custom Crystal Reports.
- Make screen customizations upgrade safe. When we move away from VBA for screen customization, we don’t want anything like the problems with re-adding all the references and fighting the EXD files.
- Work hard to make database conversion from version to version as robust as possible. Work to speed up database conversion. Self-heal any problems.
- Work with the ISV community to ensure ISV products are available quickly with the new version. Take great care that changes we make don’t break ISV products.
- Remove workstation setup. As a web based application only the server needs to be installed/updated. No more visiting hundreds of computers to run Workstation Setup/Database Client Software.
- Work on reducing the pre-upgrade checklist down to just performing a database backup for safety.
- Work on reducing the post-upgrade checklist to nothing. After installing and running data activation, everything else should just work.
- Being careful about the TCO implications of adding new features. For instance if we come up with a nifty easy to code improvement to A/R Invoices, but that change would require all custom Invoice reports to be re-created, then we probably wouldn’t do that feature. The ROI would need to be astronomically high, or besides the simple code change we would need to produce a utility to seamlessly convert all existing reports.
- Take care in changes that require operating system, database or hardware upgrades. These are all part of TCO.
Another area of TCO being addressed is productivity and learnability of the software. We have been building a large User Centered Design (UCD) team to study customer’s usage of Accpac and develop ways to improve the software. We have an observation lab where we observe and measure real customers performing tasks. We compare the results of old ways versus new ways, so we know we have improved things. The UCD team has a great deal of skill with coming up with better ways to do tasks, but we always test these by measuring customers actually performing these tasks. The goal of the UCD process is to allow customers to:
- Be more productive. Accomplish routine daily tasks like entering invoices quicker and more accurately.
- Be able to accomplish a new task without requiring additional training. Make learning the software much easier.
- Find using the software more enjoyable. Find pain points or frustration points and find ways to remove these.
Generally TCO is a definite competitive factor in our industry. It is also a key factor in providing an Extraordinary Customer Experience. We want to make sure everything we do adds real value for the customer. A lot of these things start in R&D, but hopefully you are starting to see improvements as we move forwards with each new version.
With version 6, Accpac will still be an on-premise deployed application. Even though Accpac will now be a Web Based application, customers can still deploy it on their LAN and do not need to expose the Accpac application to the greater World Wide Web. By not exposing the application to the Web and keeping it all behind a firewall and/or DMZ, their data will be very safe.
However more adventurous customers will want to expose Accpac to the Web. They will want employees to be able to login from home, airports, hotels or on the road. Probably from places (like many Hotels) where VPN is blocked by a local firewall. They will want their data just as safe as before, but much more accessible. For these customers especially, but really all customers, we have to do extensive security testing of Accpac to make sure their data is safe. Generally for security we want to ensure the service is available, all transactions are confidential and that the transactions can’t be tampered with.
Accpac will be setup to do all communications through a secure connection called Transport Layer Security (TLS) (previously called Secure Socket Layer (SSL)). This is a very secure method to protect the communication between two computers. It will prevent people spying on the network from reading the information or tampering with the information that is transmitted on the network. It also provides a high level of authentication so you know who you are talking to. This does mean that customers will need to purchase a server digital certificate so that remote clients can ensure they are communicating with the correct service and that an intermediary hasn’t been installed in-between (man in the middle attack).
TLS does not protect the Browser memory or the Browser User Interface. Malicious web pages may be able to steal data from our user interface forms (cross site scripting attacks (XSS)). Bad user input may be able to cause bad side affects by interfering with our business logic (SQL Injection attacks). We have to test our software to ensure the browser side of our web pages are secure and that malicious user input is caught and dealt with.
There are attacks that are outside the scope of our application. If customers don’t follow good practices for maintaining and configuring their servers, then perhaps they can be attacked independently of Accpac. If the customer has malware like a keystroke logger program installed (perhaps by a virus) on their computer, then that program can steal their passwords. These are threats even today with desktop applications. Hence the importance of corporate security practices, like virus checkers and reduced privilege users.
A form of attack that technology can’t solve is “social engineering” attacks. Say someone phoning a customer and persuading them they are the support department and need the customer’s password for some reason. These types of attacks are usually the easiest and most successful. Some sort of awareness training is required for employees to be aware of these and to know to never give out sensitive information like their password over the phone, or via any other means.
Other attacks aren’t intended to steal anything, but to just take your system down. These are denial of service attacks. A hacker could say setup hundreds of computers (real or virtual) to make invalid login requests to your web server. None would ever succeed, but the load of rejecting these, could make your system unusably slow. Or perhaps they can find a way to crash your web server or application. Then the hacker could blackmail you, so he’ll stop. Or maybe he doesn’t care, and is only just doing it because he can. Or maybe a competitor is trying to put you out of business. These are certainly very serious attacks that must be guarded against.
Security testing is fun, because the testers become hackers and have to find ways to break into the software. They get to use new techniques like fuzz testing to find problems (http://www.owasp.org/index.php/Category:OWASP_JBroFuzz). They get to study criminals to learn their techniques to ensure we are safe from them. Security tends to be a journey; hackers are always inventing new techniques to gain access. Often testers will use “hacker” tools downloaded from the Internet to ensure they can’t be used to compromise our application. The tester study the traffic on the wire with tools like WireShark (http://www.wireshark.org/) to study all the packets on the network. There are many tools to scan your application and server for vulnerabilities. Source code has to be reviewed and tested to ensure clever user input can’t cause problems from things like SQL Injection attacks (http://en.wikipedia.org/wiki/SQL_injection).
Generally we want to ensure that when installed properly on a Web Server using TLS that Accpac is a very hard to crack application. We will need to publish best practices for installing and configuring servers. Generally newer server operating systems turn everything off by default so there isn’t much for hackers to latch onto. Mainly its up to the operators to ensure only a minimum of services are installed, that all patches are installed and to monitor the server logs for strange activity. Hopefully this will mean making Accpac available to remote Web users will be fairly easy and safe. But as always with security it always pays to be vigilant.