Yes: It Is Inevitable

Fight it all you want, but employees are going to be bringing their own smartphones, tablets and other technology to work with them. So it's time to stop resisting and start preparing.

Most of the organizations I worked with or for over the past 40 years had strict rules about technology. They kept tight control over what hardware and software workers could use, believing it would be easier to secure and manage that way. Some even went so far as to lock down their technologies, meaning employees couldn't do things like change user preferences.

Such an approach seemed to make sense, considering the challenges related to fighting viruses and malware, as well as the need to secure business data and make sure company computers weren't used inappropriately.

But talk to corporate IT people, and they'll tell you maintaining such tight control these days has become a real pain.

Continued at Wall Street

Gunpowder, one of mankind's most disruptive innovations, made its European debut in the early part of the 14th century. Up until then, security specialists had a simple and effective strategy -- build taller, thicker walls to keep out enemies. An entire economic ecosystem had grown up around this strategy, which was what worked. Visibly. Everywhere. If you could afford it.

Gunpowder changed all that. But it wasn't until the middle of the 20th century that the military strategies of nation states really evolved past the taller, thicker walls approach. That's in part because gunpowder wasn't initially very good and the munitions it made possible weren't very effective. Sure it had the potential to be a problem, but, hey, not in my lifetime -- and, oh, by the way -- I have this really neat idea for a stronger castle I want to build for you. It didn't help that a good alternative to taller, thicker walls wasn't available. Rule number one for strategic advisors: don't show up with a problem you can't solve.

Continued at Harvard Business Review

Fixing large-scale critical infrastructure in place is one of the hardest engineering and operational management tasks we can face. Yet the better we build our infrastructure, the more we become dependent on it and the more disruptive any attempt at major change will be. We all live this with highways and bridges. Where I live we have two seasons: winter and road construction. Winter is shrinking; road season isn't.

Also where I live, large parts of the local commuter rail system need to be upgraded in place. Not the tracks or signaling or rolling stock -- they handle those upgrades all the time. But bridges, viaducts, and some stations are 100 years old and at the end, or beyond, of their design lives. It's going to take eight years to replace all this -- eight years during which the trains still have to run, if only to generate the revenue to pay for the upgrades. So (or so I'm told) a bunch of "smart young folks with their computers" sat down and recalculated the train schedules so that in some parts of the system half of the right of way can be taken out of service for extended periods. In their "smart scheduling" (they really called it that) solution, no train time changed by more than five minutes -- most by less than three -- although lots of station stops got skipped at peak times. To compensate trains got longer or shorter, requiring passengers to learn new on and off boarding strategies, because the stations didn't get longer to match the trains.

Continued at Harvard Business Review

I first got involved in the offshore business in 1979 via a software engineering and testing partnership that brought together U.S., U.K. and French teams to support a project in the Middle East. This global talent pool was a critical factor in delivering the project successfully on time and on budget. Since then, I have been involved in global sourcing initiatives in India, the Philippines, Canada, Mexico, the Caribbean, Poland, Spain and China.

Along the way, I've learned things that we don't always see in the conventional literature on outsourcing or offshoring. Here's a checklist for CIOs to consider before leaping into "world sourcing."

Continued at CIO Insight

]]> tag:www.parkwoodadvisors.biz,2010://1.52 2010-03-02T15:48:49Z 2011-03-14T19:45:22Z

Business intelligence tools have matured, but have IT's internal capabilities? A look at the real challenge CIOs face in executing their BI strategy. Businesses have been accumulating data in digital form from business operations for more than 40 years now....

Marianne Wood Business intelligence tools have matured, but have IT's internal capabilities? A look at the real challenge CIOs face in executing their BI strategy.

Businesses have been accumulating data in digital form from business operations for more than 40 years now. In parallel with this accumulation, tools for organizing, categorizing and analyzing this data--turning it into the kind of context-rich information that can drive decision making--have been growing in capability and sophistication.

If you believe the vendor stories today, we can "empower" everyone in the business with the information tools they need to make better, faster operational and strategic decisions and thus please both customers--because we know who they are as individuals and can anticipate what they want and need--and stakeholders--because happy customers make for a profitable business. There are even credible "proof points" to back up the claims, such as case studies of businesses that do this really well.

Information-driven businesses do exist. They do work. And some of them even do better than the rest of the market they compete in. Shouldn't we all make use of the mountains of data in our warehouses and match the performance of these pioneers? Isn't it time for "Enterprise BI"?

If only it were that easy.

Continued at CIO Insight

]]> tag:www.parkwoodadvisors.biz,2010://1.55 2010-02-19T16:09:56Z 2011-03-14T19:47:20Z

John seldom goes to major vendor events any more. They've gotten so big that you can't actually get anything useful done and he already owns too many of the various give away items that abound at 'partner" booths at these...

Marianne Wood

John seldom goes to major vendor events any more. They've gotten so big that you can't actually get anything useful done and he already owns too many of the various give away items that abound at 'partner" booths at these things.

