Jimmy Dean should never have recorded “Big Bad John.” His squeaky tenor just doesn’t fit the lyrics — they demand a Johnny Cash baritone.
Still, Dean got some things right — his sausages, for example.
And, he gave us a useful quote: “I can’t change the direction of the wind, but I can adjust my sails to always reach my destination.” It will never make it on despair.com, but that’s okay. Cynicism is more fun, but figuring out how to make things work is what pays the bills.
My last two columns have talked about the direction of the wind (“An imperfect storm,” 2/24/2014 and “More storm warnings,” 3/4/2014) — trends you can’t do much to affect, and do have to respond to:
- Cloud 3.0 — enterprise-class computing that includes cloud-based applications.
- Shadow IT — the growing amount of information technology implemented without IT’s involvement.
- The digital enterprise — a grab-bag; right now its most important elements are smart products, the so-called “internet of things,” and all of the opportunities possible when you put the two together.
- Income disparity — and the rising demand for luxuries and uniqueness by those on the lucky end of this trend.
- The rise of business practices over processes — practices being the way to organize how work gets done so as to be able to deliver uniqueness.
Your challenge: Adjusting your sails so IT can at least survive these trends and maybe even enjoy the outcome. Suggestions:
Get the relationship right. I know you’re tired of hearing me rant and rave about moving beyond the supplier/internal-customer relationship model to a fully collaborative alternative. I also know I talk to IT leaders all the time who haven’t made the transition.
It matters in this context because in your brave new world of embracing shadow IT, a collaborative relationship is what will stop shadow IT from become rogue IT.
Automated regression testing. Take this to the limit, and beyond.
Cloud 3.0 means multi-cloud plus inside-the-firewall infrastructure provisioning. Multi-cloud, and especially multiple cloud solutions managed directly by the lines of business, means patch management and version management move outside IT’s control.
With automated regression testing you might be able to persuade the lines of business that IT should test cloud-vendor-induced configuration changes before they’re put into production. Without it, IT will once more be positioning itself as a bottleneck rather than an enabler.
Redefine the “I” in “IT.”
Except for shadow IT, all of these trends mean more work for IT, not less. Even cloud computing doesn’t mean IT has less work to do. You’ll be managing multi-cloud systems. Think monitoring for availability and performance. Think more reliance on your WAN. Think about what restoring from backup now means. Especially, think about integration.
This is the redefinition of “I” — from “information,” which never truly encompassed IT’s responsibilities anyway, to “integration,” which completely describes where IT is essential.
Look, like it or not, sales managers everywhere understood the difference between cloud-based shadow IT and the installed alternative. Installed software meant asking IT to unlock sales reps’ laptops so they could install Act! and asking IT to provide a server so their laptops could synchronize to a shared database.
The Cloud meant buying licenses from Salesforce, doing everything through the browser, and getting the shared database too, all with no IT involvement.
So encourage Shadow IT. Get rid of as much responsibility for the applications portfolio as you can. For individual applications, shadow IT’s drawbacks are diminishing, and this also eliminates the “This application doesn’t do what I need” vs “The specs were wrong” arguments that now dominate many business/IT relationships.
But integrating the applications? Only IT … “Integration Technology” … can make this happen.
Which gets us to enterprise technical architecture management (ETAM). This is a long-running personal favorite, and it’s only going to be more important in the future.
A multi-cloud environment with lots of quasi-independent line-of-business and departmental IT departments adding to the application layer is akin to a bunch of developers adding buildings to a community without building codes or well-designed water purification, electricity-delivery and sewage treatment systems to connect to.
In particular, the ETAM function should choose the company’s integration technology system and define the company’s data integration engineering requirements.
Data integration is what causes the most trouble when it comes to accidental architecture. Without a clean, clear, well-engineered approach, shadow IT will exacerbate the situation exponentially.
Okay, okay. “Polynomially” is more accurate, but who’s counting?
* * *
15 years ago in KJR’s predecessor, InfoWorld’s “IS Survival Guide”: An app dev methodology that looks a lot like Agile, two years before the Agile Manifesto.
Way back in 1996, I recommended viewing yourself as a product, not an employee.
And ten years ago, how to avoid the proximity trap — the tendency to pay more attention to those who have access than to those who have answers.
Agree on redefine the “I” for “Integration” in IT. To extend the thought, “Integration” has always been part of the “Information” itself but growing more important as the world producing more data in many more possible domains & devices.
Giving more room to shadow IT is good for business enablement so we could move faster. The other less obvious but very important challenge is to keep a reasonable service level & security within the highly integrated clouds which would still require strong governance.
My heaven’s a good set of specs? What a concept. Course the team responsible for this consults the business unit but they must remember they are the “experts”. And they can’t ask a question like “is a 30 second response time okay?” Because the Users, who don’t know any better will say “Why, yes it is.” Blaming the Users because it is a “User Defined Specification” is disingenuous.
My word where are the competent IT folks when you need them.
For me, when you said”
“In case the point isn’t clear: They’d better be and if they aren’t it’s time to replace them, and to fix the hiring process so such irresponsible people aren’t put in positions of responsibility any more.”
you described the crux of the matter and what has to be any HR’s biggest challenge. But, what is a solid definition of irresponsible in a position of power or authority? Some people are fine and productive when working own their own, but their actions become dysfunctional in the situations you describe in your piece.
If I ran HR for a company, each applicant would have to score high on:
1. Their ability to listen accurately what others are saying to them.
2. Their ability, style, timeliness, and readiness to admit publicly to their colleagues that they were wrong.
3. Their ability to know when they are wrong, rather that just disagreeing about something.
I would develop standard protocols for evaluating these capabilities of all new hires, and no hire anyone who didn’t score high in all 3 areas. That way, the hiring process would be fair, but less subject to personal charm or connection. That would be my way of keeping new dysfunction from arriving with new hires. That’s my 2 cents.