IBIS - Nr 322 - Introduction To Gis

Welcome guest Login | My Profile | May 19th 2013


NIISS CitSci.org GISIN MSP COTrails
Home About Us Partners Staff Contact Us Websites Complete List NIISS CitSci.org GISIN MSP COTrails Technology Mapping & Modeling Philosophy Architecture Products GIS/RS Websites GIS/RS Resources IBIS Maps Papers Turtorials	Philosophy Our philosophy is focused around using the most appropriate technology for each task. The idea is that if you need to drive 1000 nails into a roof in a day, you would want to rent an automatic nailer. If you need to drive 10 nails in one day, you would get a good old hammer. Appropriate Technologies We always try to find the most appropriate technology for problem. Sometimes this means purchasing a new, high-performance, computer. Sometimes it means giving users paper forms to fill out. Watching all the costs In the information technology world it is important to remember that there are lots of ways a project can fail. Let's say you are purchasing a new database and you believe it has the features you need. After installing it and setting it up you find out that it does not. You may try to get help in solving the problem, but technical support in the software industry has largely disappeared (unless you pay for expensive technical support contracts). Thus, you use the Internet and a variety of list serves to try and find an answer. Usually you will find a fix or a work-around to take care of the problem. If not, you may have to consider sending the database back or, if the source code is available, implementing a fix yourself. What many new project managers and developers miss is the cost associated with these approaches to finding solutions to inevitable problems. Employees cost about twice what they make per hour, let's round it off to $100 per hour for IT professionals. If one employee spends just two days on a problem (16 hours), then they have spent $1600! This cost can quickly out pace the cost of purchasing a different software package. Avoiding technology religious wars Programmers, like most folks, have their likes and dislikes. This goes especially for the languages and tools they use to develop software. The problem is that over time programmers can begin to become very entrenched in specific languages and tools. They become resistant to change. They will also talk adamantly about companies that they 'hate'. I don't understand how you hate a company. The bottom line is that we don't have time to hate any organization or person; we have systems to build and products to deliver. For each decision we try to consider what the alternatives are and the merits of each alternative. Then we select the best alternative for the job and get on with it. Considering all the possible alternatives and critical factors When making a major decision on the components for a system, we consider every alternative we can think of and make sure we examine all critical factors. The factors always include: Features: Does it have the features we need? Reliability: Will is make our system unstable or make us do excessive work-a rounds to fix problems? Performance: Will it be fast enough for our users? Will it slow down development while we wait for it? Documentation: Is the documentation available, up to date, and easy to use? Is the documentation specific to the operating system we are using? Support: How easy will it be to get support? Does support have a cost? Schedule: How long will it take to obtain, install, and learn to use? Resources: What other resources are required to make it work? Cost: What is the cost? When it comes down to it, all of these items can be put into some type of cost. What we are looking for is the best cost/benefit ratio we can get. We also consider that most of the cost of a component of our system will be spent during maintenance over the years it will be in use, not just during development. This means that ease of maintaining a component is more critical than the cost of purchasing, installing, and integrating it initially. OpenSource, Free, At-Cost, and Custom We use OpenSource software when it has the features, performance, reliability, documentation, and support we need. Since we are a university, we are very cost conscious so the "free" aspect of open source is attractive to us. There are also a few examples of where OpenSource products, like NetBeans, are actually easier to get support for than some commercial products. One advantage of OpenSource products is that we can get the source code, so if we have a problem that cannot be solved any other way, we can edit the code ourselves (we really try to avoid this). We also support and contribute to the OpenSource community. The GISIN toolkit is one example of our OpenSource Development efforts. There are a growing number of 'free' resources available and we take advantage of them when it is appropriate. One example are the map backgrounds that come to us from GoogleMaps. They look great and we are grateful to Google for providing them. At the same time it is important to remember that Google is a business and has made no guarantee that they will be providing these long them. I've been in the computer industry for over 30 years and have seen companies be put in very bad situations when a 'free' resource was suddenly no longer available or was now being charged for (i.e. see the issues with GIF as a file format that caused the creation of the PNG format). Purchasing software used to have more advantages than it does now. We used to be guaranteed a certain level of support when we purchase a software package. This is rarely true nowadays and if support is provided the quality is usually pretty poor. At the same time, searching the Internet for information on solving problems has become much easier and is often faster than contacting the company. This removes one of the major benefits of purchasing software. We do purchase some software, but only when the other aspects of the software outweigh the cost. When needed, we develop our own software. This is only done after we have looked for components that would fill the need from other sources and when we feel we can write and support the software ourselves. Our system contains about 300 custom web pages, a large class library, and a number of web services, all written in PHP. Developing custom software can have advantages as out-of-the-box software often doe snot meet the needs stakeholders have identified.

An IBIS website Updated 5/3/2013