Shamil Salakhetdinov
shamil at users.mns.ru
Wed Sep 27 14:12:06 CDT 2006
Hi Dan, The quoted article is published here (watch line wraps): http://blogs.msdn.com/access/archive/2006/07/27/680772.aspx#comments <<< So, if MS can influence people to not use a high-powered tool with a low-skilled driver, the reputation of Access as a business app will improve. >>> Maybe write a petition to Microsoft to include MS Access 2007 runtime into MS Windows Vista? :) (Now, when MS Windows release is delayed and MS Office 12 release is on the way that could be possible to do?) BTW, "MS Access" gives ~112 million hits on google and Visual studio "just" ~87 million... -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Wednesday, September 27, 2006 10:29 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Moving out of MS Access? Hi Shamil, This is just about my favorite soapbox! In any organization, there is someone or a few people who learn how to begin using Access as a database, usually to track or manage a departmental activity. They use it themselves, then learn that with a few changes, it can become a shared database. But then even more people start using it, and it breaks due to poor design. But by now, the department (or company) depends on it. So the department manager goes to the IT department and tells them that he needs this database fixed right away! Predictably, the IT department sees this scenario more than they want to. From their perspective, they must now go into a significant database design effort, with no time planned for and no budget planned for. After a few times of this, it's easy to see why Access gets blamed. So, to get off the hook, the IT department will blame Access, and demand that Access no longer be used for company applications. You really can't blame them. The problem is that Access is too easy to use to create a useful application without the 'developer' having training. Think about VB - you don't just up and make a VB front end app with back end tables without some training! I have one customer which uses my Access app for Corrective Action, Nonconforming Material, Debit Memos, Die Cast Machine Settings, Vacation Requests, Attendance Tracking, Warnings, Controlled Documents, and soon to be Training Management. This is all in one FE, using a separate .mdb for Temp tables, a library database with forms, reports, and standard modules, and a BE data .mdb. It's very effective, and they literally don't have to hire as many people. So yes - Access can be used very effectively for business applications. Interestingly, one of the reasons I started working with them is because they had a Quality Engineer who tried to create a Corrective Action process, but couldn't write any code. (She was gone before I got there.) So, if MS can influence people to not use a high-powered tool with a low-skilled driver, the reputation of Access as a business app will improve. They may already be doing this by providing a large number of usable templates for people to use 'out of the box.' That's my 10 cents (with inflation)! And - Shamil - where is this report published? I'd like to be able to refer prospective customers to it. Dan Waters -----Original Message----- Subject: [AccessD] Moving out of MS Access? Hi All, Is this article from http://blogs.msdn.com/access/default.aspx just a cry of MS Access Team trying to stop the massive(?) exodus of MS Access developers or it shows the real picture and place of MS Access in corporate world and that MS Access isn't yet dead for real business tasks development ? What do you think and what do you see there overseas? <quote url="http://blogs.msdn.com/access/default.aspx"> Market research by Microsoft indicates that fewer than 5 percent of all Access applications developed in large enterprises have requirements that justify moving the data from a Jet database to SQL Server, and fewer than 1 percent require migrating the forms, reports, and code to a .NET-based solution. </quote> Does this mean there is a demand for the new MS Access development or just that there is no usually any need to migrate old MS Access applications to MS SQL/.NET? <quote url="http://blogs.msdn.com/access/default.aspx"> Microsoft Office Access and Enterprise IT Case Study: Streamlining Application Development Peter Mullen is Manager of Application Development in the corporate services department of a Fortune 500 insurance company with almost 50,000 employees and over 500 offices in 120 countries. Following a major acquisition, the company undertook a reorganization that involved centralizing its data management. Mullen, who had some experience working with Microsoft Office Access, started exploring the ways that Access database applications were being deployed across the enterprise. He was stunned to learn how pervasively Access was being used. Mullen says, “Access was all over the place doing so many things that it blew my mind. Once I became known as ‘The Access Guy’ there were people all over the company who wanted my time.” Not surprisingly, the quality of the Access applications Mullen discovered was quite variable. To Mullen’s trained eye, some were in fact very poorly designed, and yet they were getting the job done. Mullen also found positions hidden in the payroll in the field that consisted essentially of supporting a small number of departmental Access applications. Mullen and his manager put together a presentation for the Chief Information Officer (CIO), proposing that the IT department begin formally supporting Access development at the company. They outlined a strategy for centralizing and rationalizing management of the Access applications that were evolving under the radar of their traditional portfolio management. The CIO saw the value in this proposal right away, and Mullen became the lead developer of a new group that was formed for this purpose. Mullen’s group created and nurtured the use of naming standards, coding standards, and standard methodologies. They also were able to reduce headcount in the field as support activities were centralized. Mullen reports that after about two years, “We had standard code; we had about 200 applications, and we were handling it. We started to rationalize our portfolio and really started to communicate exactly what we were doing to IT. This was the key point¾that a lot of people in the organization started to see what we were really about. These were complicated problems being solved without spending a lot of money.” As more people in the IT organization learned of the success of Mullen’s group, he began to receive requests for “bolt-on applications, small department tracking projects, and proofs of concept. We hit a few of these and we had a real perceived value to the organization.” Mullen summarizes what he’s learned about the optimal role of Access in the enterprise as follows: “Access development in corporate organizations is simply a reality. People in the business are constantly looking for ways to add value to their customers and to free up their staff from mundane chores using automation that is inexpensive and easily accomplished. This is the strength of Access. The problem, from an IT perspective, is that the business comes to depend on products created without any IT involvement. Someone—usually an outsider or a low-level employee—becomes vital to the support of the product. So the question for IT becomes, ‘Will we provide support for this process?’ In my experience, providing an organized group that can create and support Access applications is a solid investment. It adds real and perceived value to the business and prevents a whole portfolio of applications from being developed under the radar of IT.” Mullen continues, “IT usually looks at all of the Access applications that are developed in the field as problems to be eliminated. I look at them and I see opportunity. Applications developed in the field are sometimes things that should never have been created; yet often they are products that are highly valued and fill a real need. By treating field applications (which most often means Access) with respect, and providing support and portfolio management, you can sometimes find patterns of demand in your organization and help drive real IT value back to the business.” Mullen is now working with the Architecture Team in his organization to identify candidates for migration to SQL Server and .NET applications. Mullen says, “Much of our portfolio will remain in Access, but some will migrate. There will always be a need for those quick and inexpensive solutions. The important thing is to keep track of these applications. They are the fingertips of your IT organization.” Market research by Microsoft indicates that fewer than 5 percent of all Access applications developed in large enterprises have requirements that justify moving the data from a Jet database to SQL Server, and fewer than 1 percent require migrating the forms, reports, and code to a .NET-based solution. Access developers, administrators, and users now have a new toolkit to aid them in analyzing Access 97 databases for upgrade and conversion to Access 2003. Users can take advantage of the tools in the Access 2003 Conversion Toolkit to find and analyze databases in preparation for switching to Access 2003. For upgrading to the 2007 release, Microsoft plans to release the Microsoft Office Migration Planning Manager. <quote> -- Shamil -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com