As those of you my age and older may recall, as recently as 20 or 25 years ago you pretty much had to know a great deal about how your computer worked in order to use it effectively (unless you had an Apple Mac). Today, with the dominance of "easy" point-and-click graphical user interfaces (GUI), good luck troubleshooting that error message without programming skills.
Yet in the business intelligence world, you see a lot of animosity toward do-it-yourself coding. After all, technology evangelists proclaim, you can pick from among all sorts of really cool point-and-click interfaces that make BI so easy! Why, the software practically does the work for you!
Does it really? What happens if something goes wrong? What happens if you don't understand something? What happens if, for some reason, you need to manually look at or edit something?
This is not even to mention the extensive (and expensive) training issues that surround implementation of any new software package.
It's good that technology is helping to make our lives easier (so I am told), but just as many BI specialists prefer to code manually, there's a very good reason why, say, most coding and programming in other realms isn't generally done with point-and-click. Somebody needs to understand just what the heck is going on behind all those fancy GUIs and pretty pictures.
An over-reliance on point-and click means an under-reliance on the fundamentals. Indeed, as at least one anticoding blogger concedes, even enterprises that use powerful extract, transform, load (ETL) tools often misuse them because they don't understand the fundamental concepts underlying data integration. True, good coders do not necessarily make good data system architects, but you cannot create a good data system architecture without a good basis in coding (just as you would hope that the architect of your new house understands how to make good wood joints, even if he's not going to do the sawing or hammering himself).
Worse, because the tools can be frustrating to use sometimes for seasoned developers, some admit to backdoor coding (sometimes undocumented). (See: To Code or Point & Click: The BI Dilemma.) Combined with the superfluous lines of code that point-and-click solutions tend to spew out haphazardly, this kind of work environment can lead to poorly integrated infrastructures and platforms. As Google employee Steve Yegge wrote in an infamous, accidentally public Google+ rant, "The golden rule of platforms is that you eat your own dogfood."
Over time, this sort of scenario can lead to a disastrous BI environment -- and, worse yet, even more reliance upon the tool that helped start the problems.
Powerful data integration point-and-click tools can be great as a supplement to your BI architecture, allowing your data and data-based decisions to be more accessible to your non-technical business users. But those tools should be just that -- a supplement.
Rather than design your data architecture around a single point-and-click software suite that may or may not be your best solution, invest in building a coding-based data architecture (well-documented, of course) from scratch. Then, and only then, look for an "easy" software solution that will fit your architecture -- as opposed to trying to do it the other way around. After all, no business solution is one size fits all. This will allow you greater adaptability (not to mention return on investment) for the long term without becoming too deeply entrenched in "what the machine tells you."
Accessibility is great. "Easy" is great. When it comes to your data infrastructure, however, ease and accessibility are not dogma -- understanding is.