Thursday, November 28, 2013

Transitioning from Access to....?

Let me start with two things:  a) This post is mostly for the Access-only "developer" that doesn't do much with other programming, and b) I started my career working with Cobol developers.  In the late 90's.  By then Cobol was, as it still is, a reliable, solid, trustworthy dinosaur.  Days could be spent debating the merits of any programming language or platform, but let's suspend that discussion and look at the parallel with Access.


Access has been around for nearly 20 years now, and like Cobol, evolution has slowed to a crawl.  You might say that Access 2010/2013 is a sign of evolution, but let's be honest.  2010/2013 contains two apps - one for client development, and one for SharePoint form/list design.  They share the same skin, but fundamentally diverge in terms of design decisions and capability.



Microsoft has done a great job with Access web services for SharePoint users, provided people try not to compare the Access web capability with the client capability, and you don't look at Access web services as a solution for enterprise-grade web capabilities.  But what about the "legacy" side of Access, the one hundreds of thousands of databases use?

My answer is, for better or worse, it's time for us to start transitioning.  In the same way that a lot of really bright COBOL programmers I know have done, we have to realize that the opportunity space for MS Access is shrinking.  The need for rapidly developed, business-user friendly database applications will never go away.  But the number of places Access will be used will continue to decline, and what I'd be curious to hear from readers is where you think people will go to solve the problem?