In this case large, dark plums.
And why does fruit no start to rot from the inside out?
particularly pears
Thursday, December 11, 2008
Saturday, November 22, 2008
Election Loophole Allows Non Citizens to Vote
And in Chicago this is news how? The dead have traditionally voted. I suspect both Mayor Daleys still vote. The current one and his father.
I would be interested in seeeing a definition of excessive recycling
WORLD WIDE WORDS ISSUE 611 Saturday 1 November 2008
2. Turns of Phrase: Carborexia
------------------------------
To exhibit "carborexia" is to have an extreme "dark green" attitude to environmental issues. This can show itself in several ways, such as excessive recycling, but in particular it refers to an obsessive desire to reduce one's personal carbon footprint. The term first appeared in an article in the NYTimes on Oct17. The adjective is "carborexic".
richard the (apparently) dark green pup
Kennesaw GA
2. Turns of Phrase: Carborexia
------------------------------
To exhibit "carborexia" is to have an extreme "dark green" attitude to environmental issues. This can show itself in several ways, such as excessive recycling, but in particular it refers to an obsessive desire to reduce one's personal carbon footprint. The term first appeared in an article in the NYTimes on Oct17. The adjective is "carborexic".
richard the (apparently) dark green pup
Kennesaw GA
Friday, July 18, 2008
and I thought that smell was from the beans at lunch
All substances are either growing or decaying at any one point in time. Human beings are no exception. If we are not growing, then we are decaying. - Thomas D. Willhite _Quotes_
[typical oversimplification - complex organisms have parts that are doing both - we are all in some sense "dying"]
[typical oversimplification - complex organisms have parts that are doing both - we are all in some sense "dying"]
Thursday, July 17, 2008
Dear Al Gore:
[context]
Who is your science advisor? Whoever they are, if anyone is, I hope you are not paying them. They are not worth it. But with your wealth that may not be an issue.
By the numbers.
1) Wind - a good thing. I was on the coast of OR last week and the wind was constant. Wind is good for OR. Except the noise pollution. Low frequency. Penetrating. Carries a long way. One reason wind farms are in out of the way places. Like offshore. And in deserts.
Then there is the visual pollution. I personally find them beautiful. Not everyone does. People sue their neighbors when they install a wind turbine.
2) Sun - a good thing. Active (photovoltaic) or passive (various) solar is a good thing -- if you have sun. Many places have lots of clouds lots of the time. Pittsburgh in the winter.
btw do you know how much pollution is made making photovoltaic devices?
3) Water - a good thing. Not evenly distributed either in space or time. Heaven knows GA is way too dry right now. And the ecologists would like to tear down dams to return rivers to their natural state. Al -- you're from TN. Can you spell snail darter? Little rascal shut down the Tellico dam.
So what we need is a reliable base line plant that just keeps on producing when the wind don't blow and the sun don't shine and its way too dry.
4) Nuclear - a good thing. If you remember to build plants with engineering and not emotion. How do you get the most expensive, least safe plant? Build them like the US has -- unique plans for each plant. For once the French are very smart. Get a set plans. Build every plant according to the same plans. Each one is cheaper than the last one. Ask Henry Ford about it.
5) Coal - a good thing if you have enough water to cleanup the air pollution they produce. And if you make sure you plant trees to offset the CO2. Lots of trees. Not grass - trees.
6) Trees - yes trees - we can now make ethanol from cellulose! Nuff said. And see numbers 5 and 7 for bonus.
7) Conservation - a kilowatt saved is a kilowatt earned. See Ben Franklin. Plant trees to shade houses. Shutters to cool houses. Insulation. Sweaters in winter and shorts in summer. Fans in summer. Better house design. Brick on inside not outside. Don't cool/heat rooms not used. Cars that don't suck gas. Mine gets 25-30 m/g-- double previous van.
8) Oil - a bad thing. Not enough. Save it for energy needs that can't use the above. If you think $4/gallon is too high wait a year. But be sitting down. This is the beginning of the end.
9) Gas - a bad thing for boiler fuel. We need it for chemical feedstock. Think plastics.
Fine whine list.
Who is your science advisor? Whoever they are, if anyone is, I hope you are not paying them. They are not worth it. But with your wealth that may not be an issue.
By the numbers.
1) Wind - a good thing. I was on the coast of OR last week and the wind was constant. Wind is good for OR. Except the noise pollution. Low frequency. Penetrating. Carries a long way. One reason wind farms are in out of the way places. Like offshore. And in deserts.
Then there is the visual pollution. I personally find them beautiful. Not everyone does. People sue their neighbors when they install a wind turbine.
2) Sun - a good thing. Active (photovoltaic) or passive (various) solar is a good thing -- if you have sun. Many places have lots of clouds lots of the time. Pittsburgh in the winter.
btw do you know how much pollution is made making photovoltaic devices?
3) Water - a good thing. Not evenly distributed either in space or time. Heaven knows GA is way too dry right now. And the ecologists would like to tear down dams to return rivers to their natural state. Al -- you're from TN. Can you spell snail darter? Little rascal shut down the Tellico dam.
So what we need is a reliable base line plant that just keeps on producing when the wind don't blow and the sun don't shine and its way too dry.
4) Nuclear - a good thing. If you remember to build plants with engineering and not emotion. How do you get the most expensive, least safe plant? Build them like the US has -- unique plans for each plant. For once the French are very smart. Get a set plans. Build every plant according to the same plans. Each one is cheaper than the last one. Ask Henry Ford about it.
5) Coal - a good thing if you have enough water to cleanup the air pollution they produce. And if you make sure you plant trees to offset the CO2. Lots of trees. Not grass - trees.
6) Trees - yes trees - we can now make ethanol from cellulose! Nuff said. And see numbers 5 and 7 for bonus.
7) Conservation - a kilowatt saved is a kilowatt earned. See Ben Franklin. Plant trees to shade houses. Shutters to cool houses. Insulation. Sweaters in winter and shorts in summer. Fans in summer. Better house design. Brick on inside not outside. Don't cool/heat rooms not used. Cars that don't suck gas. Mine gets 25-30 m/g-- double previous van.
8) Oil - a bad thing. Not enough. Save it for energy needs that can't use the above. If you think $4/gallon is too high wait a year. But be sitting down. This is the beginning of the end.
9) Gas - a bad thing for boiler fuel. We need it for chemical feedstock. Think plastics.
Fine whine list.
Wednesday, June 25, 2008
pov
Any sufficiently advanced technology is indistinguishable from ...
- ... magic. - Arthur C. Clarke
- ... a rigged demo. - button q.John McKown ASSEMBLER-LIST@LISTSERV.UGA.EDU
Friday, April 18, 2008
Tuesday, April 8, 2008
KJR themes in the news
4/7/2008
Favorite themes from Keep the Joint Running in the news:
Zero Tolerance Policies: The use of process is the difference between effective management and bureaucracy. Effective managers keep the goal paramount. Processes guide action, help the organization learn, and are ignored whenever they don't fit the situation.
For bureaucrats, the process is the point. Following the steps is all that matters, never mind the outcome.
In another example of zero tolerance being a synonym for bureaucracy, we have a six-year-old boy who swatted a schoolmate on the bottom.
The principal, citing the school's zero tolerance policy for sexual touching, called the police. They, unlike the principal, showed good sense and dropped the matter. Sadly they did not show more good sense by arresting the principle on general principles.
Internal customers also made the news. Well, not exactly. Misuse of the word "customer" is what made the news.
Customers are properly defined as the people who make buying decisions. Many business consultants define it, incorrectly, as those whose inboxes receive the contents of your outbox.
That use of "customer" is an analogy, and as the Economist points out, "Being an analogy ... is not the same thing as being the same thing."
This particular analogy caused serious flight delays over the past couple of weeks. A story brought to my attention by sharp-eyed subscriber J. MacKenzie (Airline Safety Alarms Unheeded Washington Post 2008Apr4), reports that FAA inspectors were told the airlines are ... yes, that's right ... their customers.
More than told. When they tried to enforce the safety rules their supervisors sided with the carriers, threatening the inspectors (according to testimony before the House Transportation Committee).
The good news is, the FAA's top safety inspector isn't giving the usual "few bad apples" speech. He's acknowledging a systemic problem. That's an excellent first step in accomplishing a useful result.
The FAA episode reinforces the importance of industry regulation -- a concept that has become unfashionable over the past few decades.
Industry regulation is needed when the results of pure, unfettered competition are not in the public interest. It fell out of fashion because its downsides -- added expense, extra steps, lots and lots of paperwork, and entanglement in government bureaucracies --received excessive emphasis, while propagandists explained away its obvious successes (one example: The Cuyahoga River is no longer flammable).
Speaking of deregulation mania having resulted in even more inconvenience than the regulations themselves, the tipping-domino-like state of the world economy is also in the news. In one of the most insightful articles yet written on the subject (Chaos on Wall Street Fortune 2008Mar31), Allan Sloan dissects both the situation and what we can and should do about it.
Most past downturns were caused by a weak economy dragging down the markets. This one is different: Weak markets are dragging down the economy. The last time this happened? 1929.
As Sloan convincingly demonstrates, you can't create a mess like this with just one mistake. It took several. One was, clearly, a too-weak regulatory environment.
Following the Great Depression came minimum capital ratio regulations for banks -- basically, how much cash they must have to cover their risks. And only banks, even though brokerages and other financial institutions are now allowed to act in bank-like ways.
The result: The bank-like entities don't even know their risks. Many of their "assets" are portfolios of portfolios of portfolios of loans, packaged as investment vehicles.
It's the financial equivalent of spaghetti code. It works until it stops working, and once it does it's very hard to repair.
What possible relevance does all of this have for a working CIO with a job to do? Quite a lot, as it happens.
Also as with business deregulation, once a good thing starts to be too much of a good thing, it can become a bad thing.
Balance matters.
Favorite themes from Keep the Joint Running in the news:
Zero Tolerance Policies: The use of process is the difference between effective management and bureaucracy. Effective managers keep the goal paramount. Processes guide action, help the organization learn, and are ignored whenever they don't fit the situation.
For bureaucrats, the process is the point. Following the steps is all that matters, never mind the outcome.
In another example of zero tolerance being a synonym for bureaucracy, we have a six-year-old boy who swatted a schoolmate on the bottom.
The principal, citing the school's zero tolerance policy for sexual touching, called the police. They, unlike the principal, showed good sense and dropped the matter. Sadly they did not show more good sense by arresting the principle on general principles.
Internal customers also made the news. Well, not exactly. Misuse of the word "customer" is what made the news.
Customers are properly defined as the people who make buying decisions. Many business consultants define it, incorrectly, as those whose inboxes receive the contents of your outbox.
That use of "customer" is an analogy, and as the Economist points out, "Being an analogy ... is not the same thing as being the same thing."
This particular analogy caused serious flight delays over the past couple of weeks. A story brought to my attention by sharp-eyed subscriber J. MacKenzie (Airline Safety Alarms Unheeded Washington Post 2008Apr4), reports that FAA inspectors were told the airlines are ... yes, that's right ... their customers.
More than told. When they tried to enforce the safety rules their supervisors sided with the carriers, threatening the inspectors (according to testimony before the House Transportation Committee).
The good news is, the FAA's top safety inspector isn't giving the usual "few bad apples" speech. He's acknowledging a systemic problem. That's an excellent first step in accomplishing a useful result.
The FAA episode reinforces the importance of industry regulation -- a concept that has become unfashionable over the past few decades.
Industry regulation is needed when the results of pure, unfettered competition are not in the public interest. It fell out of fashion because its downsides -- added expense, extra steps, lots and lots of paperwork, and entanglement in government bureaucracies --received excessive emphasis, while propagandists explained away its obvious successes (one example: The Cuyahoga River is no longer flammable).
Speaking of deregulation mania having resulted in even more inconvenience than the regulations themselves, the tipping-domino-like state of the world economy is also in the news. In one of the most insightful articles yet written on the subject (Chaos on Wall Street Fortune 2008Mar31), Allan Sloan dissects both the situation and what we can and should do about it.
Most past downturns were caused by a weak economy dragging down the markets. This one is different: Weak markets are dragging down the economy. The last time this happened? 1929.
As Sloan convincingly demonstrates, you can't create a mess like this with just one mistake. It took several. One was, clearly, a too-weak regulatory environment.
Following the Great Depression came minimum capital ratio regulations for banks -- basically, how much cash they must have to cover their risks. And only banks, even though brokerages and other financial institutions are now allowed to act in bank-like ways.
The result: The bank-like entities don't even know their risks. Many of their "assets" are portfolios of portfolios of portfolios of loans, packaged as investment vehicles.
It's the financial equivalent of spaghetti code. It works until it stops working, and once it does it's very hard to repair.
What possible relevance does all of this have for a working CIO with a job to do? Quite a lot, as it happens.
- The importance of eschewing (gesundheit!) zero-tolerance policies is, I hope, clear. Policy is a poor substitute for clear principles and good judgment, and should be reserved for situations where everyone must be treated exactly the same, always, rather than being treated fairly and well.
- Treating those who use IT's services with respect, without pretending they're customers, is a key to the ongoing success of most 21st century CIOs. Those who work together in a business should collaborate as peers, not serve each other as suppliers and customers.
- Recent KJRs have emphasized the desirability of deregulating PCs. As with business deregulation, PC deregulation has a number of benefits.
Also as with business deregulation, once a good thing starts to be too much of a good thing, it can become a bad thing.
Balance matters.
-----------------
Copyright and other stuff -- The great KJR link point
Sunday, April 6, 2008
I belong to a prayer group
Over the 8 weeks it has met, the number attending has dwindled by 1/2 for various reasons. I said tonight that we should call everyone who has ever attended or expressed interest to attend, and invite them next. Consensus was that we tried a couple of times and that is enough.
Well it isn't. The "new evangelization" is not a half-hearted try.
And while I'm on my high horse, having the group meet in upscale restaurants in the vicinity of the church is neither a good group maintenance practice nor even Christian. When Christ fed the people he neither charged nor met where people could not afford to meet.
Well it isn't. The "new evangelization" is not a half-hearted try.
And while I'm on my high horse, having the group meet in upscale restaurants in the vicinity of the church is neither a good group maintenance practice nor even Christian. When Christ fed the people he neither charged nor met where people could not afford to meet.
Sunday, March 30, 2008
Wednesday, March 19, 2008
To lock or not to lock - it's a deeper question than you thought
3/17/2008
I had a plan.
Last week's column listed three factors to take into account in deciding how far you should open up or lock down desktop PCs: The company's size, how heavily it is regulated, and the role of the individual employee. Bigger, more heavily regulated companies tend to need more tightly controlled PCs. The same is true of employee roles that are more regimented and less flexible.
I'd planned to continue this week with three more factors. One was going to be company strategy. Specifically, companies that sell strongly commoditized products -- products whose only differentiation is price -- have to focus heavily on cost control, meaning lockdown makes sense.
So much for planning: On reflection, I don't buy it.
I don't care if your company manufactures cinder blocks, or buys and sells lentils. It doesn't matter if the product itself is a commodity. Any company that wants to enjoy continued success needs to be on a constant lookout for new and better ways of getting things done.
There are two ways to go about finding these improvements. One is top-down planning. The other is bottom-up initiative. Since the business case for opening up PCs is built on the importance of bottom-up initiative, this is a subject we need to explore in depth.
Top-down planning has the advantage over bottom-up initiative when it comes to engineering elegance. Since the only way to optimize the whole is to sub-optimize the parts, business leaders should engineer the corporation from the top down, according to a carefully rendered program of progressive decomposition -- from core process to sub-processes to sub-sub-processes to activities to tasks to procedures, all carefully orchestrated and controlled.
It's the organization as machine. The gears mesh, the shafts turn, the subassemblies integrate, and everything hums. IT locks down the desktops because any variation from the grand design can only optimize a part at the expense of the whole.
Now imagine you're an employee who performs actual, for example, work. You know how the work gets done because you do it every day. You see an opportunity -- a way to do it better.
Which is too bad, because better people than you have already designed the whole company. There's no room for bottom-up initiative. How could there be? Change anywhere could unbalance the whole machine.
Sure sounds convincing, doesn't it? Well, no, it doesn't. Company processes aren't as carefully engineered as all that. They aren't perfectly optimized from a global, top-down perspective.
The situation is messier than that.
In a typical company, core processes ... the processes that form the heart of the business ... are well-engineered and well supported by the company's enterprise systems. It's hard to escape this conclusion because by definition, a company's core processes are what give it a competitive advantage. That being the case, they will have received the most attention, brainpower, and investment.
Move away from the core processes and you typically find solutions that are more ad hoc in nature. That makes sense. Company leaders should invest more time and attention in competitive differentiators than in business responsibilities that support business responsibilities that support business responsibilities that support competitive differentiators.
So we'd expect to find more opportunities for bottom-up innovation in non-core areas of responsibility than in core processes. This logic dictates a policy that locks down most rigidly the PCs of employees who play primary roles in core and near-core business functions and processes. The PCs of employees whose responsibilities are farther away from the core would be more open.
This makes for a neat, tidy little business paradigm, not too different from Geoffrey Moore's "Keep the core and outsource the rest."
Don't trust tidy little business paradigms. Too often they are on the wrong side of the line that separates the simple from the simplistic.
Here's one of the nasty little conundrums (conundra?) that get in the way. Imagine your company's core and supporting processes really are carefully engineered and perfectly balanced. If that's the case, then in addition to perfect optimization, the company will have achieved perfect stagnation and stasis.
Look at any large organization that's optimized from the top down and you'll find it almost has to discourage front-line innovation. How do you innovate in a world where, when Manufacturing sneezes, Marketing has to say "gesundheit"?
The price to be paid for tight integration is rigidity, and a powerful resistance to change. Today's efficiency almost guarantees tomorrow's obsolescence.
On the other hand, advocating inefficiency and poor business integration just doesn't sit very well.
Do you still think desktop policy is a simple matter?
Think again.
I had a plan.
Last week's column listed three factors to take into account in deciding how far you should open up or lock down desktop PCs: The company's size, how heavily it is regulated, and the role of the individual employee. Bigger, more heavily regulated companies tend to need more tightly controlled PCs. The same is true of employee roles that are more regimented and less flexible.
I'd planned to continue this week with three more factors. One was going to be company strategy. Specifically, companies that sell strongly commoditized products -- products whose only differentiation is price -- have to focus heavily on cost control, meaning lockdown makes sense.
So much for planning: On reflection, I don't buy it.
I don't care if your company manufactures cinder blocks, or buys and sells lentils. It doesn't matter if the product itself is a commodity. Any company that wants to enjoy continued success needs to be on a constant lookout for new and better ways of getting things done.
There are two ways to go about finding these improvements. One is top-down planning. The other is bottom-up initiative. Since the business case for opening up PCs is built on the importance of bottom-up initiative, this is a subject we need to explore in depth.
Top-down planning has the advantage over bottom-up initiative when it comes to engineering elegance. Since the only way to optimize the whole is to sub-optimize the parts, business leaders should engineer the corporation from the top down, according to a carefully rendered program of progressive decomposition -- from core process to sub-processes to sub-sub-processes to activities to tasks to procedures, all carefully orchestrated and controlled.
It's the organization as machine. The gears mesh, the shafts turn, the subassemblies integrate, and everything hums. IT locks down the desktops because any variation from the grand design can only optimize a part at the expense of the whole.
Now imagine you're an employee who performs actual, for example, work. You know how the work gets done because you do it every day. You see an opportunity -- a way to do it better.
Which is too bad, because better people than you have already designed the whole company. There's no room for bottom-up initiative. How could there be? Change anywhere could unbalance the whole machine.
Sure sounds convincing, doesn't it? Well, no, it doesn't. Company processes aren't as carefully engineered as all that. They aren't perfectly optimized from a global, top-down perspective.
The situation is messier than that.
In a typical company, core processes ... the processes that form the heart of the business ... are well-engineered and well supported by the company's enterprise systems. It's hard to escape this conclusion because by definition, a company's core processes are what give it a competitive advantage. That being the case, they will have received the most attention, brainpower, and investment.
Move away from the core processes and you typically find solutions that are more ad hoc in nature. That makes sense. Company leaders should invest more time and attention in competitive differentiators than in business responsibilities that support business responsibilities that support business responsibilities that support competitive differentiators.
So we'd expect to find more opportunities for bottom-up innovation in non-core areas of responsibility than in core processes. This logic dictates a policy that locks down most rigidly the PCs of employees who play primary roles in core and near-core business functions and processes. The PCs of employees whose responsibilities are farther away from the core would be more open.
This makes for a neat, tidy little business paradigm, not too different from Geoffrey Moore's "Keep the core and outsource the rest."
Don't trust tidy little business paradigms. Too often they are on the wrong side of the line that separates the simple from the simplistic.
Here's one of the nasty little conundrums (conundra?) that get in the way. Imagine your company's core and supporting processes really are carefully engineered and perfectly balanced. If that's the case, then in addition to perfect optimization, the company will have achieved perfect stagnation and stasis.
Look at any large organization that's optimized from the top down and you'll find it almost has to discourage front-line innovation. How do you innovate in a world where, when Manufacturing sneezes, Marketing has to say "gesundheit"?
The price to be paid for tight integration is rigidity, and a powerful resistance to change. Today's efficiency almost guarantees tomorrow's obsolescence.
On the other hand, advocating inefficiency and poor business integration just doesn't sit very well.
Do you still think desktop policy is a simple matter?
Think again.
-----------------
Copyright and other stuff -- The great KJR link point
Monday, March 17, 2008
Deciding how far to open the portal door
3/10/2008
What is it about vitamins?
When I was a kid they were chewable. Then I grew up and they were small, coated, and easily swallowed.
Now they make me feel like Mr. Ed: They're the size of horse pills, and if (when) they get stuck on the way down I taste alfalfa, or maybe straw.
Speaking of things that are hard to swallow, correspondent Mark Sowash made me aware that, since at least last October, Gartner has been predicting increased employee ownership of PCs (Ready or not, here comes user PC choice Computerworld 10/15/2007).
There is, of course, a difference between prediction and advocacy. Still, fair's fair -- Gartner got there first (ouch!) and I agree (the horror!).
The Computerworld article describes a 250-employee consulting company that's giving employee PC ownership a try.
It isn't going to be a free-for-all. The company is establishing standards for all PCs that connect to the corporate network, especially for security. It will scan devices for compliance before they connect. It's moving its enterprise applications to web-based access to keep enterprise data in the data center.
Sounds well-thought-out and workable to me.
Following last week's column on this subject (Getting to 21st century IT Keep the Joint Running 3/3/2008) I added two posts on Advice Line, the question-and-answer blog I do for InfoWorld (Can virtualization resolve the IT/end-user disconnect? 2/29/2008 and Getting to 21st century IT - User-owned PCs? 3/4/2008), asking for comments. The response was enthusiastic, perceptive, argumentative at times, and in all respects worthwhile.
I was struck by something: The positions taken were generally rooted in a hidden assumption about the nature of the workplace and employee. Those advocating employee ownership, for example, tended to be travelers or knowledge workers who are expected to creatively solve problems for their employers. Many of those who rejected the idea (and the idea of significantly loosened controls) support production workers with well-defined responsibilities that are entirely supported by the company's enterprise applications.
The more I think about the subject the more I'm convinced the right answer isn't yes or no. It's "it depends." This is, in retrospect, obvious. It's also woefully incomplete, because the moment you say the words, you have to then explain what "it" depends on.
We'll start the ball rolling this week with three factors: size, role, and regulation.
Size: Small companies tend to succeed through individual initiative, employing generalists who understand a broad swath of what the company does. Most "business process" happens inside one employee's head.
As companies grow they gain economies of scale. To get them, they have to standardize what was idiosyncratic, whether the subject is business process, HR policy or PC configurations. Employee roles specialize, and what used to happen in one person's head now happens through defined workflows.
It's a sad trade-off: With success comes increasing bureaucracy, because the alternative is having costs increase as fast as revenue, or even faster.
Role: Some jobs are defined by their lack of clear definition. While the desired outcome might be clear, the means for achieving it is not. The list might include sales, marketing, consulting, IT developer (yes, IT developer) and varying kinds of analyst.
If you can't predict what someone will have to do to get the job done it seems futile to lock down a specific toolkit and say, "that's all you need."
Other jobs are rigidly defined and narrowly focused. Call center agents come to mind. While they might, and often are called on to be flexible in how they converse with callers, when the time comes to pull data out of the company's systems and put new data in, you want every agent to use the exact same tools in the exact same way.
Regulation: Some businesses are more highly regulated than others. This is neither bad nor good (I remember the pre-environmental-regulation United States and like what we have now much better). It's a fact.
Another fact: Regulators care about compliance and only compliance. If compliance means a reduced ability to innovate, too bad. HIPAA regulators care about protecting patient data. The impact on creativity elsewhere in the company isn't their concern.
The Big Finish: The smaller the company, the broader and fuzzier the role, and the less regulated the industry, the more likely it is you can open things up.
The really tough challenge is figuring out what you can do, if you're big and highly regulated, to provide as much empowerment as possible. After all, the people who run big companies rarely want to preside over bureaucracies.
They just need an alternative.
What is it about vitamins?
When I was a kid they were chewable. Then I grew up and they were small, coated, and easily swallowed.
Now they make me feel like Mr. Ed: They're the size of horse pills, and if (when) they get stuck on the way down I taste alfalfa, or maybe straw.
Speaking of things that are hard to swallow, correspondent Mark Sowash made me aware that, since at least last October, Gartner has been predicting increased employee ownership of PCs (Ready or not, here comes user PC choice Computerworld 10/15/2007).
There is, of course, a difference between prediction and advocacy. Still, fair's fair -- Gartner got there first (ouch!) and I agree (the horror!).
The Computerworld article describes a 250-employee consulting company that's giving employee PC ownership a try.
It isn't going to be a free-for-all. The company is establishing standards for all PCs that connect to the corporate network, especially for security. It will scan devices for compliance before they connect. It's moving its enterprise applications to web-based access to keep enterprise data in the data center.
Sounds well-thought-out and workable to me.
Following last week's column on this subject (Getting to 21st century IT Keep the Joint Running 3/3/2008) I added two posts on Advice Line, the question-and-answer blog I do for InfoWorld (Can virtualization resolve the IT/end-user disconnect? 2/29/2008 and Getting to 21st century IT - User-owned PCs? 3/4/2008), asking for comments. The response was enthusiastic, perceptive, argumentative at times, and in all respects worthwhile.
I was struck by something: The positions taken were generally rooted in a hidden assumption about the nature of the workplace and employee. Those advocating employee ownership, for example, tended to be travelers or knowledge workers who are expected to creatively solve problems for their employers. Many of those who rejected the idea (and the idea of significantly loosened controls) support production workers with well-defined responsibilities that are entirely supported by the company's enterprise applications.
The more I think about the subject the more I'm convinced the right answer isn't yes or no. It's "it depends." This is, in retrospect, obvious. It's also woefully incomplete, because the moment you say the words, you have to then explain what "it" depends on.
We'll start the ball rolling this week with three factors: size, role, and regulation.
Size: Small companies tend to succeed through individual initiative, employing generalists who understand a broad swath of what the company does. Most "business process" happens inside one employee's head.
As companies grow they gain economies of scale. To get them, they have to standardize what was idiosyncratic, whether the subject is business process, HR policy or PC configurations. Employee roles specialize, and what used to happen in one person's head now happens through defined workflows.
It's a sad trade-off: With success comes increasing bureaucracy, because the alternative is having costs increase as fast as revenue, or even faster.
Role: Some jobs are defined by their lack of clear definition. While the desired outcome might be clear, the means for achieving it is not. The list might include sales, marketing, consulting, IT developer (yes, IT developer) and varying kinds of analyst.
If you can't predict what someone will have to do to get the job done it seems futile to lock down a specific toolkit and say, "that's all you need."
Other jobs are rigidly defined and narrowly focused. Call center agents come to mind. While they might, and often are called on to be flexible in how they converse with callers, when the time comes to pull data out of the company's systems and put new data in, you want every agent to use the exact same tools in the exact same way.
Regulation: Some businesses are more highly regulated than others. This is neither bad nor good (I remember the pre-environmental-regulation United States and like what we have now much better). It's a fact.
Another fact: Regulators care about compliance and only compliance. If compliance means a reduced ability to innovate, too bad. HIPAA regulators care about protecting patient data. The impact on creativity elsewhere in the company isn't their concern.
The Big Finish: The smaller the company, the broader and fuzzier the role, and the less regulated the industry, the more likely it is you can open things up.
The really tough challenge is figuring out what you can do, if you're big and highly regulated, to provide as much empowerment as possible. After all, the people who run big companies rarely want to preside over bureaucracies.
They just need an alternative.
-----------------
Copyright and other stuff -- The great KJR link point
Thursday, March 6, 2008
Tuesday, March 4, 2008
Getting to 21st century IT
3/3/2008
When is a computer not a computer?
Answer: When it's a portal to an entire universe, as I pointed out last week with perhaps-excessive lyricism. Lyrical or not, quite a few correspondents agreed with the column's core arguments:
Many, misreading last week's column as advocacy of a free-for-all in business computing, were horrified.
My point was something different: This, like it or not, is the situation. IT needs to figure out how to adapt, instead of establishing policies and procedures predicated on a world that no longer exists.
Look, for example, at an increasingly common class of employee -- the traveler. Few among us still entertain the notion that this is a cushy, glamorous existence. Travel delays, increasingly cramped airline seating, the need to schlep one's office and wardrobe along, and the rigors of threat levels eternally Orange combine to make business travel an annoying lifestyle at best.
Add to this the typical corporate no-personal-use computing policy. In practical terms it means no ability to answer personal e-mail for days at a time; no right to use the Internet for non-business purposes, even after business hours; no right to download music and add it to an MP3 player to help pass the time during the next cross-country flight.
In many companies, it appears corporate IT expects travelers to bring two laptops along -- one personal, the other corporate. Very nice.
Here's one more, related point: Many IT end-user support organizations are trapped in the "Whiteout-on-a-screen" mentality while many of the alleged Whiteout users routinely participate in (for example) on-line gaming environments with sophisticated interfaces they nonchalantly figure out on their own, without thinking much of it.
This is the challenge. The question is what to do about it.
Correspondent Richard Resnick provided the most extreme suggestion: No corporate-owned PCs at all. Let employees buy their own -- whatever they think they need to do their jobs. It's Nicholas Carr's vision in reverse: Only central IT remains. Employees take over ownership of the periphery, including responsibility for their own PC support.
It's an intriguing alternative, and one not easily envisioned. Certainly, the nature of the protections IT would institute would be very different given the change in boundary. I leave the specifics as an exercise for the reader.
Another correspondent, Will Pearce, provided a less radical alternative: Virtualize. Give end-users two virtual machines.
IT has valid concerns about having to support systems on which end-users have installed unapproved software, so one virtual machine would be buttoned-down, corporate, protected, fully supported, and strongly connected.
End-users and business managers, on the other hand, frequently discover useful software tools that are not on IT's list of supported applications. Enter the Sandbox -- a place end-users can install and use business-focused applications IT doesn't and doesn't need to support. If they work without creating conflicts with other applications, more power to everyone, and IT might even add them to the supported list.
If they don't ... it's the Sandbox. All the user has to do is switch over to the corporate virtual machine to continue working. All IT has to do is to restore the standard Sandbox virtual machine.
I'd add a third virtual machine as well. It would be open, personal, still reasonably protected ... but unsupported beyond restoring the virtual machine, and kept outside the corporate firewall. Travelers and other employees in the growing population of those who donate personal time to their employers would be able to use their personal virtual machine to take care of personal business without impinging on corporate IT.
Even if you ignore the issues discussed this week and last, virtualization would appear to provide an easier-to-administer alternative to maintaining standard images for restoring hashed-up systems. It certainly seems like a workable technological core for handling the challenges discussed last week and here.
End-user ownership of the periphery is a fascinating long-shot. Virtualization is a promising but unproven possibility. Entirely different alternatives might prove superior for supporting the 21st century workforce.
Underneath the specific solutions is the contrast between two corporate attitudes. One considers employees a necessary evil -- unavoidable, but suspect; untrustworthy entities from which the corporation must be protected. The other recognizes employees as the source of all success.
IT's response to the 21st century workforce depends on which sort of employee companies think they have.
So, as it happens, does every company's long-term financial success.
When is a computer not a computer?
Answer: When it's a portal to an entire universe, as I pointed out last week with perhaps-excessive lyricism. Lyrical or not, quite a few correspondents agreed with the column's core arguments:
- When using their home computers, end-users experience a vast array of possibilities, but at the office they operate in a very constrained space; and
- Increasingly, "work/life balance" is giving way to "live your life wherever you are."
Many, misreading last week's column as advocacy of a free-for-all in business computing, were horrified.
My point was something different: This, like it or not, is the situation. IT needs to figure out how to adapt, instead of establishing policies and procedures predicated on a world that no longer exists.
Look, for example, at an increasingly common class of employee -- the traveler. Few among us still entertain the notion that this is a cushy, glamorous existence. Travel delays, increasingly cramped airline seating, the need to schlep one's office and wardrobe along, and the rigors of threat levels eternally Orange combine to make business travel an annoying lifestyle at best.
Add to this the typical corporate no-personal-use computing policy. In practical terms it means no ability to answer personal e-mail for days at a time; no right to use the Internet for non-business purposes, even after business hours; no right to download music and add it to an MP3 player to help pass the time during the next cross-country flight.
In many companies, it appears corporate IT expects travelers to bring two laptops along -- one personal, the other corporate. Very nice.
Here's one more, related point: Many IT end-user support organizations are trapped in the "Whiteout-on-a-screen" mentality while many of the alleged Whiteout users routinely participate in (for example) on-line gaming environments with sophisticated interfaces they nonchalantly figure out on their own, without thinking much of it.
This is the challenge. The question is what to do about it.
Correspondent Richard Resnick provided the most extreme suggestion: No corporate-owned PCs at all. Let employees buy their own -- whatever they think they need to do their jobs. It's Nicholas Carr's vision in reverse: Only central IT remains. Employees take over ownership of the periphery, including responsibility for their own PC support.
It's an intriguing alternative, and one not easily envisioned. Certainly, the nature of the protections IT would institute would be very different given the change in boundary. I leave the specifics as an exercise for the reader.
Another correspondent, Will Pearce, provided a less radical alternative: Virtualize. Give end-users two virtual machines.
IT has valid concerns about having to support systems on which end-users have installed unapproved software, so one virtual machine would be buttoned-down, corporate, protected, fully supported, and strongly connected.
End-users and business managers, on the other hand, frequently discover useful software tools that are not on IT's list of supported applications. Enter the Sandbox -- a place end-users can install and use business-focused applications IT doesn't and doesn't need to support. If they work without creating conflicts with other applications, more power to everyone, and IT might even add them to the supported list.
If they don't ... it's the Sandbox. All the user has to do is switch over to the corporate virtual machine to continue working. All IT has to do is to restore the standard Sandbox virtual machine.
I'd add a third virtual machine as well. It would be open, personal, still reasonably protected ... but unsupported beyond restoring the virtual machine, and kept outside the corporate firewall. Travelers and other employees in the growing population of those who donate personal time to their employers would be able to use their personal virtual machine to take care of personal business without impinging on corporate IT.
Even if you ignore the issues discussed this week and last, virtualization would appear to provide an easier-to-administer alternative to maintaining standard images for restoring hashed-up systems. It certainly seems like a workable technological core for handling the challenges discussed last week and here.
End-user ownership of the periphery is a fascinating long-shot. Virtualization is a promising but unproven possibility. Entirely different alternatives might prove superior for supporting the 21st century workforce.
Underneath the specific solutions is the contrast between two corporate attitudes. One considers employees a necessary evil -- unavoidable, but suspect; untrustworthy entities from which the corporation must be protected. The other recognizes employees as the source of all success.
IT's response to the 21st century workforce depends on which sort of employee companies think they have.
So, as it happens, does every company's long-term financial success.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, February 26, 2008
The portal
2/25/2008
In 1980, a 3278 green-screen terminal cost (as I recall) about $6,000, not including the mainframe it attached to.
Along came the PC. It cost half that, and was self-sufficient.
IT tried to keep them out. They put too much power in the hands of ignorant users and you couldn't do serious computing on them anyway. Yes, the IT authorities made both arguments, simultaneously, and didn't even blush.
PCs leaked in despite IT's opinion. Distributed computing leaked in too. The economics made them unavoidable. Various pundits claim otherwise, but they are comparing the costs of PCs and distributed computing with the competition-deflated costs of mainframe computing, not the pre-PC high-margin early-1980s price tag.
Fast-forward to now. You can buy a 150 gigabyte drive for less than $100. For another hundred bucks you can buy a USB external disk to back it up.
For 150 backed-up gigabytes, IT would charge $1,500 per year.
From my backup drive I can restore any file in five minutes. IT would take more than a day. Self-service? Forget it.
In 1980, IT completely locked down the 3278 terminal, by definition. IT now locks down the PC, not by definition but by choice. Meanwhile, at home, people install whatever they please, and in spite of what the doomsayers tell you, few run into insurmountable problems. Those who do sheepishly ask their teen-aged children to help them. Their teenagers give them the same eyeball rolls they get from the Help Desk staff at work, but much better service.
Nothing in this comparison is fair. Fair has nothing to do with it. My PC at home beckons, saying "Yes, you can do that too." My PC at work says, "No you can't." Your end-users experience that contrast every working day.
Preaching to them that "it's a business computer, to be used only for business purposes," isn't persuasive, because they know something we in IT often ignore: It isn't really a computer.
Oh, technically that's what it is, but technically doesn't matter. The PC is a portal to a universe of possibilities. While the word "cyberspace" has fallen out of use, the idea of cyberspace is alive, well, and built into the perception of everyone who looks at a screen while manipulating a keyboard and mouse.
It might be time ... past time ... for IT to look at its job in a new way.
Try this on for size: Imagine you ran IT as if it embraced this PC-as-portal perspective. As if IT's job was to manage one corner of that universe of possibilities.
What would you do differently?
Let's take it a step further. Let's look, not just at the PC but about work as a whole from the employee's point of view. That shouldn't be too hard. We in IT are employees too, when we aren't busy being IT professionals.
From the employee's point of view the job is, in addition to being a way to earn a living, a place for: social interaction; developing the self-esteem that comes from creating value and achieving important things; structuring time and staying occupied; exercising their brains and keeping them from becoming stale.
Few employees draw a hard boundary around their work life, keeping it psychologically distinct and independent of the rest of their life. They are the same people in the office as out of the office.
We in IT are stuck in a 1950s industrial view of the workplace. Much of the workforce is post-industrial in perspective. They don't "achieve work/life balance." They just live their lives, wherever they happen to be at the moment -- sometimes in the office, sometimes out of it.
In the office they research reports, create presentations, check their investment portfolios, answer business e-mail, answer personal e-mail, make business phone calls, answer personal phone calls.
Out of the office they think about the reports, edit the presentations, check their investment portfolios, answer business e-mail, answer personal e-mail, make business phone calls, and answer personal phone calls.
Employees live a significant part of their lives in the universe of possibilities they reach through their PCs, their Blackberries, the Treos, their iPhones.
The economic gap between self-sufficient computing and central IT that drove the PC revolution is back. The existential gulf separating IT's perception of work from the employee perception of work is new, and wider. We in IT had better figure it out, or business users will figure it out without us.
Because for us, a PC is an expensive, hard-to-support business resource. But for them it's a portal to an entire universe they can buy at Costco for a few hundred bucks.
In 1980, a 3278 green-screen terminal cost (as I recall) about $6,000, not including the mainframe it attached to.
Along came the PC. It cost half that, and was self-sufficient.
IT tried to keep them out. They put too much power in the hands of ignorant users and you couldn't do serious computing on them anyway. Yes, the IT authorities made both arguments, simultaneously, and didn't even blush.
PCs leaked in despite IT's opinion. Distributed computing leaked in too. The economics made them unavoidable. Various pundits claim otherwise, but they are comparing the costs of PCs and distributed computing with the competition-deflated costs of mainframe computing, not the pre-PC high-margin early-1980s price tag.
Fast-forward to now. You can buy a 150 gigabyte drive for less than $100. For another hundred bucks you can buy a USB external disk to back it up.
For 150 backed-up gigabytes, IT would charge $1,500 per year.
From my backup drive I can restore any file in five minutes. IT would take more than a day. Self-service? Forget it.
In 1980, IT completely locked down the 3278 terminal, by definition. IT now locks down the PC, not by definition but by choice. Meanwhile, at home, people install whatever they please, and in spite of what the doomsayers tell you, few run into insurmountable problems. Those who do sheepishly ask their teen-aged children to help them. Their teenagers give them the same eyeball rolls they get from the Help Desk staff at work, but much better service.
Nothing in this comparison is fair. Fair has nothing to do with it. My PC at home beckons, saying "Yes, you can do that too." My PC at work says, "No you can't." Your end-users experience that contrast every working day.
Preaching to them that "it's a business computer, to be used only for business purposes," isn't persuasive, because they know something we in IT often ignore: It isn't really a computer.
Oh, technically that's what it is, but technically doesn't matter. The PC is a portal to a universe of possibilities. While the word "cyberspace" has fallen out of use, the idea of cyberspace is alive, well, and built into the perception of everyone who looks at a screen while manipulating a keyboard and mouse.
It might be time ... past time ... for IT to look at its job in a new way.
Try this on for size: Imagine you ran IT as if it embraced this PC-as-portal perspective. As if IT's job was to manage one corner of that universe of possibilities.
What would you do differently?
Let's take it a step further. Let's look, not just at the PC but about work as a whole from the employee's point of view. That shouldn't be too hard. We in IT are employees too, when we aren't busy being IT professionals.
From the employee's point of view the job is, in addition to being a way to earn a living, a place for: social interaction; developing the self-esteem that comes from creating value and achieving important things; structuring time and staying occupied; exercising their brains and keeping them from becoming stale.
Few employees draw a hard boundary around their work life, keeping it psychologically distinct and independent of the rest of their life. They are the same people in the office as out of the office.
We in IT are stuck in a 1950s industrial view of the workplace. Much of the workforce is post-industrial in perspective. They don't "achieve work/life balance." They just live their lives, wherever they happen to be at the moment -- sometimes in the office, sometimes out of it.
In the office they research reports, create presentations, check their investment portfolios, answer business e-mail, answer personal e-mail, make business phone calls, answer personal phone calls.
Out of the office they think about the reports, edit the presentations, check their investment portfolios, answer business e-mail, answer personal e-mail, make business phone calls, and answer personal phone calls.
Employees live a significant part of their lives in the universe of possibilities they reach through their PCs, their Blackberries, the Treos, their iPhones.
The economic gap between self-sufficient computing and central IT that drove the PC revolution is back. The existential gulf separating IT's perception of work from the employee perception of work is new, and wider. We in IT had better figure it out, or business users will figure it out without us.
Because for us, a PC is an expensive, hard-to-support business resource. But for them it's a portal to an entire universe they can buy at Costco for a few hundred bucks.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, February 19, 2008
Capability Maturity Model revisited
2/18/2008
I wrote harsh words about the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) (The connection between leadership and process in IT Keep the Joint Running 1/14/2008).
Nobody wrote to disagree. Not exactly. Hillel Glazer, an SEI insider, politely informed me that I was hopelessly out of date: SEI abandoned CMM in 2001 in favor of Capability Maturity Model Integration (CMMI). He agreed to an interview to explain the situation. Mike Konrad, one of CMMI's authors, reviewed Hillel's answers and wrote me independently to endorse them.
Bob: SEI describes CMMI as a general-purpose process framework that can be used to create just about any sort of business process -- not just software methodologies. Do we need yet another process methodology, given that we already have: Lean, Six Sigma, Lean Six Sigma, Theory of Constraints, and Reengineering?
Hillel: To be more precise, "CMMI-DEV" is not for creating business processes or for creating (developing) products, but for improving the business processes of product and service development. CMMI assumes a given organization already has business processes and desires to improve them. What happens all too often is organizations are compelled to use CMMI but start out not having/knowing their processes and so CMMI becomes both how they define their processes as well as how they improve them. It's a fundamental -- and widely held -- misunderstanding of CMMI.
Bob: In his 2005 interview, Capers Jones was openly dismissive of Agile and similar adaptive, iterative methodologies. With CMMI, has SEI softened its stance?
Hillel: Capers Jones is not a reviewer or contributor to CMMI, and I wouldn't say SEI folks and Capers Jones see eye to eye on many things.
When CMMI was being written, reviewers were criticizing SEI for making it so "waterfall" centric. The authors were genuinely dumbfounded as to what it is in the model that gave that "anti-iteration" connotation. CMMI is 100% agnostic as to the product development life cycle an organization chooses to use, and always has been. Also, the SEI has created a team-oriented development method called "Team Software Process" (TSP) which has been demonstrated as being very agile-oriented.
Bob: Does any of this really matter to bread-and-butter IT shops? Most companies don't develop -- they integrate and configure purchased applications. The packaged methodologies, waterfall or iterative, weren't designed for this world. Does CMMI offer something useful for it, or is it also intended for new development?
Hillel: Right now, ITIL probably provides more value than CMMI to pure-play IT shops. However, stay tuned, there's another CMMI in the works for "services" organizations that goes beyond a static library of management and service workflows and offers a continuous improvement mechanism to companies providing services -- IT or otherwise.
Bob: I've recommended culture change as the first step in implementing a more process-driven approach in any organization -- to create a "culture of process" -- and to make sure process owners are fully educated in process management. Do you agree? If not, how do you recommend starting down the CMMI path?
Hillel: I completely agree. When working with companies that do need a culture shift, the first thing I get them to internalize are the CMMI's "generic practices" which provide the process acculturation so many organizations lack.
In many cases, no matter how much power they've been given, you can't start with the CIO, you must start with the CEO. The CEO needs to see the business value of being process-oriented. Otherwise, the CIO will be placed in an untenable position at the business level.
Bob: Anything else?
Hillel: What's most often misunderstood about this is that "CMMI is a model, not a standard." CMMI contains no processes or procedures of its own, and is not a thing that can be complied with. It's a fundamental shift in expectation and experience of most CMMI users -- who are used to complying with standards. Wrapping one's head around and being able to apply a model takes a whole different set of aptitudes than complying with a standard.
We hear "just tell me what to do" all the time. Combine that with the impatience (read: short attention span) and lack of process culture among too many executives -- a topic you regularly rail against -- and you have a recipe for process disaster.
Bob: Last question: Do you agree Keep the Joint Running is the most insightful commentary in the IT industry? Or would you rather have me twist your responses in creative ways that make you appear to be the biggest schlemiel in the trade?
Hillel: LOL!
Bob: Don't say I didn't warn you ...
I wrote harsh words about the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) (The connection between leadership and process in IT Keep the Joint Running 1/14/2008).
Nobody wrote to disagree. Not exactly. Hillel Glazer, an SEI insider, politely informed me that I was hopelessly out of date: SEI abandoned CMM in 2001 in favor of Capability Maturity Model Integration (CMMI). He agreed to an interview to explain the situation. Mike Konrad, one of CMMI's authors, reviewed Hillel's answers and wrote me independently to endorse them.
Bob: SEI describes CMMI as a general-purpose process framework that can be used to create just about any sort of business process -- not just software methodologies. Do we need yet another process methodology, given that we already have: Lean, Six Sigma, Lean Six Sigma, Theory of Constraints, and Reengineering?
Hillel: To be more precise, "CMMI-DEV" is not for creating business processes or for creating (developing) products, but for improving the business processes of product and service development. CMMI assumes a given organization already has business processes and desires to improve them. What happens all too often is organizations are compelled to use CMMI but start out not having/knowing their processes and so CMMI becomes both how they define their processes as well as how they improve them. It's a fundamental -- and widely held -- misunderstanding of CMMI.
Bob: In his 2005 interview, Capers Jones was openly dismissive of Agile and similar adaptive, iterative methodologies. With CMMI, has SEI softened its stance?
Hillel: Capers Jones is not a reviewer or contributor to CMMI, and I wouldn't say SEI folks and Capers Jones see eye to eye on many things.
When CMMI was being written, reviewers were criticizing SEI for making it so "waterfall" centric. The authors were genuinely dumbfounded as to what it is in the model that gave that "anti-iteration" connotation. CMMI is 100% agnostic as to the product development life cycle an organization chooses to use, and always has been. Also, the SEI has created a team-oriented development method called "Team Software Process" (TSP) which has been demonstrated as being very agile-oriented.
Bob: Does any of this really matter to bread-and-butter IT shops? Most companies don't develop -- they integrate and configure purchased applications. The packaged methodologies, waterfall or iterative, weren't designed for this world. Does CMMI offer something useful for it, or is it also intended for new development?
Hillel: Right now, ITIL probably provides more value than CMMI to pure-play IT shops. However, stay tuned, there's another CMMI in the works for "services" organizations that goes beyond a static library of management and service workflows and offers a continuous improvement mechanism to companies providing services -- IT or otherwise.
Bob: I've recommended culture change as the first step in implementing a more process-driven approach in any organization -- to create a "culture of process" -- and to make sure process owners are fully educated in process management. Do you agree? If not, how do you recommend starting down the CMMI path?
Hillel: I completely agree. When working with companies that do need a culture shift, the first thing I get them to internalize are the CMMI's "generic practices" which provide the process acculturation so many organizations lack.
In many cases, no matter how much power they've been given, you can't start with the CIO, you must start with the CEO. The CEO needs to see the business value of being process-oriented. Otherwise, the CIO will be placed in an untenable position at the business level.
Bob: Anything else?
Hillel: What's most often misunderstood about this is that "CMMI is a model, not a standard." CMMI contains no processes or procedures of its own, and is not a thing that can be complied with. It's a fundamental shift in expectation and experience of most CMMI users -- who are used to complying with standards. Wrapping one's head around and being able to apply a model takes a whole different set of aptitudes than complying with a standard.
We hear "just tell me what to do" all the time. Combine that with the impatience (read: short attention span) and lack of process culture among too many executives -- a topic you regularly rail against -- and you have a recipe for process disaster.
Bob: Last question: Do you agree Keep the Joint Running is the most insightful commentary in the IT industry? Or would you rather have me twist your responses in creative ways that make you appear to be the biggest schlemiel in the trade?
Hillel: LOL!
Bob: Don't say I didn't warn you ...
-----------------
Copyright and other stuff -- The great KJR link point
Friday, February 15, 2008
Tuesday, February 12, 2008
Carr-toonish engineering
2/11/2008
If someone does something that's patently ridiculous, but manages to draw enough attention that it generates a lot of discussion, has that person performed a valuable service or just wasted our time?
But enough about Paris Hilton, Kiefer Sutherland and Lindsay Lohan. In our own industry we can ask a similar question about Nicholas Carr, who, as mentioned last week, has predicted that the "technical aspect of IT" (which in Carr's world is IT infrastructure management) will move to the Internet, which will become the CPU-cycle-provisioning equivalent of an electrical power plant.
With the technical part gone, handling the non-technical remainder (I bet you didn't know application design, development and integration are non-technical undertakings) won't require a separate in-house IT organization any more. Instead, they will become a mixture of Software as a Service (SaaS) applications and business-department-developed code that runs on the utility computing infrastructure.
Sometimes, fault-finding isn't the best way to evaluate a new idea. A superior alternative is to be helpful and positive -- to figure out how to make it work (for a historical example, see Inhaling network computers KJR, 1/13/1997.)
What will be required for IT to go away?
First of all, let's assume Carr isn't simply "predicting" the success of IT infrastructure outsourcing, as I contended last week -- that he's serious about utility computing in the electrical generation sense.
In the deregulated electrical power industry, generation companies pump 60-cycle current onto the grid, metering how much they provide. End-customers draw electricity off the grid. Their local provider acts as a broker, buying current from the low-cost provider and metering consumption.
This is, by the way, how you can buy wind-generated electricity if you prefer. You don't really get the exact electrons pushed onto the grid by a wind farm. You simply instruct your broker to buy enough of them to satisfy your consumption. The rest is just balancing the books.
For utility computing to work, we would need a similar metering and billing infrastructure. We'd need a lot more, too. For example:
Now, look ahead just far enough that you're at the end of any useful business planning horizon. You'll reach a very different conclusion.
If someone does something that's patently ridiculous, but manages to draw enough attention that it generates a lot of discussion, has that person performed a valuable service or just wasted our time?
But enough about Paris Hilton, Kiefer Sutherland and Lindsay Lohan. In our own industry we can ask a similar question about Nicholas Carr, who, as mentioned last week, has predicted that the "technical aspect of IT" (which in Carr's world is IT infrastructure management) will move to the Internet, which will become the CPU-cycle-provisioning equivalent of an electrical power plant.
With the technical part gone, handling the non-technical remainder (I bet you didn't know application design, development and integration are non-technical undertakings) won't require a separate in-house IT organization any more. Instead, they will become a mixture of Software as a Service (SaaS) applications and business-department-developed code that runs on the utility computing infrastructure.
Sometimes, fault-finding isn't the best way to evaluate a new idea. A superior alternative is to be helpful and positive -- to figure out how to make it work (for a historical example, see Inhaling network computers KJR, 1/13/1997.)
What will be required for IT to go away?
First of all, let's assume Carr isn't simply "predicting" the success of IT infrastructure outsourcing, as I contended last week -- that he's serious about utility computing in the electrical generation sense.
In the deregulated electrical power industry, generation companies pump 60-cycle current onto the grid, metering how much they provide. End-customers draw electricity off the grid. Their local provider acts as a broker, buying current from the low-cost provider and metering consumption.
This is, by the way, how you can buy wind-generated electricity if you prefer. You don't really get the exact electrons pushed onto the grid by a wind farm. You simply instruct your broker to buy enough of them to satisfy your consumption. The rest is just balancing the books.
For utility computing to work, we would need a similar metering and billing infrastructure. We'd need a lot more, too. For example:
- Web 3.0: We will need a grid computing architecture that runs applications wherever CPU cycles happen to be cheapest (with suitable metering and billing -- see above).
- Virtualization: This will have to be perfect, so that the CPU cycles you buy can run your applications no matter what operating system they were written for.
- Quality of Service: Different applications need different levels of performance. Buyers will need a way to specify how fast their cycles have to be, and without the help of those pesky engineers who would be housed in an IT department if it hadn't been disbanded.
- AI-based data design: With professional, centralized IT evaporated into the business, which will be building whatever custom applications remain, there will no longer be an organizational home for data designers. The only alternative is technology smart enough to handle this little engineering chore.
- Automated, self-tuning pre-fetch: Last week's column demonstrated the impact of latency in the communications channel on linked SaaS-supplied systems -- the speed of light slows table joins to a crawl.
This is fixable, so long as systems are smart enough to automatically pre-fetch records prior to needing them. Every SaaS vendor will have to provide this facility automatically, since businesses will no longer employ engineers able to manually performance-tune system linkages.
- New security paradigm: Sorry about the use of "paradigm." It fits here. You'll be running all of your applications on public infrastructure, on the wrong side of the firewall (which -- good news! -- you'll no longer need). Think it will be hard for someone with ingenuity to plant a Trojan that monitors the cycles and siphons off every business secret you no longer have?
- AI-based data warehouse design: Let's assume for the sake of argument that the Carr-envisioned future happens as he predicts. You will still want to mine all of your data, in spite of it being schmeared out across the SaaS landscape.
I see two choices. The first, almost unimaginable, is an efficient, distributed, virtual data warehouse, reminiscent of the sea shell collection Steven Wright keeps scattered on beaches all over the world.
The alternative is the same data warehouse technology we've grown accustomed to. Except we don't have IT anymore, so we'll need an AI design technology to pull it together for us, performance optimized and ready for analysis.
Now, look ahead just far enough that you're at the end of any useful business planning horizon. You'll reach a very different conclusion.
-----------------
Copyright and other stuff -- The great KJR link point
Wednesday, February 6, 2008
Tuesday, February 5, 2008
Carr-ied away
2/4/2008
Nicholas Carr has a new theory -- that internal IT is reaching the end of the line, because information technology will follow the same commoditization curve that electrical utilities followed a century ago.
Okay, it isn't really a new theory, although from the attention Carr is getting for his new book, which should have been titled The Joys of Griddish but instead is called The Big Switch: Rewiring the World, from Edison to Google (W. W. Norton, 2008), you'd think he had come up with it all by himself.
Carr, you'll recall, previously theorized that IT doesn't matter (We ain't there quite yet Keep the Joint Running 6/16/2003). His reasoning: Every business has access to the same information technology, so IT can't provide a sustainable strategic advantage.
That his old theory was fatally flawed is easily demonstrated: Every business has access to the same everything as every other business -- the same technology, ideas, people, processes, capital, real estate, and silly articles published in the Harvard Business Review because their authors were once on its editorial staff.
Were we to accept Carr's past logic and apply it equally to all subjects, we would despairingly conclude that nothing matters. Now, not content with turning us all into depressed nihilists, Carr has discovered (and we should be pleased for him) the Internet and the possibility of outsourcing all of the computing cycles of every business to it.
What Carr has visionarily discovered, while tossing in terms like grid and utility computing to prove he is Fully Buzzword Compliant, is IT infrastructure outsourcing, a mere three decades after it began. Meanwhile, many very large corporations that outsourced their IT infrastructure have found that economies of scale reach a point of diminishing returns -- enterprises reach a size where running their own data center costs less and provides more value than contracting with an outsourcer.
But never mind this little quibble. After all, many businesses aren't that big and data center outsourcing does make sense for them. It's nothing new and makes no difference. It's business as usual right now, and companies still need an IT organization, because ...
Applications and the information they process are where the IT rubber meets the business road. Computer programs are not indistinguishable from one another. The information in the data repositories they control is unique, valuable, and (assuming corporations are careful about information security) private.
Carr hasn't entirely ignored this reality in "his" theory of utility computing. He merely waves it off as trivial -- something easily solved through a combination of Software as a Service (SaaS, which if you've been asleep for awhile means hosted solutions) and ... here's an exact quote ... "the ability to write your own code but use utility suppliers to run it and to store it. Companies will continue to have the ability to write proprietary code and to run it as a service to get the efficiencies and the flexibility it provides."
With unparalleled perspicuity, Carr has figured out that companies can write their own code and then run it in an outsourced data center. Hokey smokes!
Carr's New Insight is that responsibility for applications will move "into the business" which is why IT will eventually go away. He endorses the notion that businesses can easily integrate disparate SaaS-provided applications and databases across the Internet using a few easy-to-use interfaces.
What nonsense. Most internal IT organizations long ago changed their focus. They seldom develop. Mostly they configure and integrate purchased applications.
Nothing about this is easy. Integrating multiple applications and their databases takes complex engineering, not facile hand-waving. Moving responsibility "into the business" means nothing more than managing multiple, smaller, poorly cooperating IT departments instead of single, larger centralized ones. Ho hum.
Nor can integrating multiple SaaS systems work in a high-volume production environment. That's because of a concept network engineers but not self-appointed "experts" understand: latency.
Imagine a financial services company. Customer management is SaaS in California. loan operations is SaaS in Massachusetts. You have to update 10 million customer accounts every day with interest computations. The minimum latency imposed by the laws of physics on an ordinary two-table join adds more than 45 hours to this little batch run.
Well-integrated computing environments come from serious engineering. Phrases like utility computing and grid might obscure this fact behind a fog of vagueness. They don't eliminate it.
I have my own vision for the future of IT. In it, only people who have written code, designed databases, administered servers or engineered networks at some time in their careers will get to write about IT's past, present and future.
The rest can include themselves out.
Nicholas Carr has a new theory -- that internal IT is reaching the end of the line, because information technology will follow the same commoditization curve that electrical utilities followed a century ago.
Okay, it isn't really a new theory, although from the attention Carr is getting for his new book, which should have been titled The Joys of Griddish but instead is called The Big Switch: Rewiring the World, from Edison to Google (W. W. Norton, 2008), you'd think he had come up with it all by himself.
Carr, you'll recall, previously theorized that IT doesn't matter (We ain't there quite yet Keep the Joint Running 6/16/2003). His reasoning: Every business has access to the same information technology, so IT can't provide a sustainable strategic advantage.
That his old theory was fatally flawed is easily demonstrated: Every business has access to the same everything as every other business -- the same technology, ideas, people, processes, capital, real estate, and silly articles published in the Harvard Business Review because their authors were once on its editorial staff.
Were we to accept Carr's past logic and apply it equally to all subjects, we would despairingly conclude that nothing matters. Now, not content with turning us all into depressed nihilists, Carr has discovered (and we should be pleased for him) the Internet and the possibility of outsourcing all of the computing cycles of every business to it.
What Carr has visionarily discovered, while tossing in terms like grid and utility computing to prove he is Fully Buzzword Compliant, is IT infrastructure outsourcing, a mere three decades after it began. Meanwhile, many very large corporations that outsourced their IT infrastructure have found that economies of scale reach a point of diminishing returns -- enterprises reach a size where running their own data center costs less and provides more value than contracting with an outsourcer.
But never mind this little quibble. After all, many businesses aren't that big and data center outsourcing does make sense for them. It's nothing new and makes no difference. It's business as usual right now, and companies still need an IT organization, because ...
Applications and the information they process are where the IT rubber meets the business road. Computer programs are not indistinguishable from one another. The information in the data repositories they control is unique, valuable, and (assuming corporations are careful about information security) private.
Carr hasn't entirely ignored this reality in "his" theory of utility computing. He merely waves it off as trivial -- something easily solved through a combination of Software as a Service (SaaS, which if you've been asleep for awhile means hosted solutions) and ... here's an exact quote ... "the ability to write your own code but use utility suppliers to run it and to store it. Companies will continue to have the ability to write proprietary code and to run it as a service to get the efficiencies and the flexibility it provides."
With unparalleled perspicuity, Carr has figured out that companies can write their own code and then run it in an outsourced data center. Hokey smokes!
Carr's New Insight is that responsibility for applications will move "into the business" which is why IT will eventually go away. He endorses the notion that businesses can easily integrate disparate SaaS-provided applications and databases across the Internet using a few easy-to-use interfaces.
What nonsense. Most internal IT organizations long ago changed their focus. They seldom develop. Mostly they configure and integrate purchased applications.
Nothing about this is easy. Integrating multiple applications and their databases takes complex engineering, not facile hand-waving. Moving responsibility "into the business" means nothing more than managing multiple, smaller, poorly cooperating IT departments instead of single, larger centralized ones. Ho hum.
Nor can integrating multiple SaaS systems work in a high-volume production environment. That's because of a concept network engineers but not self-appointed "experts" understand: latency.
Imagine a financial services company. Customer management is SaaS in California. loan operations is SaaS in Massachusetts. You have to update 10 million customer accounts every day with interest computations. The minimum latency imposed by the laws of physics on an ordinary two-table join adds more than 45 hours to this little batch run.
Well-integrated computing environments come from serious engineering. Phrases like utility computing and grid might obscure this fact behind a fog of vagueness. They don't eliminate it.
I have my own vision for the future of IT. In it, only people who have written code, designed databases, administered servers or engineered networks at some time in their careers will get to write about IT's past, present and future.
The rest can include themselves out.
-----------------
Copyright and other stuff -- The great KJR link point
Monday, February 4, 2008
Beat Me Daddy, Eight to the Bar
Natives who beat drums to drive off evil spirits are objects of scorn to smart Americans who blow horns to break up traffic jams. - Mary Ellen Kelly q.TFTD-L@TAMU.EDU
dan-galvin@oldschool.tamu.edu
dan-galvin@oldschool.tamu.edu
Wednesday, January 30, 2008
a note from the boss on the current company reorganization
A man in a hot air balloon, realizing he was lost, reduced altitude and spotted a woman below. He descended further and shouted to the lady
Excuse me, can you help me? I promised a friend I would meet him an hour ago, but I don't know where I am.The woman below replied,
You're in a hot air balloon, hovering approximately 30 feet above the ground. You're between 40 and 41 degrees north latitude and between 59 and 60 degrees west longitude.
You must be in IT,said the balloonist. Replied the woman,
Actually I am, How did you know?Answered the balloonist,
Well, everything you have told me is technically correct but I've no idea what to make of your information and the fact is I'm still lost. Frankly, you've not been much help at all. If anything, you've delayed my trip.The woman below responded,
You must be in Management.Replied the balloonist,
I am, but how did you know?Said the woman,
Well, you don't know where you are or where you’re going. You have risen to where you are due to a large quantity of hot air. You made a promise, which you've no idea how to keep, and you expect people beneath you to solve your problems. The fact is you are in exactly the same position you were in before we met, but now, somehow, it’s my f****** fault.
Tuesday, January 29, 2008
Run, IT, run ... but not as a business
1/28/2008
Nitpicking is fun, but pragmatism pays the bills.
Last week's column, which deconstructed the notion that CIOs should run IT as a business, was fun, but it might have been more self-indulgent than useful.
The column, if you missed it, listed eleven definitions of "business" and demonstrated that none of them makes sense as a basis for running an IT department. But running IT like a business doesn't require you to define it as one, Louis Sullivan's dictum that "form follows function" notwithstanding.
After you've finished singing, dancing and playing the tuba, running IT like a business means negotiating "service level agreements" (SLAs) for what you do and instituting a system of charge-backs to the rest of the business to pay for it.
Negotiated SLAs are contracts between IT and the departments IT serves, and are just plain silly.
Contracts are how businesses manage relationships with their customers, so if you are to run IT as a business, this is what you must do.
Which brings up the question, what happens if you fail to live up to one of your negotiated SLAs? In business, this would result in financial penalties, withheld payments, binding arbitration, or lawsuits.
Just how stupid would a business look if Manufacturing took IT to court for failing to live up to an SLA? This isn't an easy question to answer because "stupid" isn't easily quantified, nor is there a unit of measure for it. If stupid was electricity and we measured it in volts, I'm pretty sure this would reach Taser levels.
Charge-backs, in contrast to SLAs, do have one thing going for them -- they vastly simplify IT governance. If, for example, Marketing wants to re-plumb the company website with a content management system (CMS), you have no worries. Marketing signs up for the cost and charge-backs give you the budget you need. You hire staff, engage contractors or bring in a systems integrator and everybody is happy.
Not really. What really happens is that your staff based its CMS recommendation on what would integrate best with the rest of your technical architecture, scale without major reconfiguration, and allow granular administration to avoid opening interesting holes in your information security.
The Marketing Director, being a prudent steward of her departmental budget, obtains three competitive bids. All are lower than your estimate.
Of course they are. Because your staff failed to run IT like a business. They are running IT like a department, responsible for managing the company's information assets. And so you lose the Marketing Department's business to a competitor.
It isn't the Marketing Director's fault. IT isn't alone in this nonsense. If IT is to be run as a business, so is every other shared service department in the enterprise, Marketing included. Marketing doesn't want to lose the Dental Accessories business unit's account to an outside agency, so it has to keep its costs as low as possible.
And the race to the bottom continues.
CEOs who organize the enterprise so its shared services departments act as independent businesses have forgotten a basic engineering principle ... that optimizing the parts sub-optimizes the whole and vice versa ("Optimizing the organization Keep the Joint Running 10/27/2003).
Specifically, the company's shared services organizations, when run as businesses, lose their authority to preserve the integrity of essential resources. In the case of IT it's the information architecture. In the case of Marketing it's the corporate image and the meaning of the brand. In the case of Human Resources it's the policies that protect employees from bad managers while allowing managers to deal with non-performing employees without the risk of ending up in court.
And so on.
No question, the idea is seductive. CEOs, for understandable reasons, are likely to have a strong faith in the power of markets to regulate themselves efficiently without the need for outside controls or guidance. That being the case, turning the enterprise into a marketplace sure seems easier than the hard work of instituting the governance processes, difficult choices and consensus building that are otherwise required. As is so often the case, trying to avoid hard work doesn't lead to brilliant results.
Marketplaces don't require all of this because they don't have a purpose. They are simply spaces where entities that do have purpose interact in complex ways.
Companies have a purpose. Marketplaces don't. Turning a company into a marketplace misses this essential difference.
In the end, running IT as a business ... and the enterprise as a marketplace ... is an attempt to avoid the need for governance processes, difficult choices and consensus building.
Another name for these activities is leadership. Done right it's hard work.
Nitpicking is fun, but pragmatism pays the bills.
Last week's column, which deconstructed the notion that CIOs should run IT as a business, was fun, but it might have been more self-indulgent than useful.
The column, if you missed it, listed eleven definitions of "business" and demonstrated that none of them makes sense as a basis for running an IT department. But running IT like a business doesn't require you to define it as one, Louis Sullivan's dictum that "form follows function" notwithstanding.
After you've finished singing, dancing and playing the tuba, running IT like a business means negotiating "service level agreements" (SLAs) for what you do and instituting a system of charge-backs to the rest of the business to pay for it.
Negotiated SLAs are contracts between IT and the departments IT serves, and are just plain silly.
Contracts are how businesses manage relationships with their customers, so if you are to run IT as a business, this is what you must do.
Which brings up the question, what happens if you fail to live up to one of your negotiated SLAs? In business, this would result in financial penalties, withheld payments, binding arbitration, or lawsuits.
Just how stupid would a business look if Manufacturing took IT to court for failing to live up to an SLA? This isn't an easy question to answer because "stupid" isn't easily quantified, nor is there a unit of measure for it. If stupid was electricity and we measured it in volts, I'm pretty sure this would reach Taser levels.
Charge-backs, in contrast to SLAs, do have one thing going for them -- they vastly simplify IT governance. If, for example, Marketing wants to re-plumb the company website with a content management system (CMS), you have no worries. Marketing signs up for the cost and charge-backs give you the budget you need. You hire staff, engage contractors or bring in a systems integrator and everybody is happy.
Not really. What really happens is that your staff based its CMS recommendation on what would integrate best with the rest of your technical architecture, scale without major reconfiguration, and allow granular administration to avoid opening interesting holes in your information security.
The Marketing Director, being a prudent steward of her departmental budget, obtains three competitive bids. All are lower than your estimate.
Of course they are. Because your staff failed to run IT like a business. They are running IT like a department, responsible for managing the company's information assets. And so you lose the Marketing Department's business to a competitor.
It isn't the Marketing Director's fault. IT isn't alone in this nonsense. If IT is to be run as a business, so is every other shared service department in the enterprise, Marketing included. Marketing doesn't want to lose the Dental Accessories business unit's account to an outside agency, so it has to keep its costs as low as possible.
And the race to the bottom continues.
CEOs who organize the enterprise so its shared services departments act as independent businesses have forgotten a basic engineering principle ... that optimizing the parts sub-optimizes the whole and vice versa ("Optimizing the organization Keep the Joint Running 10/27/2003).
Specifically, the company's shared services organizations, when run as businesses, lose their authority to preserve the integrity of essential resources. In the case of IT it's the information architecture. In the case of Marketing it's the corporate image and the meaning of the brand. In the case of Human Resources it's the policies that protect employees from bad managers while allowing managers to deal with non-performing employees without the risk of ending up in court.
And so on.
No question, the idea is seductive. CEOs, for understandable reasons, are likely to have a strong faith in the power of markets to regulate themselves efficiently without the need for outside controls or guidance. That being the case, turning the enterprise into a marketplace sure seems easier than the hard work of instituting the governance processes, difficult choices and consensus building that are otherwise required. As is so often the case, trying to avoid hard work doesn't lead to brilliant results.
Marketplaces don't require all of this because they don't have a purpose. They are simply spaces where entities that do have purpose interact in complex ways.
Companies have a purpose. Marketplaces don't. Turning a company into a marketplace misses this essential difference.
In the end, running IT as a business ... and the enterprise as a marketplace ... is an attempt to avoid the need for governance processes, difficult choices and consensus building.
Another name for these activities is leadership. Done right it's hard work.
-----------------
Copyright and other stuff -- The great KJR link point
Tuesday, January 22, 2008
Running IT like a whatchamacallit
1/21/2008
CIOs are, according to many in the business punditocracy, supposed to run IT as a business. Yet in spite of all of the ink smeared on crushed trees advocating this thought process (not to mention the miniscule magnetic domains that have given up their freedom to store it) I've yet to see anyone define what they mean by "business."
It might seem too obvious to bother with. We all know what a business is, don't we?
That's the problem with this sort of thing: We all do know what a business is, only we don't all know what one is in the same way. Depending on the situation and who is doing the talking, businesses can be:
When a CIO is supposed to run IT as a business, which definitions are supposed to be part of the formula?
Certainly not Definition #1. If you work in IT you might like it, as it makes Definition #7 a more enduring possibility. But even ignoring the pundits who also recommend disbanding internal IT in favor of outsourcing, self-perpetuation isn't something you can sell to a board of directors.
Which also means you can scratch Definition #7 off the list.
Definition #2 is a certainty. In its simplest form, IT's mission is to provide working information technology to the business. This, or something like it, is IT's mission whether you run it as a business, a department, or a hobby, so scratch Definition #2 off the list as well. The same logic applies to Definitions #6, #8 and #9.
Definition #3 is a distinct possibility. Never mind a mission. A Definition #3 IT business would deliver products and services to internal customers in exchange for money, through the magic of transfer pricing (the practice formerly known as charge-backs).
Except that it doesn't work that way. When companies engage in transfer pricing they put controls in place to make sure internal departments break even exactly. If they didn't, the business as a whole would be an ecology (Definition #5, as are most companies that engage in transfer pricing anyway). Scratch this one off, too, and Definition #4 for the same reason.
Definition #5 is a good representation of a marketplace as well as a jungle, and in fact, marketplaces are near-perfect parallels to ecologies. It's bad enough when a CEO turns a whole enterprise into an ecology. Another description of this sort of environment is "political quagmire." One presumes "run IT as a political quagmire" isn't what the pundits have in mind.
Definitions #10 and #11 make no sense either. It might be fun to sell shares in IT to various business executives and might even lead to beneficial results, in much the way the Green Bay Packers benefit from having 125,000 fans as the shareholders who collectively own the team.
Somehow I just don't see it working very well in practice.
So there you have it. Eleven different definitions of "business" and not one of them makes any sense for IT. Which leads to a question: If IT isn't a business by any reasonable definition of the term, what might it mean to run it like one?
I'm left without an answer, and with only one possible conclusion -- that I don't know what the pundits are talking about.
I suspect that's something they and I have in common.
CIOs are, according to many in the business punditocracy, supposed to run IT as a business. Yet in spite of all of the ink smeared on crushed trees advocating this thought process (not to mention the miniscule magnetic domains that have given up their freedom to store it) I've yet to see anyone define what they mean by "business."
It might seem too obvious to bother with. We all know what a business is, don't we?
That's the problem with this sort of thing: We all do know what a business is, only we don't all know what one is in the same way. Depending on the situation and who is doing the talking, businesses can be:
- Non-human, amoral organisms that have an existence independent of the people who make them up, and which, like any other organisms, consider self-perpetuation their first and most important goal.
- Mission-driven entities that exist to provide goods and services that have value to someone.
- Product generators that exist to deliver items for which customers will pay more money than was needed to provide them.
- Profit generators that exist to deliver a stream of money to their actively-involved owners.
- Ecologies -- environments in which individuals compete, and sometimes collaborate to obtain resources.
- Assemblages of processes that connect to transform inputs into outputs.
- Places of employment that exchange work assignments for money and non-cash compensation.
- Social fabrics that provide a space for people to interact and form connections.
- Personal "force multipliers" that increase an individual's ability to achieve goals.
- Opportunities for investment, to deliver a lump of cash to a passively involved shareholder.
- Commodities to be bought, sold, aggregated or dispersed for profit.
When a CIO is supposed to run IT as a business, which definitions are supposed to be part of the formula?
Certainly not Definition #1. If you work in IT you might like it, as it makes Definition #7 a more enduring possibility. But even ignoring the pundits who also recommend disbanding internal IT in favor of outsourcing, self-perpetuation isn't something you can sell to a board of directors.
Which also means you can scratch Definition #7 off the list.
Definition #2 is a certainty. In its simplest form, IT's mission is to provide working information technology to the business. This, or something like it, is IT's mission whether you run it as a business, a department, or a hobby, so scratch Definition #2 off the list as well. The same logic applies to Definitions #6, #8 and #9.
Definition #3 is a distinct possibility. Never mind a mission. A Definition #3 IT business would deliver products and services to internal customers in exchange for money, through the magic of transfer pricing (the practice formerly known as charge-backs).
Except that it doesn't work that way. When companies engage in transfer pricing they put controls in place to make sure internal departments break even exactly. If they didn't, the business as a whole would be an ecology (Definition #5, as are most companies that engage in transfer pricing anyway). Scratch this one off, too, and Definition #4 for the same reason.
Definition #5 is a good representation of a marketplace as well as a jungle, and in fact, marketplaces are near-perfect parallels to ecologies. It's bad enough when a CEO turns a whole enterprise into an ecology. Another description of this sort of environment is "political quagmire." One presumes "run IT as a political quagmire" isn't what the pundits have in mind.
Definitions #10 and #11 make no sense either. It might be fun to sell shares in IT to various business executives and might even lead to beneficial results, in much the way the Green Bay Packers benefit from having 125,000 fans as the shareholders who collectively own the team.
Somehow I just don't see it working very well in practice.
So there you have it. Eleven different definitions of "business" and not one of them makes any sense for IT. Which leads to a question: If IT isn't a business by any reasonable definition of the term, what might it mean to run it like one?
I'm left without an answer, and with only one possible conclusion -- that I don't know what the pundits are talking about.
I suspect that's something they and I have in common.
-----------------
Copyright and other stuff -- The great KJR link point
Sunday, January 20, 2008
Tuesday, January 15, 2008
The connection between leadership and process in IT
1/14/2008
Business is the land of the panacea, and IT is its capital. Sensible people ... people who would never ask, "What do you think -- should I take tetracycline, Vitamin D, or have surgery?" before undergoing the minor inconvenience of a medical diagnosis to determine (a) if they are ill; and (b) if so, with what ... ask whether they should undertake CMM, ITIL or COBiT without first having any idea of what is and isn't working well.
Let's dispose of something right now: Ignore CMM (the Software Engineering Institute's Capability Maturity Model).
That, more or less, is the advice given by Capers Jones, one of CMM's strongest advocates.
CMM is waterfall application development methodology taken off a cliff. (Come to think of it, waterfalls always go off a cliff, by definition. Oh, never mind.) Had everyone followed CMM, the World Wide Web would never have happened. By the time the first few thousand websites had been deployed ... with maybe one tenth the content and functionality of the ones that actually happened ... everyone would have lost interest.
According to Capers Jones, CMM is essential for just about any run-of-the-mill IT shop that employs more than 1,000 developers and undertakes 10,000+ function point projects. He has solid evidence that this is the case.
So if you lead more than a thousand developers, it's just barely possible that you really do need CMM. Probably not, though, because even if you do, you rarely have a reason to charter a 10,000+ function point development project, for two reasons.
The first: You're almost always better off chunking your projects down into a succession of small projects instead. Risk goes down, success is more reliable, and business value happens faster. And, (he said, never passing up an opportunity to plug his books and seminars) you can employ the Bare Bones methodology instead of something bulkier.
The second: Most business IT groups spend the majority of their applications effort integrating, configuring, maintaining and upgrading commercial software packages rather than developing from scratch. The square peg of development methodologies has limited relevance when it comes to the round hole of integration and configuration, despite decades of attempts to pound one into the other.
But I digress.
Four major factors determine the success of any IT organization: Business alignment, process maturity, technical architecture, and human performance.
Which of the four is most important? Human performance, without a doubt. As mentioned here in recent columns, the proof is easy, and geometrical in its rigor: Great employees routinely overcome bad or non-existent process, ineffective leadership and governance, and messy technical architecture. Bad employees just as routinely cause even the best process designs to fail while turning elegant architecture into a tangle of spaghetti, and efficient governance into meaningless committee meetings as projects become eternal.
Bad employees don't routinely fail in the face of excellent leadership for the simple reason that excellent leaders hire bad employees less often, and when they do either coach them to success, reassign them to more suitable roles, or terminate them. Strong leaders don't tolerate weak employees.
That doesn't stop us (us being IT Catalysts, my consulting company) from advising clients on how to make their processes more effective. Far from it. One of the questions we often ask struggling managers is how (but really whether) they know if the processes they're responsible for are healthy.
Am I speaking out of both sides of my mouth?
Not at all. Here's the distinction: Effective leaders place their emphasis on people. Effective managers insist on delivery, and recognize the importance of process in achieving that end.
If you are responsible for a business function you have to be effective at both leadership and management, and they aren't independent topics.
Effective management depends on effective leadership for all the reasons enumerated here over the past few weeks and summarized above: Effective leadership puts motivated employees with the right skills, attitude and focus in the right roles, allowing processes to be effective.
Effective leadership is equally dependent on effective management, although the reason is more subtle: Because effective managers know how to monitor and manage processes, they can know what's going on without having to micromanage.
One other reason for the dependency: If you are in charge of a business function, you have to know how to manage first, because results ... process outputs ... are what you're paid for.
Fail to deliver them and your own manager might insist you spend less time leading and more time closely supervising the work.
Business is the land of the panacea, and IT is its capital. Sensible people ... people who would never ask, "What do you think -- should I take tetracycline, Vitamin D, or have surgery?" before undergoing the minor inconvenience of a medical diagnosis to determine (a) if they are ill; and (b) if so, with what ... ask whether they should undertake CMM, ITIL or COBiT without first having any idea of what is and isn't working well.
Let's dispose of something right now: Ignore CMM (the Software Engineering Institute's Capability Maturity Model).
That, more or less, is the advice given by Capers Jones, one of CMM's strongest advocates.
CMM is waterfall application development methodology taken off a cliff. (Come to think of it, waterfalls always go off a cliff, by definition. Oh, never mind.) Had everyone followed CMM, the World Wide Web would never have happened. By the time the first few thousand websites had been deployed ... with maybe one tenth the content and functionality of the ones that actually happened ... everyone would have lost interest.
According to Capers Jones, CMM is essential for just about any run-of-the-mill IT shop that employs more than 1,000 developers and undertakes 10,000+ function point projects. He has solid evidence that this is the case.
So if you lead more than a thousand developers, it's just barely possible that you really do need CMM. Probably not, though, because even if you do, you rarely have a reason to charter a 10,000+ function point development project, for two reasons.
The first: You're almost always better off chunking your projects down into a succession of small projects instead. Risk goes down, success is more reliable, and business value happens faster. And, (he said, never passing up an opportunity to plug his books and seminars) you can employ the Bare Bones methodology instead of something bulkier.
The second: Most business IT groups spend the majority of their applications effort integrating, configuring, maintaining and upgrading commercial software packages rather than developing from scratch. The square peg of development methodologies has limited relevance when it comes to the round hole of integration and configuration, despite decades of attempts to pound one into the other.
But I digress.
Four major factors determine the success of any IT organization: Business alignment, process maturity, technical architecture, and human performance.
Which of the four is most important? Human performance, without a doubt. As mentioned here in recent columns, the proof is easy, and geometrical in its rigor: Great employees routinely overcome bad or non-existent process, ineffective leadership and governance, and messy technical architecture. Bad employees just as routinely cause even the best process designs to fail while turning elegant architecture into a tangle of spaghetti, and efficient governance into meaningless committee meetings as projects become eternal.
Bad employees don't routinely fail in the face of excellent leadership for the simple reason that excellent leaders hire bad employees less often, and when they do either coach them to success, reassign them to more suitable roles, or terminate them. Strong leaders don't tolerate weak employees.
That doesn't stop us (us being IT Catalysts, my consulting company) from advising clients on how to make their processes more effective. Far from it. One of the questions we often ask struggling managers is how (but really whether) they know if the processes they're responsible for are healthy.
Am I speaking out of both sides of my mouth?
Not at all. Here's the distinction: Effective leaders place their emphasis on people. Effective managers insist on delivery, and recognize the importance of process in achieving that end.
If you are responsible for a business function you have to be effective at both leadership and management, and they aren't independent topics.
Effective management depends on effective leadership for all the reasons enumerated here over the past few weeks and summarized above: Effective leadership puts motivated employees with the right skills, attitude and focus in the right roles, allowing processes to be effective.
Effective leadership is equally dependent on effective management, although the reason is more subtle: Because effective managers know how to monitor and manage processes, they can know what's going on without having to micromanage.
One other reason for the dependency: If you are in charge of a business function, you have to know how to manage first, because results ... process outputs ... are what you're paid for.
Fail to deliver them and your own manager might insist you spend less time leading and more time closely supervising the work.
-----------------
Copyright and other stuff -- The great KJR link point
Monday, January 14, 2008
Tuesday, January 8, 2008
A contrarian view of process
1/7/2008
Process has dominated the consulting world, at least since Michael Hammer and James Champy published Reengineering the Corporation in 1994.
Keep the Joint Running and its InfoWorld predecessor, Survival Guide, have been contrarian about process for nearly as long.
The process perspective isn't wrong. It is, however, subordinate to other, more important perspectives. As evidence:
Process has dominated the consulting world, at least since Michael Hammer and James Champy published Reengineering the Corporation in 1994.
Keep the Joint Running and its InfoWorld predecessor, Survival Guide, have been contrarian about process for nearly as long.
The process perspective isn't wrong. It is, however, subordinate to other, more important perspectives. As evidence:
- Jim Collins' Good to Great (2001) isolated five factors common to the high-performance companies he and his team analyzed. Process improvement or reengineering initiatives weren't among them. High-quality leadership, a culture of discipline, and strategic focus were.
- William Joyce, Nitin Nohria, and Bruce Roberson published the results of their "Evergreen Project" in What Really Works (2004). Their formulation is a bit more complicated than Collins', but similar in most respects. Their evidence was, if anything, more compelling.
Over the ten years examined in the study, companies that followed the "formula" increased sales by 415 percent and operating income by 326 percent. Companies that didn't increased sales by just 83 percent and operating income by 22 percent. - Regular correspondent Noah Wollner pointed me to an older study by John Kotter and James Heskitt. Titled Corporate Culture and Performance (1992), it contrasted companies that fostered a "performance enhancing culture" with others that didn't. Defined as promoting risk taking and innovation, being receptive to change, valuing entrepreneurship, and encouraging mutual support in identifying and solving problems, the impact was, to say the least, significant:
Over an eleven year span, organizations with performance-enhancing cultures experienced 682 percent revenue growth and 746 percent net income growth. Those that didn't grew revenue by only 166 percent and net income by just 1 percent over the same period of time. - And, as mentioned [in] my last column, every time anyone looks at what drives customer satisfaction, employee attitude is the most important underlying factor.
So far as I can tell, there is no reliable published evidence, other than the anecdotal, that process change is a primary driver of business success.
Does this mean process has no value in a modern corporation? That would be a false inference. The question isn't whether process matters. The question is how it matters.
Those who view companies as collections of processes end up looking at companies as mechanisms -- collections of gears, cogs, buttons, and wheels. From this perspective, employees occupy some but not all roles in a process. Done right, everyone is replaceable, and when replaced, nothing changes.
Those who view companies as collections of people end up in a different place. For us, businesses are, first and foremost, societies. While not the lead story, process still has important roles to play.
First, process encourages consistency where consistency matters -- usually when the company has to produce a large number of very similar items; sometimes when failing to undertake work in a very specific way can lead to dangerous situations or legal liability.
Second, having well-defined processes lets employees focus on getting work done instead of on figuring out how to do it. Just as important, well-defined processes (and procedures) make collaboration easier because everyone involved shares a common understanding of how we do things around here.
And finally, well-defined processes create a framework for constant, steady improvement ("continuous improvement" is the now-cliched, preferred buzz-phrase). Without a well-defined process to provide a baseline, the enterprise has to constantly start over -- the getting-work-done equivalent of software that never progresses beyond the alpha-testing release.
In human-centered enterprises, process also has clear boundaries. The most important is this: Everyone understands that the business exists to take care of customers; that taking care of customers is something employees do; and that employees rely on trustworthy processes to help them do it, when the processes fit the situation.
When a company's processes don't fit the situation, the company has to make a choice. It can, with complete validity, decide that what the customer wants isn't something the company does. If you run a travel agency and a customer wants you to replace a broken axle in the family minivan, "Sorry but we don't do that," is a reasonable response.
"We haven't done that before, but we'll figure out a way to do it for you," is often an even more reasonable response: The company can decide that when its standard processes don't fit a customer's request, the customer has just revealed an opportunity, or something that should be fixed.
Companies that only do what they do eventually do too much of what customers don't need any more. Those that figure out how to handle unexpected requests, on the other hand, sometimes find whole new profitable lines of business in the process.
As it were.
-----------------
Copyright and other stuff -- The great KJR link point
Subscribe to:
Posts (Atom)