I am working on a new database for a client, the original was developed several years ago. A lot of effort has been put into the new version to make it easy to use and efficient. Part of this process has been identifying the business process that the database is supporting, and determining what data is required. Not surprisingly the old system has been collecting a large amount of data that is completely unnecessary.
However old habits die hard and one of the managers is upset that there is no place in the new system to enter all the data that they have been typing in for years.
The fact that data is still being collected (from paper forms and an existing web site) doesn't mean it should go into the database. It's not the issue of storage, it's the time wasted on data entry and support.
Friday, April 22, 2011
Wednesday, April 20, 2011
Happy developers
I've been re-reading some classic texts, again.
Fred Brooks in No Silver Bullet observed way back in the 1960s that developers don't need specifications, they are happy to invent as they go along.
Fred Brooks in No Silver Bullet observed way back in the 1960s that developers don't need specifications, they are happy to invent as they go along.
Business Re-think Part 2.5
Following on from the previous post, here are what I see are the main challenges and solutions to implementing our new business model.
* The client has to know what problem they want to solve. (Business Process)
* We need agreement that the solution we propose will solve the problem. (Project Plan)
* We need to agree on the scope of the solution so that we know what to build, how much it will cost, and determine when the project is finished. (Scope and Specifications)
I'm becoming more and more convinced that some decent time needs to be spent defining the *problem* in detail. This includes the business process, but also includes exploring the "solution space" with quick proof of concept databases and rapid prototypes. This is required because people don't know what they want, but they know what the DON'T want when they see it. Rapid prototypes and story boards and diagrams are ideal for discovery.
FileMaker is an excellent tool for rapid prototypes.
* The client has to know what problem they want to solve. (Business Process)
* We need agreement that the solution we propose will solve the problem. (Project Plan)
* We need to agree on the scope of the solution so that we know what to build, how much it will cost, and determine when the project is finished. (Scope and Specifications)
I'm becoming more and more convinced that some decent time needs to be spent defining the *problem* in detail. This includes the business process, but also includes exploring the "solution space" with quick proof of concept databases and rapid prototypes. This is required because people don't know what they want, but they know what the DON'T want when they see it. Rapid prototypes and story boards and diagrams are ideal for discovery.
FileMaker is an excellent tool for rapid prototypes.
Tuesday, April 19, 2011
Wrong seat
I flew to Melbourne on Monday morning, from Sydney. An unremarkable 65 minute flight. Except that when I got up to get my luggage after landing I realised that I had been sitting in the wrong seat the whole time.
Thursday, April 14, 2011
Prototyping
One of the HUGE advantages of working with FileMaker Pro is the speed at which proofs of concept and prototypes can be churned out. There is no better way to decide an issue than to try it out, both for the developer and the client.
I'm doing a database that consists of organisations and the services they provide. The "users" of this database are telephone hotline staff. In a single day I was able to put together two very fast prototypes to test ideas for interface and get feedback from the users.
I'm doing a database that consists of organisations and the services they provide. The "users" of this database are telephone hotline staff. In a single day I was able to put together two very fast prototypes to test ideas for interface and get feedback from the users.
Monday, April 11, 2011
Interface Restrictions ≠ Data Security
Today I worked on a client's system where the developer had disabled export from the menus. They needed the data out. I got called in to fix the problem but it turned out that nobody had the full access password, and the developer was overseas on holiday.
After spending some time working through password possibilities, it occurred to me that the export restrictions were caused by the disabling of the command in the menus. So I tried the backdoor approach, and it worked. This highlights the difference between securing the interface, and security at the record level.
My "back door" method took only a couple of minutes to complete.
1) Create a new database file.
2) Delete the table that is created by default.
3) Add an external data reference to the main database using the user-level account.
4) Add a TO of the external table.
5) Create a layout to display the external table TO.
And voila, the entire data set is available via an interface with full menus. That's because the security was provided by the original interface, yet we've simply by-passed it. It can be fixed by disabling the ability to export in the user account privileges in the original file.
FMP 11 adds additional security by optionally requiring a full access password to allow the file to be added as an external data source.
After spending some time working through password possibilities, it occurred to me that the export restrictions were caused by the disabling of the command in the menus. So I tried the backdoor approach, and it worked. This highlights the difference between securing the interface, and security at the record level.
My "back door" method took only a couple of minutes to complete.
1) Create a new database file.
2) Delete the table that is created by default.
3) Add an external data reference to the main database using the user-level account.
4) Add a TO of the external table.
5) Create a layout to display the external table TO.
And voila, the entire data set is available via an interface with full menus. That's because the security was provided by the original interface, yet we've simply by-passed it. It can be fixed by disabling the ability to export in the user account privileges in the original file.
FMP 11 adds additional security by optionally requiring a full access password to allow the file to be added as an external data source.
Subscribe to:
Posts (Atom)