They always seem to be in inconvenient locations (at least if you live in the Northern Midwest they're inconvenient) and I hate the travel. Every now and again, however, something comes to Chicago that looks like it could be interesting or useful, and I sign up.

Inevitably I regret it. Yesterday was no exception.

Continued at CIO Insight

]]> tag:www.parkwoodadvisors.biz,2010://1.54 2010-02-17T16:06:11Z 2011-03-14T19:50:32Z

It's become almost a religious belief that to get 'real" innovation you need a broad community of people sharing ideas and helping to improve whatever is being dreamt up. Free from stifling corporate constraints and management process overheads, "open innovation"...

Marianne Wood

It's become almost a religious belief that to get 'real" innovation you need a broad community of people sharing ideas and helping to improve whatever is being dreamt up. Free from stifling corporate constraints and management process overheads, "open innovation" can go fast and take unexpected directions.

That's what entrepreneurs do, isn't it? Many eyes help keep you from blind alleys. Peer review keeps you honest. Buzz gets you market, or at least mind, share.

And then there's Apple.

Continued at CIO Insight

]]> tag:www.parkwoodadvisors.biz,2010://1.53 2010-02-16T16:01:46Z 2011-03-14T19:51:40Z

If you're like John, you spend a decent amount of time worrying about whether your disaster recovery processes and plans would really work. Sure, you actually do have plans. Sure, you practice parts of them periodically. But a full "like-it-was-for-real"...

Marianne Wood

If you're like John, you spend a decent amount of time worrying about whether your disaster recovery processes and plans would really work.

Sure, you actually do have plans. Sure, you practice parts of them periodically. But a full "like-it-was-for-real" DR test isn't usually feasible unless you run active/active with rapid reconfiguration/failover capabilities, and most people don't do that.

When you look at the people who do (I know a few) you realize why most organizations don't even try: It's a LOT of work.

Continued at CIO Insight

]]> tag:www.parkwoodadvisors.biz,2010://1.51 2010-02-11T21:52:05Z 2011-03-14T19:52:55Z

Several times over the past year John has been asked by senior executive colleagues to recommend reading material that would give them a working background on and understanding of enterprise IT. Something along the lines of the "XX for Dummies"...

Marianne Wood Several times over the past year John has been asked by senior executive colleagues to recommend reading material that would give them a working background on and understanding of enterprise IT. Something along the lines of the "XX for Dummies" series.

I was surprised to find that this didn't really exist.

I probably scanned thirty or forty possible sources (thank you, Google and Amazon) but most of what I found wasn't really suitable--not focused on the enterprise, too "2.0" or even "3.0"-oriented, too technical, insufficiently accessible, just plain wrong and so on. I did eventually find something that was almost what my colleagues needed, but even that wasn't quite right.

This is puzzling.

Continued at CIO Insight

]]> tag:www.parkwoodadvisors.biz,2010://1.50 2010-02-05T21:48:14Z 2011-03-14T19:54:15Z

John hasn't worried about reliable power for quite some time. But last week he started to, if not worry, at least think about how to cope with the levels of power density we are starting to see in the data...

Marianne Wood

A fully populated rack--four full blade chassis, for example, running virtualized environments at around 80 percent utilization (which is what we are achieving these days)--consumes 24kVA of power continuously. That's more than the average family home concentrated into 10 square feet.

At an efficiency ratio of about 1.4 (it takes 1.4 units of power to cool 1 unit of power), that means that each rack represents nearly 60kVA of committed power. And with compute, storage and connectivity to take into account, we have a lot of racks.

Data center designs tend to keep the racks close together. So we save on real estate as well as fiber and copper connection costs, but that just makes the power and cooling capacity problem worse. Most data centers can safely deliver only 200 watts per square foot with the current generation of power-distribution infrastructure, yet we need north of 240, with some headroom above that to handle occasional utilization spikes.

Something has to give.

Continued at CIO Insight

]]> tag:www.parkwoodadvisors.biz,2010://1.49 2010-01-20T23:42:25Z 2011-03-14T19:55:29Z

Around the middle of last year, my then-boss asked me what I thought was the most critical strategic decision we had taken in the preceding 18 months. It wasn't a trick question--he was going to be asked the same thing...

John Parkinson Around the middle of last year, my then-boss asked me what I thought was the most critical strategic decision we had taken in the preceding 18 months.

It wasn't a trick question--he was going to be asked the same thing at an investment conference and wanted some thought on the logic behind the answer.

What we settled on was the decision to aggressively go after virtualizing our technology infrastructure, starting with the computing capacity and proceeding rapidly to storage and networking.

Of course, when you work in the mainframe world, virtualization of the computing environment is old hat. Even in high-end UNIX servers, logical partitioning of the resources and oversubscription of resource allocation is a couple of decades old (which is ironical if you remember what triggered the development of UNIX in the first place).

But applying the principles of virtualization to everything in the data center is a big step beyond just choosing approaches to abstracting hardware. It's a commitment to a new way of thinking about managing infrastructure.

Which is what makes it hard.

Continued at CIO Insight

]]>