I am currently working on a customised reporting solution. I have complete control over the initial design and implementation with some minor limitations which I wil explain below.

First some background…

I am a full-stack software engineer at a data storage company that deals with a number of big clients such as Reebok, Sears (RIP), etc. Our product is essentially a wrapper for an existing backup solution.

When a client signs on, we provide them with a custom built, pre-installed back server. These clients/servers can be located anywhere. Our help-desk persons are responsible for monitoring these systems for backup statuses and system integrity.

Presently, each of these systems include a 3rd-party powershell script that must be executed manually or as a task created, by the given help-desk person. They do so by RDPing into these off-site systems. These powershell scripts compile a report and send it off to a representative of the client as an email attachment. This can be pain-stakenly time consuming given the number of clients is growing steadily.

The help-desk person may or may not be tech savvy beyond what their job description may describe.

The requirement…

A dynamic solution that provides the help-desk person with the ability to query the server system and determine the backup status and system integrity on the fly without having to use RDP.

The solution should provide monitoring and inform the supervising party of any changes in real-time. (eg. push notifications, emails, etc)

The solution should require no direct supervision. (eg. a windows scheduled task or service)

The solution should be customisable in regards to report scheduling and report settings.

• Staggered scheduling (eg. When and what sort of report to create and what to do with it.)
• Granular reporting (eg. What should be on the report.)

Initial design approach…

The initial approach suggested by the management was to have the following:

• An in-house client report database. (eg. Each time a report is created, it should be persisted somewhere in a queryable json format.)
• A supporting web service for the client report database. (eg. A client report is added and can be queried via a web service method call.)
• A configurable/scheduleable reporting console application. (eg. Resides on the client server and creates reports and relays system health and integrity. Can be executed as a windows scheduled task or via command prompt.)

Pros:

• More straight-forward and easier to implement.
• Less initial configuration needed.
• Less moving parts and therefore more dependable.

Cons:

• The reporting console application is executed on a pre-defined schedule via windows task scheduler and therefore less configurable.
• Real-time reporting relies on the interval of the scheduled task.
• Occasionally managed by supervising party.

Updated design approach…

After much confusion and wheel spinning due to inconsistent expectation of requirements, I finally worked it down to the following:

• An in-house client report database. (eg. Each time a report is created, it should be persisted somewhere in a queryable json format.)
• A supporting web service for the client report database. (eg. A client report is added and can be queried via a web service method call.)
• A windows reporting (heartbeat) service (eg. Checks the system health and status at a given interval and notifies supervisor of changes. This would also be responsible for creating reports and invoking the client report web service.)

Pros:

• Real-time reporting can be more reliable. (eg. heartbeat interval determines inconsistency.)
• Less management required by the supervising party.

Cons:

• Requires more initial configuration and setup.

Question(s) to you…

• Is there anything I haven’t yet thought of in the latest design described above?
• Is there anything you would do differently?
• Do you have any suggestions or thoughts?