Welcome to Part 1 of my series of posts related to Microsoft Access as a business tool. In this post, I discuss the use of Microsoft Access in organisations for Rapid Application Development (RAD). In my Overview post, I noted that like all technologies Access has a number of benefits but also a number of risks that needed to be considered, and whilst this post covers the benefits, I have tried to ensure that you the reader also understand the limitations or risk with each choice so you are able to make informed decisions as the need arises.
In making sure the scene is set, I view RAD in two dimensions:
Describing a set of tools to implement software quickly (rapidly) or;
The process behind or driver in getting an application delivered quickly
In this post, I have approached these by the business scenarios where RAD is commonly applied:
Delivering an application quickly when the business requirements are not full understood or documented
Delivering an application quickly to meet an urgent need
The need to get applications in place quickly is an ever increasing need for organisations who are under pressure to get technology in place to support rapidly changing business conditions an initiatives. As opposed to say 20 years ago, these needs are often short lived in nature thus the appetite to put in lengthy or costly technology projects is limited.
Whilst short term projects are increasing in nature, the need to have well-considered highly structured and engineered solutions for core systems such as accounting and other enterprise wide applications still remains. These projects by nature are complex and need large amounts of requirements as well as larger design considerations around scale and long term change. Given that RAD and in particular Microsoft Access are not generally fits for these type of projects, the remainder of this post will focus on RAD for:
Use in Iterative Proof of Concept development
The delivery of Limited Scope or Small Applications
Iterative Proof of Concept Development
While in a perfect world, an organisation is able provide their requirements accurately and immediately, the reality is that requirements specification is a difficult ,(often) tenuous and lengthy process. Much of the attraction (I believe) in Agile Methodologies has been in recognising that the traditional process of requirements gathering is problematic in modern organisations where:
Getting access to the key staff who understand the requirements without impacting BAU is nigh impossible and;
Even when you do get access to this staff, the requirements often change by the time they are rigorously documented
To add further complication, once the requirements are documented via a (often lengthy) requirements specification, pressure is then applied on getting everyone to "sign off" on these requirements as being a common understanding. Language being at the best of time, even documents written by the most competent of authors are open to interpretation and a common vision hard to attain. Most of us (including myself) are visual in nature and better able to make decisions from visualisations versus wads of text.
Generally, working as we naturally do requirements are best captured in a top-down approach whereby the high level outcomes of a new application are described, followed by increasing levels of detail or "sub detail". Using the example of a Hire Car Company documenting their requirements; "As a User I want to be able to capture the details of a Customer Loaning a Hire Car" will naturally lead to the next questions as to what details need to be captured about the Customer ? or What do we need to know about the Hire Car ? Early on in the requirements process, a clear initial data model starts to emerge, and in the case of the above we see that we have three types on basic information:
The details of the Hire Car being loaned
The details of the Customer loaning (se we can contact them if they don't return it)
The details of the Loaning (eg. When the car is being loaned out or returned)
In the above example, a crew of people working to articulate the details of the above items may get 80% but then on the system being delivered at a later date, the final visualised system triggers them to remember facts such as the need to capture Next of Kin.
So in accepting our limitations as humans, adopting the delivery of an incremental application makes sense. In an Incremental delivery where increasing level of specification is followed by delivery, the approach looks something like:
The most important features (requirements) are discussed and documented to understand the basic flows of the application;
A working prototype of these features is developed to allow users to "drive" the system and through a tangible experience;
Refine the application and amend as necessary
Repeat 1-3 gathering an increasing level of detail
Microsoft Access provides a perfect tool for the prototype for the above for the following reasons:
It is widely available in organisations that are Microsoft Office users
It is highly visual and fast to implement basic User Interface Designs, which can be worked through side-by-side with business users with the application developer (an ideal way to get user engagement early)
The process and use of Access as described above provides for the delivery of working software which may or may not be deployed into an organisation. It is advised that at regular intervals an assessment is made as to whether the current state of the POC (prototype) delivers a working preview of what is required and if so, now what ? It is likely that some will see that the application in front of them is "ready to roll" and pressure may start to mount from an impatient business to just "roll out" what is there or spend limited additional time to wrap it up and move onto the next business problem
Certainly, Microsoft Access applications can (and are) deployable as are and this may end up being the best option, but here are some of those "considerations"I've been committing to address:
Number of Users: Access is not designed as a large multi-user tool. The more people accessing an Access database the less performant it may become. This can be addressed to a degree but needs consideration if your planning to use the solution for more than a handful (5-10) of users. Along with this the concept of Concurrency emerges which questions whilst the user cound may be low if they are all "hitting" the database at the same time, issues can arise.
Web Deployment: Users have become exposed to (and used) an increasing number of their applications being browser based. This expectation means users expect to use an application from wherever they happen to be with access to a browser. Options with Access are limited in this manner and will ultimately rely on a Windows Desktop to reside on somewhere in the solution.
Security: Like the user count consideration, there is no Out of the Box robust way of providing commonly expected features such as auditing the changes users make to data
The above may seem like a heady list, but a number of organisations may find the above limitations not of concern and/or choose to rollout the application to a small pilot group to start utilising the features accepting the noted the risks in favour of meeting business needs.
Often while the pilot group uses the application in a smaller setting, the organisation submits the (now) refined requirements for a larger development project. When it does come to taking a Proof Of Concept into a larger technology solution, significant risk has been reduced at this stage given that the requirements have been captured, verified and signed off through virtue of the Microsoft Access applications current state.
Limited Scope and Small Scale Application Development
In this Overview post for the series, I referenced my use of Access in developing a tool to collect information for my school year book. When this need arose I had actually become quite proficient with Visual Basic 2.0 and could have taken the opportunity to show off my growing programming skillset by building a well polished application. But a few things stopped me:
I was mid my year 12 exams and did not have the time (or to be honest desire) to provide IT support to my peers
Despite the fact that I could build a polished UI in Visual Basic, I could develop the same result in Access in 1/2 the time
I needed to distribute the application to several of my peers who were charged with collecting the data and being 1994:
I was limited to passing the data around on 3.5' floppy disks and;
at the time (as is the case now) installation programs can be a tricky and unreliable affair.
Fast forward 25 years and whilst the limitations of 3.5" floppy disks may have disappeared, to remains true in a corporate world we are always under scrutiny to develop solutions that:
Can be developed quickly
Can be picked up easily by staff without the need for increased IT support efforts
Are able to be deployed across a wide range of varied desktop environments
Whilst not the first choice in implementing the next corporate accounting system, MS Access does provide a great choice in building an application to quickly and accurately meet business needs for small applications with a small user base.
Here are some examples of MS Access tools that I have built over the past that have been used in a production sense (all within 1 to 20 days):
Client Database developed for a property company to take the details of Registration of Interest phone calls from clients combined with Mail Merge to provide an instant mail out following the phone call
Data Transformation tool used within a large scale data migration project to migrate data from a source system and build an import data set for the new system as the primary migration tool
Seminar Invitee and Registration database to manage the process of emailing invites to seminar attendees, tracking their response and capturing their actual attendance
Each of the above represent cases where a business need emerged to have an application built and rolled out to a small user base quickly, and whilst many were reused again for other reasons their need to not enterprise grade nor ongoing; so if you choose to go this path, keep your stakeholders well abreast of the abilities and the limitations as noted earlier in this post should the expectation to grow the user of these applications arise.
So that's the end of Part 1 on Rapid Application Development. In my next post I intend on discussing one of my favourite applications of Access in the field being it ability to connect to managed data in external systems.
Comentários