Comments from OMB's Chief Architect: Kshemendra Paul
"I was online and came across your site -
http://usercentricea.blogspot.com/2007/08/system-development-life-cycle-and.html.
I had two comments I wanted to share. First, I would recommend you highlight a business case step, a formal decision to move out of select/conceptual planning and into control. While this is implied, it is such a crucial step and we don't do it well - meaning that we don't force programs to work through all of the kinks in terms of putting forward a real business case (tied to strong performance architecture).
Also, this is a step that is inevitably cross boundary - either on the mission side and for sure on the funding side.
Second, I'd like to see more emphasis on smaller scale rollout or piloting. The goal of which is to prove the original business case in a limited setting. Nothing goes as planned, so another objective is to have real world data to refine the over all plan."
I completely agree with Kshemendra on the need to develop business cases and do them well for all new initiatives.
Organizations, all too often, in their zeal to get out new technologies, either skip this step altogether or do it as a "paper" (i.e. compliance) exercise. Symbolic, but wholly without intent to do due diligence and thus, without any genuine value.
Therefore, whenever we plan for new IT, we must ensure strategic business alignment, return on investment, and risk mitigation by developing and properly vetting business cases through the Enterprise Architecture and Investment Review Boards.
It's great to want to move quickly, get ahead of the pack, and gain competitive advantage by deploying new technologies quickly, but we risk doing more harm than good, by acting rashly and without adequately thinking through and documenting the proposed investment, and vetting it with the breadth and depth of organizational leadership and subject matter experts.
Secondly, as to Kshemendra's point on doing pilots to prove out the business case. This is an important part of proofing new ideas and technologies, before fully committing and investing. It's a critical element in protecting the enterprise from errant IT investments in unproven technologies, immature business plans, and the lack of ability to execute.
Pilots should be incorporated along with concept of operations, proof of concepts, and prototypes in rolling out new IT. (See my blog http://usercentricea.blogspot.com/2007/08/conops-proof-of-concepts-prototypes.html)
With both business cases and pilots for new IT projects, it's a clear case of "look before you leap." This is good business and good IT!
MSNBC on the ATF and Enterprise Architecture
Visit msnbc.com for Breaking News, World News, and News about the Economy
Al Roker: "Armed in America"--The ATF in Action:
Enterprise architecture has to live in the real world, and in the real world a technology is any tool that gets the job done. Instead of being driven only by whiz-bang technologies, we need to focus on what works for the mission. And while this certainly includes traditional information technology, it also must take into account people, training, intel, equipment, and so forth. In this video from MSNBC, we see a focus on the mission of the ATF, and this is certainly part of any business architecture for an organization. Architecture information products do not only take the form of inventories of items, models of processes, and charts of intricate detail, but they can also take the form of video, audio, and other such artificats that documentan an organization and the way it performs.
Engineering Employee Productivity and Enterprise Architecture
The Wall Street Journal, 17 November 2008, reports that “Stores Count Seconds to Trim Labor Costs.”
Companies “break down tasks such as working a cash register into quantifiable units and devise standard times to complete them, called ‘engineered labor standards.’ Then it writes software to help clients keep watch over employees.”
So for example, in some retailers, “A clock starts ticking the instant he scans a customer’s first item, and it doesn’t shut off until his register spits out a receipt.”
Employees who don’t meet performance standards (e.g. they fall below 95%), get called into for counseling, training, and “various alternatives” (i.e. firing).
The result is “everybody is under stress.”
So, is this workforce optimization or micromanagement? Is this helping employees learn do a better job or is this just scare tactics geting them under the management whip?
Some employers are claiming improved productivity and cost savings:
One retailer, for example, claims saving $15,000 in labor costs across 34 stores for every one second shaved from the checkout process.
But others are finding that customer service and employee morale is suffering:
Check clerks are not as friendly. They don’t chat with customers during checkout. Cashiers “avoid eye contact with shoppers and generally hurry along older or infirm customers who might take longer to unload carts and count money.”
Additionally, as another cashier put it, “when you’re afraid you’re going to lose your job, you make more mistakes.”
Other employees are gaming the system to circumvent the rigid performance measures and for example, improving their time by hitting the suspend button to stop the clock more than they are supposed to—it is meant only for use when remotely scanning bulky merchandise.
The other problem with the engineered labor standards is that they often don’t take into account the “x factors”—the things that can go wrong that adversely affect your performance times. Some examples: customers who don’t have enough cash or those “digging through a purse,” credit cards that don’t swipe, “an item with no price or item number,” customers who forget something and go back or those that ask for an item located at the other end of the store.
It seems obvious that while we need to measure performance, we need to make sure that we measure that right things and in the right way.
What good is measuring pure speed of transactions to “boost efficiency” if at the same time we
- alienate our customers with poor service or
- harm employee morale, integrity and retention with exacting, inflexible, and onerous measurements?
Like all sound enterprise architecture efforts, we need to make sure that they are reasonable, balanced, and take into account not just technology, but people, and process.
In this case, we need to ensure the process is customer service driven and the employees are treated fairly and humanly. Without these, the productivity savings of engineered labor standards will be more than offset over time by the negative effects to our customers and employees.
A Productivity Boost and Enterprise Architecture
You would think with all these tools for managing information, our lives would be simpler, more straightforward, and ever more carefree. Isn’t that what “tools” are supposed to do for people?
Well, think about your own life. Is your life less hectic with all the IT tools? Do you have more time to focus on what you’re working on? How’s your work-life balance?
If you are like most people these days, the answer is likely that you are more frantic and are trying to more things at the same time than ever before—almost driving yourself crazy, at times, to keep up.
The Wall Street Journal, 15 December 2008 had a book review by Christopher Chabris on “The Overflowing Brain.”
Here’s an excerpt of the review that I believes tells the story well:
“Take a look at your computer screen and the surface of your desk. A lot is going on. Right now, I count 10 running programs with 13 windows on my iMac, plus seven notes or documents on my computer desk and innumerable paper piles, folders, and books on my ‘main’ desk, which serves primarily as overflow space. My 13 computer windows include four for my internet browsers, itself showing tabs for 15 separate Web pages. The task in progress, in addition to writing this review…include monitoring three email accounts, keeping up with my Facebook friends, figuring out how to wire money into one of my bank accounts, digging into several scientific articles about genes, checking the weather in the city I will be visiting next week and reading various blogs, some which are actually work-related. And this is at home. At the office, my efforts to juggle these tasks would be further burdened by meetings to attend, conference calls to join, classes to teach, and co-workers to see. And there is still the telephone call or two—one of my three phone lines (home, office, mobile).”
Does this ring a bell for anybody? Dare I say that this is the reality for more of us these days.
So has IT (and the CIOs of our time) succeeded in giving us the technologies we need and want?
Well let’s look at what we said earlier were goals of IT—communication, information, commerce, entertainment, and productivity. Yep, we sure have all of these—big time!
Great, let’s just stop here at the outputs of technology and claim victory for our CIOs and the society we’ve created for ourselves.
But wait, what about the simpler, straightforward, and carefree parts—the anticipated outcomes, for many, of IT—shouldn’t we all be breathing a little easier with all the technology tools and new capabilities we have?
Ah, here’s the disconnect: somehow the desired outputs are NOT leading to the outcomes many people had hoped for.
One possible answer is that we really don’t want simple and carefree. Rather, in line with the ‘alpha male theory,’ we are high achievers, competitive, and some would even say greedy. And all the IT in the world just pours oil on our fire for doing and wanting more, more, more.
As many of us take some time off for the holidays and put our feet up for a week or two, we realize how much we look forward to some peace and quiet from all the helpful technology that surrounds us every day. But at the end of a few weeks, most of us are ready to go back to work and go crazy again with all our technology-driven productivity.
On a more serious note, from an enterprise architecture perspective, one has to ask if all this running around is leading to a strategic, desirable result in our personal and professional lives or is it just business for business sake, like technology for technology sake.
Chief Interaction Officer -- Architecting Social Networking
Appreciate any comments.
GM and Enterprise Architecture
THEN: In 1954, GM’s U.S. auto market share reached 54%; in 1979, their number of worldwide employees hit 853,000, and in 1984 earning peak at $5.4 billion.
NOW: In 2007, U.S. market share stands at 23.7% and GM loses $38.7 billion; by 2008 employment is down to 266,000.
(Associated Press, “A Brief History of General Motors Corp., September 14, 2008)
Fortune Magazine, 8 December 2008, reports that “It was a great American Company when I started covering it three decades ago. But by clinging to the attributes that made it an icon, General Motors drove itself to ruin.”
GM clung to its past and “drove itself to ruin”—they weren’t nimble (maybe due to their size, but mostly due to their culture). In the end, GM was not able to architect a way ahead—they were unable to change from what they were (their baseline) to what they needed to be (their target).
“But in working for the largest company in the industry for so long, they became comfortable, insular, self-referential, and too wedded to the status quo—traits that persist even now, when GM is on the precipice.”
The result of their stasis—their inability to plan for change and implement change—“GM has been losing market share in the U.S. since the 1960’s destroying capital for years, and returning no share price appreciation to investors.”
GM’s share price is now the lowest in 58 years.
When the CEO of GM, Rick Wagoner, is asked why GM isn’t more like Toyota (the most successful auto company is the world with a market cap of $103.6 billion to GM’s $1.8 billion), his reply?
“We’re playing our own game—taking advantage of our own unique heritage and strengths.”
Yes, GM is playing their own game and living in their own unique heritage. “Heritage” instead of vision. “Playing their own game” instead of effectively competing in the global market—all the opposite of enterprise architecture!!
GM has been asphyxiated by their stubbornness, arrogance, resistance to change and finally their high costs.
“ GM’s high fixed costs…no cap on cost-of-living adjustments to wages, full retirement after 30 years regardless of age, and increases in already lavish health benefits. Detroiters referred to the company as ‘Generous Motors.’ The cost of these benefits would bedevil GM for the next 35 years.”
GM’s cost structure has been over-the-top and even though they have been in “perpetual turnaround,” they have unable to change their profligate business model.
Too many models, too many look-alike cars, and too high a cost structure—GM “has lost more than $72 billion in the past four years” and the result is? Are heads rolling?
The article says no—“you can count on one hand the number of executives who have been reassigned or lost their jobs”
“At GM, conformity was everything, and rebellion was frowned on.” Obviously, this is not a successful enterprise architecture strategy.
Frankly, I cannot understand GM’s intransience to create a true vision and lead. Or if they couldn’t innovate, why not at least imitate their Japanese market leader brethren?
It’s reminds me of the story of the Exodus from Egypt in the bible. Moses goes to Pharaoh time and again and implores him to “let my people go” and even after G-d smites the Egyptians with plague after plague, he is still unmovable.
Well we know how that story ended up for the Egyptians and it doesn’t bode well for GM.
The bottom line, if the enterprise isn’t open to genuine growth and change, nothing can save them from themselves.
User-Centric Enterprise Architecture on YouTube
http://www.youtube.com/watch?v=SkRgh8mjbpM
Enjoy and I appreciate your (constructive) comments.


