Mr. Lott has been involved in over 70 software development projects in a career that spans 30 years. He has worked in the capacity of internet strategist, software architect, project leader, DBA, programmer. Since 1993 he has been focused on data warehousing and the associated e-business architectures that make the right data available to the right people to support their business decision-making. Steven is a DZone MVB and is not an employee of DZone and has posted 140 posts at DZone. You can read more from them at their website. View Full User Profile
shows what innovation looks like when it happens.
There's no process for innovation.
There's no "permission to fail". Folks just fail or succeed without
anyone's support or permission.
disruptive. Many IT departments don't know how to cope with USB drives,
iPads and related leading-edge technology. So these things are simply
banned. (Ever walked past a sign that says "No Recording Devices
Allowed Beyond This Point" with your iPhone?)
one great quote: "Policies around regulatory compliance, reliability,
budget approvals, and support all give IT teams reasons to resist
technology driven by end users."
innovation is happening. It is disruptive. Therefore, IT tends to
resist the disruption.
The best stall tactic:
"Security". If IT lifts up security as an issue, they can resist
technology innovation effectively.
This happens everywhere.
It isn't just the iPad. All disruptive, innovative change is met with
Agile Methods. Some IT
departments resist agile methods because -- obviously -- the lack of a
comprehensive and detailed project plan is a problem. Failure to plan
is a plan for failure. The idea of building intentional flexibility
into predicting the future is rejected. It's too disruptive to the IT
chain of command to reduce the need for project managers.
or Functional Programming Languages. It was painful to adopt Java (or
C#). Adopting another, different language like Python is insanity.
Obviously. Anyone in "Big IT" who is a serious Java or C# developer can
tell you that a dynamic language is obviously unsuitable for production
use. Mostly, the reasons boil down to "it's different"; different is
N0SQL Data Management.
Clearly, the relational database is the only form of persistence that
can possibly be used. It is perfect in every way. It can be used as a
message queue (because adopting an actual message queue is too much
work). It can be used for temporary or transient data. It can be used
for non-relational objects like XML documents. Any suggestion that we
use something other than a database is often met with derision.
Clearly, a non-SQL database is disruptive to the orderly flow of data.
Architecture. [This is code for "No Stored Procedures".] Since stored
procedures have been used with mixed success, some folks argue that
they should be used more. On the other hand, it seems peculiar to me to
intentionally fork application logic into two places -- application
code and database. It seems to add complexity with no value. Lots of
DBA's try to explain that some logic is "lower-level" or "more closely
associated with the data" or "is a more 'essential' business rule."
There's no dividing line here that makes stored procedures necessary or
Try to prevent the problems
associated with stored procedures and you will receive a $#!+-storm of
abuse. Every time. Reducing the use of stored procedures is a
disruptive change. An innovation. A bad thing.
proof of the non-essential nature of stored procedures? Watch what
happens when to upgrade or replace an application and migrate your data.
Did you need the stored procedures? No, you left those behind. You
only kept the data.]