Software Factories: Part 3 – Smart Clients

[Software Factories Series]

A custom smart client can go a long way to addressing your Software factory needs and is in my opinion one of the most effective ways of reducing ongoing development effort.

A Smart-client can address many non-functional or repeating-requirements that will not have to be developed ever again.

Smart-Client Administration
An administration Interface for the smart client is essential to take admin away from the developers and hand it over to the support desk. For instance adding a new user or promoting a piece of functionality from Testing to Production can be done via an administrative interface. Within this client we embed a lot of functionality that would previously have been done by developers. I include Authorisation, creation of Data access aliases (See section on Data Access Agent), upload of new functionality into the Smart-client database, promotions between Development, Testing, Production etc, notifications to authorised users, work-flow definition and edits, creation of aliases to access functionality (menu-item naming) and any other administration whether done by developers or support-staff. I also recommend that the admin tools be built as functionality that snaps into the smart client itself – it just makes it easier.

Authentication / Authorisation
If your organisation uses a directory service of some sort, then integrate the smart client into the directory for authentication. If you have a generic authorisation services, then use that to authorise the client functionality as well. if not, link the IDs of your directory user into an authorisation table accessed by the Smart client Administration interface to link users to the functionality they require.

Work-flow
If your organisation uses work-flow, then definitely link generic work-flow functionality into the smart client so that it too is dealt with once.

Data Access Agent
If your smart client allows plugged-in code to access data directly, then you are missing a trick here. This idea has very powerful side-effects.

Define a method by which plugged-in code asks a function provided within the smart client for some data. The smart client should then source the appropriate data and return it to the calling plug-in. Some side-effects here are that the developers need not know any of your production database user-names or passwords, and you can within the smart-client infrastructure redirect data requests to other destinations (for example to your disaster-recovery site, or a testing database)

In the implementation I have built previously, we created a lookup-table for data-sources that indicated an “allowed calling-plug-in”, “operational-mode” a “Data-source alias” and the details of each data source. This allowed us to automate a switch to “Disaster-Recovery” mode through using a predefined “operational-mode” called “DR”. The Smart-client had a process for checking against a centralised web-service for which mode it should be operating in for a particular application. The flexibility here was staggering. This also means that the change management team can promote an program from Testing to Production without any help from a technical team whatsoever.

On-line/Offline modes
A web-based client or portal has the disadvantage that offline modes are not possible or at least very difficult to implement. A smart-client can do this fairly easily and with the “data-access agent” functionality above it is even easier to achieve.

Code Generators
I have found that most user interfaces that we needed to build were in fact forms that interacted with data-tables. We used a multi-tier architecture where the front end was smart-client (containing a data-access layer), a business layer consisting of stored procedures which performed a lot of the business activities and which interacted directly with the data-tables. So we created a form-builder that created both the stored procedures and .NET forms automatically. We would point the tool at a set of data-tables and lookup tables do some configuration and click “GO”. What we got out was a stored-procedure that conformed with all the rules we had predefined and a .NET project with all the necessary forms and the interactions with the Data Access Layer and Stored Procedures. If there were no fancy custom UI interactions nececessary we could simply compile the project, and upload the DLL into our smart-client database for testing.

So no developer-time required for:

• authorisation,
• basic form-based UIs,
• access to data,
• Disaster recovery implementations,
• promotions between Dev, QA, Prod etc,
• Creation of menus
• Creation of custom workflows

among others. This represents a significant saving in the development stage of any project.

Technorati Tags: Software Factory, Development, Custom Code, Code Generation