I wrote about the importance of SMBs keeping processes and systems simple. I recently began work with a new client that was searching for ways to increase knowledge sharing across their organization. They were just starting the development of a new corporate intranet. They had spec’d out their needs and identified a sub-site to have custom developed. The analysts and developers did a nice job and it looks great.
But I recommended they hold on the custom development. They needed to evaluate MS Sharepoint’s capabilities before proceeding. Why? The basic corporate intranet portal has been built 100+ times already. Sharepoint, Plone, Liferay, JBoss, DotNetNuke and many others are decent out-of-the-box foundations for an internal site. So there’s just no reason to pursue custom development for this type of project.
But why Sharepoint? This client is also upgrading their core enterprise system. Turns out that the system based on a MS platform and uses Sharepoint for document management. Doesn’t it make a lot of sense to evaluate whether or not the platform used by your core enterprise system will work for the rest of your needs as well?
Right now, they seem to like Sharepoint and we’re now doing a test project to prove it to the company. If the test fails, there are other options. But custom development for an intranet should be a last resort.
One of the greatest developments in office software suites has been the desktop database. People have done some pretty complex things with relative ease using tools like Microsoft Access. Now, online databases such as DabbleDB and ZohoDB are advancing the tool and allowing companies to collaborate outside their own borders using secure databases.
I have a love/hate relationship with MS Access. Way back when, I spent a lot of time doing Microsoft Office development and Access was a favorite tool of mine. I liked that I could easily hook up to the enterprise databases, pull the information I needed and integrate it with any other application I happened to build.
But people who do Access development full time tend to get trapped into that box. When the task becomes greater than the tool, they simply find ways to make it work. And that leads to problems.
Nowadays I spend a lot of time supporting an Access database that has outgrown its skin. I’m rebuilding the application with a SQL Server back end, and ASP.NET and Sharepoint on the front end. But it’s a really slow process because there are so many business rules hard coded into the VBA. Identifying the code that has to be there versus what was done inefficiently is a real chore. And all the while I spend time helping users through crashes, data corruption, and reports that aren’t tying out.
So, here’s my advice of the day. Use Access. Or Dabble or Zoho. They’re great tools and fill a need. But when you need more than a couple users, have rigorous security requirements, need sophisticated data entry forms, or have complex reporting needs, it’s time for a different tool. Don’t put this off. Your application will only become more complex over time. And you’ll end up spending a lot of time and money supporting the application instead of improving your business.
Looking through my bio, you may notice a slant towards Microsoft technologies. I will readily admit that when I do application development, I mostly use Microsoft tools. That’s because Microsoft has always done a great job getting part-time developers like myself the tools and training we need to quickly build and deploy solutions.
So what does this mean to you, a business leader at an SMB? Well, I’m not a professional software developer, and I don’t try to sell myself as one. I focus on the business processes and then I find the right technology that will enable process improvement. I need to do my work in a way that does not box me into one potential solution. After all, if you hire an Access guru, you’re going to get an Access database no matter what solution will work best.
Once I understand your processes and can help you identify opportunities, I need to be able to quickly produce solutions that meet several criteria:
- The solution must fit in your environment with minimal additional investment,
- The solution must be able to scale with you as your business grows.,
- You must be able to use the solution without constantly calling me back for (billable) assistance, and
- If you do require additional assistance, you shouldn’t have trouble finding someone to support you should I get hit by a bus or win the lottery and retire.
Here’s an example. I needed to develop a multi-user application that would read data from a database and would write information to the client’s intranet. One of my client’s main concerns was that the application operate quickly. The client has no internal IT staff, and their intention to rapidly expand the scope of the application meant that distributing an application to PCs of the users was not a great idea. The database was MS Access, and the intranet was built on Windows Sharepoint Services.
A web based solution made sense for obvious reasons. I had never gotten much real-world experience with AJAX but the ability to process transactions without full page refreshes would certainly be appreciated. In a couple hours, I had built the required pages using the ASP.NET AJAX toolkit. We are now extending this application, and what I was able to produce in those few hours has enabled the client’s staff to think completely differently about their processes. Not only that, but the client is now moving their data into SQL Server 2005 Express. This application is remaining virtually untouched.
I certainly keep my eyes open when designing a new solution. If a client already has a significant investment on a LAMP platform, I’m certainly not going to recommend that they implement Sharepoint for document management. But more often than not, I find the client already has the environment in place to support a Microsoft approach. And I know that there are 20 other people in town that can pick up right where I leave off when my numbers come up!
