In 1996 the first mapping component came on the market.That first product, published by Sylvan Ascent was followed in short order by products from Blue Marble Geographics (GeoView and GeoObjects), ESRI (MapObjects), and MapInfo (MapX).In their short time on the market these products have put spatial technology in the toolkit of thousands of developers.
Undoubtedly more can be done to spread the use of these tools.Jeff Cole, founder and President of Blue Marble, submitted the following OpEd to us; we publish it to further the discussion.We welcome the comments and contributions of our readers in general, and of other software publishers in particular.
-------------------------------------------------------
Advantages of Component Software
The advantages of component software are clear, and becoming clearer every day.Developers are concerned to add world-class features to their applications.Rapid development is absolutely essential in today's software marketplace.Components allow you to implement world-class features in your application at a fraction of the cost of "reinventing" the feature.Components should plug into your application in a very simple manner, work "straight out of the box", not "lock you in", and provide compelling value.While you're off working on other aspects of your application you can take comfort in knowing that the component vendor is improving and supporting your feature by improving his product.
We've learned a lot during the last six years of working with thousands of developers throughout the world.We offer the following 'Rules of Thumb' for you to use as you look to integrate components, specifically mapping components, within your application.
Rule #1 - Never bet against Bill Gates!
Don't ever accuse us of steering away from controversy! Bill Gates is the most interesting figure in the technology marketplace today.Bill has been villified by many and praised by a few.Regardless, his company has played and will continue to play a fundamental role within the technology and software development landscape.Microsoft "enabling technologies" (DLL, VBX, OCX, OLE, COM, DCOM, VBA, etc.) have made Microsoft the "classic gorilla" within the Gorilla Game.In establishing an open interface to a proprietary architecture that has been broadly adopted as a "defacto" standard, Microsoft has effectively "locked" developers and customers into their solutions and way of doing business.This pervasive dominance isn't likely to end soon.
Every day, developers make important decisions with respect to possible approaches towards solving fundamental development problems as they present themselves.What standards do you intend to support? What development environment do you intend to develop around? Java and/or COM? It's hard to even comprehend the opportunities that have been lost due soley to the adoption of the "wrong" approach to a problem.Just ask anyone who has ported their application from Borland's OWL framework to Microsoft's MFC architecture.It's impossible to see ahead in time and know with any sort of certainty which technical approaches will "win".It's also very hard to bet against Bill Gates.
Several years ago Bill Gates spoke of "information at your fingertips" where the program would fade into the background on your desktop and the information that you were creating or analyzing would come to the forefront.He spoke of "everyone being a programmer" where users could highly customize software in order to create nearly perfect solutions for their problems.He spoke of Visual Basic for Applications (VBA) as being the "glue".He spoke of component software (monolithic systems would fade away) and systems that could be rapidly developed consisting of distinct components working in a seamless manner, each providing an optimal solution to its role within the overall solution framework.We were listening.
Rule #2 - Buy into simple and complete products!
The evolution of a technology market is based on this premise.Don't buy complicated or incomplete products.
There has been a general tendency towards "feature bloat" within the mapping software market.Oftentimes, customers even pay for custom features to be included within a retail product.If someone wants it and is willing to pay for it, everyone gets it.Product definition loses focus and what may have been simple and clean turns into a hard-to-use, complex beast.
Review the object diagram for the component.Is it a large poster? Does it resemble the wiring schematic for a Boeing 747, or is it clean and simple?
Rule #3 - Refuse to pay per-seat runtime royalties!
What other products do you license this way? How many accountants to you have on your team? Does a GIS vendor really need to become directly hooked into your customer base?
Per-seat runtime royalties are a relic of an immature marketplace.There is a general perception that per-seat royalty-based products are "quality" and per-seat royalty-free products are "cheap".Is this really the case? You need to decide if it is acceptable for you to pay per-seat royalties for every copy of your product that you give away, upgrade at a reduced price, or sell.The per-seat royalty-based business model is a dinosaur, created by vendors who:
- have legacy products that they don't want to see cannibalized by component based applications, or
- don't want to see the component marketplace mature with an empowered customer base that won't be "locked" in to their technology.
"Relationship deals" are also a relic of an immature marketplace.Did your charting or graphing OCX vendor visit your shop and take you out to lunch?
Rule #4 - Refuse to translate your map files!
Most map controls support only a single map format.Even worse, many only support a single proprietary map format.Refuse to be "locked in" to a proprietary map format! A mapping component must support standard formats directly "on-the-fly" with transparent format and coordinate system conversion.
Data translation almost always turns into a project unto itself.There isn't a credible translator vendor in existance that will guarantee perfect conversions.Information is almost always lost and other issues are almost always uncovered.
Remove unnecessary complexity from your projects (and your life) in any way possible.
Rule #5 - Don't lock yourself into a single GIS component vendor!
Demand support for open standards.Don't develop your application using proprietary interfaces.One of the most compelling reasons behind using components within your application is that you have the freedom to pick the best component for the application.You are empowered, fire up your search engine! Wouldn't it be great if a single mapping component supported the ESRI, AutoDesk, and MapInfo formats directly without conversion.
Rule #6 - Paying for vendor consulting services or training as a default choice is unacceptable!
Again, this is a relic of an immature marketplace.Many "GIS" customers have become conditioned to accept training as a requirement in order to effectively use leading desktop mapping and GIS packages.You shouldn't need training or consulting services to use a vendor's mapping component product.Spatially enabling your application is not as complex as you may have been led to believe.
Consider outsourcing your development if you are breaking completely new ground, if development isn't part of your focus, or if you can save money by farming out the development; not as the "default" choice because that's what a vendor recommends.
Does the component vendor publish a training schedule that looks like a major college cirriculum? Why?
Rule #7 - "Always make things as simple as possible, but not simpler." - Albert Einstein
The mapping component marketplace is maturing rapidly as customer expectations drive the market.We don't mean to trivialize the issues you face as you decide which mapping component to use within your applications.But, don't accept complexity, and keep things simple.
Pretend you are buying a charting or graphing control.As the market matures you want to be in the drivers seat, not the back seat.