John sent me a request. Quite simply he wanted to know what his particular application design would look like in a SaaS delivered way. A detailed description of how John described his application is underneath but in essence it is a timesheet management system that is hosted on a central, but private, server and accessed via the web by users all over the place.

Is this SaaS? – I answered a resounding yes. My reasons (a transcript of my email to John) follows;

Wikipedia defines SaaS thusly;

The key characteristics of SaaS software, according to IDC, include:[5]

  • network-based access to, and management of, commercially available (i.e., not custom) software
  • activities that are managed from central locations rather than at each customer’s site, enabling customers to access applications remotely via the Web
  • application delivery that typically is closer to a one-to-many model (single instance, multi-tenant architecture) than to a one-to-one model, including architecture, pricing, partnering, and management characteristics
  • centralized feature updating, which obviates the need for downloadable patches and upgrades.

On the first point your software is custom – but spread sufficiently widely to infer that in fact the business en masse is your customer and as such you almost meet this requirement. I guess even more complaint would be to spin off what you’ve done and offer it to other enterprises.

On the second point – while there is some debate over where exactly software needs to be to constitute “in the clouds” the fact that yours is centrally hosted and available via the web to “customers” meets this requirement.

On the third – you meet the requirements – sure you don’t charge but it’s built into the business model so don’t lose sleep over it

On the last – once again you comply

The long and the short of it is that I’d define what you do, as you’ve described it, as SaaS. While on a conceptual and idealistic level it would be nice to imagine an aggregated and independent SaaS provider aggregating various different services (ERP, CRM, time sheeting, payroll etc) into which the business plugged in, given the size of your organisation this model seems pretty optimal.

The gist of my position is that SaaS is dynamic and just because something is a customised in-house application does not preclude it from gaining the SaaS moniker.

John is a smart guy and the sort who would be worth his weight in gold anywher in the world – shame we can’t aford to utilise him here in NZ! Here a detailed synopsis of the application design;

Timesheet Management

Timesheet Management is a set of Web pages, hosted in IIS on our payroll server.

They are presently available only to users on our worldwide network however I believe there will be a requirement to expose them on the Web in the future.

They are used by Managers to capture and maintain data relating to employee payments and are reasonably complex. They enter hours worked, pay rates in certain situations, expense information, sick hours, holiday hours, and all sorts of other things that are not relevant to this discussion.

To put this into perspective, these Web pages are currently used to capture pay information for more than ten thousand employees on a monthly basis.

These pages read data from, and write data to, other SQL Systems here in addition to the payroll system, and they feature automated reconciliation to the financial and banking systems.

Architecture

The data is all stored in SQL Server on our central payroll system here in London.

There is no client deployment of any kind – users all access the Web pages through Internet Explorer.

The Web pages are all ASP.Net Web pages.

The Web pages all make extensive use of a customised object library that I designed and wrote, which in context is a DLL that sits in the Bin folder in the application directory in IIS on the payroll server. Among many other things, this object library is responsible for ALL interaction with the various SQL Server databases.

It’s probably worth noting that this object library is also used extensively by all kinds of other Web applications I have done here – it was not designed specifically for this project.

The solution has many Web pages – here are two examples:

There is a page that is used by the payroll team to “open” Timesheets, which writes default data into the Timesheets table in SQL Server for a selected pay period and pay group. This page presents the user with some options, and then calls stored procedure(s) on the payroll server (through the customised object library) to write the data into the database.

So in this particular case, the ASP.Net Web page itself is very simple, and all of the complexity is encapsulated in the stored procedure(s) which get called, which is where I believe it should be.

The “main” Web page is used by all Managers to actually view / maintain / save / submit the actual data ( from above ) for payment to employees.

This is also an ASP.Net Web page that makes heavy use of the customised object library.

Again, the code on the ASP.Net Web page is very clean and uncluttered, because the complexity is all built into the customised object library.

The point is that virtually all of the application logic is handled by my object library, and virtually all of the database logic is contained within SQL Server stored procedures and functions, called by that object library internally as and when required.

 

 

 

 

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

2 Comments
  • Interesting 🙂

    I’ve been following the SaaS definition debate for a while now and it all seems a little familiar, ie. a new concept appears, gets a name and then the salesmen and marketers of the world attempt to co-opt it and apply it to every situation. At some point it becomes the magical Silver Bullet that will solve all the worlds problems, Microsoft attempts to embrace and extend and eventually if it has any true worth rather than being a marketing facade it just becomes another tool we all use.

    Can you remember Intranet, Extranet, Push Technology, Groupware, Web 2.0, OOP etc.

    I do like the idea of SaaS within the enterprise, something we briefly spoke a while back, but the following thought has been hitting me recently.

    One of the communicated benefits of M&A activity is usually reduced costs through consolidate infrastructure, ie. cost cutting in the back office. I’ve always been a skeptical though as to whether these cost saving ever really get achieved beyond simply making lots of staff redundant (how much does it really cost to move an aquired enterprise onto a completely new accounting platform just to centralise support?)

    However wouldn’t SaaS be the ideal platform for a conglomerate to deploy key business functions within unified enterprises? I can easily imagine Accounting, CRM, HR, Legal, OSH, Knowledge management, talent management etc. easily deployed to a closed user base within many organisations through the “cloud”

  • You’re dead right John – SaaS as the key to aggregating diverse but related revenue (or expenditure depending on which side of the fence you sit on) streams and combining them with efficiencies and synergies

Leave a Reply