The Doomsday Machine is Real

There is a fascinating article in Wired (Oct. 2009) on a Doomsday Machine called “the Perimeter System” created by the Soviets. If anyone tries to attack them with a debilitating first strike, the doomsday machine will take over and make sure that the adversary is decimated in return.

“Even if the US crippled the USSR with a surprise attack, the Soviets could still hit back. It wouldn’t matter if the US blew up the Kremlin, took out the defense ministry, severed the communications network, and killed everyone with stars on their shoulders. Ground-based sensors would detect that a devastating blow had been struck and a counterattack would be launched.”

The Doomsday machine has supposedly been online since 1985, shortly after President Reagan proposed the Strategic Defense Initiative (SDI or “Star Wars”) in 1983. SDI was to shield the US from nuclear attack with space lasers (missile defense). “Star Wars would nullify the long-standing doctrine of mutually assured destruction.”

The logic of the Soviet’s Doomsday Machine was “you either launch first or convince the enemy that you can strike back even if you’re dead.”

The Soviet’s system “is designed to lie dormant until switched on by a high official in a crisis. Then it would begin monitoring a network of seismic, radiation, and air pressure sensors for signs of nuclear explosion.”

Perimeter had checks and balances to hopefully prevent a mistaken launch. There were four if/then propositions that had to be meet before a launch.

Is it turned on?

Yes then…

Had a nuclear weapon hit Soviet soil?

Yes, then…

Was there still communications links to the Soviet General Staff?

No, then launch authority is transfered to whoever is left in protected bunkers

Will they press the button?

Yes, then devastating nuclear retaliation!

The Perimeter System is the realization of the long-dreaded reality of machines taking over war.

The US never implemented this type of system for fear of “accidents and the one mistake that could end it all.”

“Instead, airborne American crews with the capacity and authority to launch retaliatory strikes were kept aloft throughout the Cold War.” This system relied more on people than on autonomous decision-making by machines.

To me, the Doomsday Machine brings the question of automation and computerization to the ultimate precipice of how far we are willing to go with technology. How much confidence do we have in computers to do what they are supposed to do, and also how much confidence do we have in people to program the computers correctly and with enough failsafe abilities not to make a mistake?

On one hand, automating decision-making can help prevent errors, such as a mistaken retaliatory missile launch to nothing more than a flock of geese or malfunctioning radar. On the other hand, with the Soviet’s Perimeter System, once activated, it put the entire launch sequence in the hands of a machine, up until the final push a button by a low-level duty station officer, who has a authority transferred to him/her and who is perhaps misinformed and blinded by fear, anger, and the urge to revenge the motherland in a 15 minute decision cycle—do or die.

The question of faith in technology is not going away. It is only going to get increasingly dire as we continue down the road of computerization, automation, robotics, and artificial intelligence. Are we safer with or without the technology?

There seems to be no going back—the technology genie is out of the bottle.

Further, desperate nations will take desperate measures to protect themselves and companies hungry for profits will continue to innovate and drive further technological advancement, including semi-autonomous and perhaps, even fully autonomous decision-making.

As we continue to advance technologically, we must do so with astute planning, sound governance, thorough quality assurance and testing, and always revisiting the technology ethics of what we are embarking on and where we are headed.

It is up to us to make sure that we take the precautions to foolproof these devices or else we will face the final consequences of our technological prowess.

The Doomsday Machine is Real

Creating Win-Win and Enterprise Architecture

We are all familiar with conflict management and day-to-day negotiations in our everyday leadership role in our organizations, and the key to successful negotiation is creating win-win situations.

In the national bestseller, Getting to Yes, by Fisher and Ury, the authors call out the importance of everyday negotiation and proposes a new type of negotiation called "principled negotiation".

“Everyone negotiates something every day…negotiation is a basic means of getting what you want from others. It is a back-and-forth communciation designed to reach an agreement when you and the other side have some interests that are shared and others that are opposed. More and more occasions require negotiation. Conflict is a growth industry…whether in business, government, or the family, people reach most decisions through negotiation.”

There are two standard ways to negotiate that involve trading off between getting what you want and getting along with people:

Soft—“the soft negotiator wants to avoid personal conflict and so makes concessions readily in order to reach agreement. He wants an amicable resolution yet he often ends up exploited and feeling bitter.”

Hard—“the hard negotiator sees any situation as a contest of wills in which the side that takes more extreme positions and holds out londer fares better. He want to win yet he often ends up producing an equally hard response which exhausts him and his resources and harms his relationship with the other side.”

The third way to negotiate, developed by the Harvard Negotiation Project, is Principled Negotiation.

Principled Negotiation—“neither hard nor soft, but rather both hard and soft…decide issues on their merits rather than through a haggling process…you look for mutual gains wherever possible, and that where your interests conflict, you should insist that the results be based on some fair standards independent of the will of either side.”

In principled negotiation, the method is based on the following:

1. People—participants are not friends and not adversaries, but rather problem solvers
2. Goal—the goal is not agreement or victory, but rather a “wise outcome reached efficiently and amicably”
3. Stance—your stance is “soft on the people, hard on the problem”
4. Pressure—you don’t yield or apply pressure, but rather “reason and be open to reasons”
5. Position—you don’t change your position easily or dig in, but rather you “focus on interests, not positions”
6. Solution—the optimal solution is win-win; you develop “options for mutual gain”

In User-centric EA, there are many situations that involve negotiation, and using principled negotiation to develop win-win solutions for the participants is critical for developing wise solutions and sustaining important personal relationships.

• Building and maintaining the EA—first of all, just getting people to participate in the process of sharing information to build and maintain an EA involves negotiation. In fact, the most frequent question from those asked to participate is “what’s in it for me?” So enterprise architects must negotiate with stakeholders to share information and participate and take ownership in the EA initiative.
• Sound IT governance—second, IT governance, involves negotiating with program sponsors on business and technical alignment and compliance issues. Program sponsors and project managers may perceive enterprise architects as gatekeepers and your review board and submission forms or checklists as a hindrance or obstacle rather than as a true value-add, so negotiation is critical with these program/project managers to enlist their support and participation in the review, recommendation, and decision process and follow-up on relevant findings and recommendations from the governance board.
• Robust IT planning—third, developing an IT plan involves negotiation with business and technical partners to develop vision, mission, goals, objectives, initiatives, milestones, and measures. Everyone has a stake in the plan and negotiating the plan elements and building consensus is a delicate process.
  

In negotiating for these important EA deliverables, it’s critical to keep in mind and balance the people and the problem. Winning the points and alienating the people is not a successful long-term strategy. Similarly, keeping your associates as friends and conceding on the issues, will not get the job done. You must develop win-win solutions that solve the issues and which participants feel are objective, fair, and equitable. Therefore, using principled negotiation, being soft on people and hard on the problem is the way to go.

Creating Win-Win and Enterprise Architecture

DHS OIG Report on My User-centric EA Implementation at the Coast Guard

Just learned of new Department of Homeland Security (DHS) Office of Inspector General (OIG) Report documenting the significant progress of Enterprise Architecture and IT Governance program at the U.S. Coast Guard, which I led up to and during the majority of the audit.

I am pleased at the recognized progress and at the terrific work that my team accomplished there--I am very proud of all of them!

Of course, there is more work to be done, but the right EA infrastructure has been put in place to accomplish the goals and objectives set out.

Here is the link to the report: http://sites.google.com/site/thetotalcio/Home/links/EAOIGReport-July2009.pdf?attredirects=0

"The Coast Guard has made progress in developing its enterprise architecture by defining its enterprise architecture framework [User-centric EA] in alignment with both federal and DHS architectures. In addition, its enterprise architecture is aligned with the Coast Guard's IT strategy. These achievements have been possible because of executive support for the enterprise architecture effort."

DHS OIG Report on My User-centric EA Implementation at the Coast Guard

Andy Blumenthal Presents How Enterprise Architecture is Transforming Government (June 2009)

Check out this SlideShare Presentation:

Andy Blumenthal Presents How Enterprise Architecture is Transforming Government (June 2009)

View more Microsoft Word documents from ablumen.

Andy Blumenthal Presents How Enterprise Architecture is Transforming Government (June 2009)

Groups Can Help or Hurt the Decision Process…Here’s how

Generally, IT governance is based on the assumption that by vetting decisions in groups or boards—such as an Enterprise Architecture Board or Investment Review Board--we get better decisions. I for one have been an outspoken proponent for this and still am.

However, I read with great interest in the Wall Street Journal, April 25-26, an article entitled “How Group Decision End Up Wrong-Footed.”

In this article, an organizational psychologist at Stanford University, Robert Sutton states: “The best groups will be better than their best individual members”—okay, that’s right in line with our IT governance model, but then goes on to say…

“and the worst groups will be worse than the worst individual.”—oh uh, that’s not good…here the IT governance model seems to backfire, when the group is dysfunctional!

Here’s the explanation:

“Committees and other groups tend either to follow the leader in a rush of conformity [here’s the herd mentality taking over] or to polarize into warring groups [here’s where the members break into oppositional stovepipes jockeying for position and turf].”

In these all too common dysfunctional group scenarios, the group does not work the way it is intended to—in which members constructively offer opinions, suggestions, explanations and discuss issues and proposals from various points of view to get a better analysis than any single person in the group could on their own.

Instead, “all too often committees don’t work well at all—resulting in a relentless short-term outlook, an inability to stick to strategic plans, a slapdash pursuit of the latest fad and a tendency to blame mistakes on somebody else.”

So how do we develop groups that work effectively?

According to Richard Larrick a psychologist at Duke University, “For committees and other boards to work well, they must be made up of people with differing perspectives and experience who are unafraid to speak their minds…they must also select and process information effectively and seek to learn from their mistakes.”

In this model, people in a group can effectively balance and complement each other, and synergistically work together to make better IT decisions for the organization.

Here are some suggestions offered by the article for effective groups:

The first is to break the group into “pro” and “con” sub-groups that can develop arguments for each side of the argument. I call this the debate team model and this offsets the tendency of groups to just follow the “leader” (loudest, pushiest, most politically savvy…) member in the room, creating the herd mentality, where anybody who disagrees is branded the naysayer or obstacles to progress. To get a good decision, we need to foster a solid debate and that occurs in an environment where people feel free to explore alternate point of view and speak their minds respectfully and constructively with non-attribution and without retaliation.

The second suggestion is to ask how and why questions to “expose any weak points in the advise.” This idea was a little surprising for me to read, since I had prior learned in leadership training that it is impolite and possibly even antagonistic to ask why and that this interrogative should be avoided, practically at all costs.

In prior blogs, I have written how enterprise architecture provides the insight for decision-making and It governance provides the oversight. So I read with interest once more, that oversight has a dual meaning: “the word can mean either scrutiny or omission.” And again it clicked…when the governance board works effectively; it “scrutinizes” investments so that the organization invests wisely. However, when the group is dysfunctional the result is “omissions” of facts, analysis, and healthy vetting and decision-making. That is why we need to make our IT governance boards safe for people to really discuss and work out issues.

Groups Can Help or Hurt the Decision Process…Here’s how

To Invest or Not to Invest, That is the Question

There are scarce dollars for investment purposes and many competing alternatives to invest in. Therefore, organizations must make wise investment decisions.

Common sense dictates that we invest in those technologies that will bring us the greatest return on investment. However, investing in IT is not only about seeking to maximize profitability or superior mission execution, but also about mitigating risk.

MIT Sloan Management Review, Spring 2009, discusses the need to balance between two types of investment risks.

The first, and obvious one is financial risk—“the failure to achieve satisfactory returns from an investment;” those organizations that load up on too much financial risk, can actually put themselves in danger of not being able to stay financially solvent i.e. too many poor investments and the company can be sunk!

The second risk is competitive risk—“the failure to retain a satisfactory competitive position for lack of investment.” Organizations that are too conservative and don’t invest in the future put themselves at risk of falling behind the competition, and may be even out of the race altogether.

So how do we balance these two risks?

On one hand, we need to make critical new IT investments to stay competitive and become more effective and efficient over time, but on the other hand, we need to manage our money prudently to stay on solid financial footing.

Managing financial risk is a short-term view—similar to looking at the daily stock market prices or quarterly financial returns; if we can’t meet our financial obligations today or tomorrow, game over. While managing competitive risk is a long term perspective on investing—we need to remain agile amidst our marketplace competitors and outmaneuver them over time picking up additional customers and market share and building brand and satisfaction.

In information technology management, we must manage both the short-term financial risk and the long-term competitive risks.

What tools are in the CIO’s arsenal to manage these risks effectively?

Enterprise architecture planning is a strategic function that takes a primarily top-down view and assesses organizational requirements (including competitive needs) and drives IT investments plans to meet those needs. In this way, EA manages competitive risk.

IT governance or capital planning and investment control is a bottom-up view that helps us manage shorter-term financial risks by providing a structure and process for vetting IT investments and prioritizing those. Sound IT governance helps us limit financial risk.

So we attack the risks from both ends—from the top and from the bottom.

While we cannot entirely eliminate the risks of failed IT investments or of missing opportunities to knock the competition off its feet, we can manage these by architecting our enterprise for long-term success and by appropriately scrutinizing the selection, control and evaluation of our investments so that we safeguard our financial resources.

So the CIO can err by going too far in either direction:

So a balance needs to be maintained.

“More specifically, a balance should be maintained between errors of omission and commission.” Fail to invest and modernize the organization’s technology and you commit the error of omission. Invest overly aggressively and you commit the error of commission. “A balance must be struck between the error of pursuing too many unprofitable investment opportunities as opposed to the error of passing up too many potentially profitable ones.”

To Invest or Not to Invest, That is the Question

Why We Miss the Planning Mark

We’ve all been there asking why we missed the signs while others saw them head-on and benefited in some way. This happens with financial investments (e.g. I should’ve sold before this recent meltdown like my good buddy did), business opportunities (e.g. I should’ve opened up a chain of coffee stores like Starbucks before Howard Shultz got to it), military strategy (e.g. we should’ve seen the attacks on Pearl Harbor and 9-11 coming and been better prepared to try and stop them) and other numerous “should’ve” moments—and no I’m not talking about that” I should’ve had a V8!”

Why do we miss the signs and misread information?

Obviously, these are important questions for IT leaders, enterprise architects and IT governance pros who are often managing or developing plans for large and complex IT budgets. And where the soundness of decisions on IT investments can mean technological superiority, market leadership and profitability or failed IT projects and sinking organizational prospects.

An article in MIT Sloan Management Review, Winter 2009, provides some interesting perspective on this.

“Organizations get blindsided not so much because decision makers aren’t seeing signals, but because they jump to the most convenient or plausible conclusion, rather than fully considering other interpretations.”

Poor decision makers hone in on simple or what seems like obvious answers, because it’s easier in the short-term than perhaps working through all the facts, options, and alternative points of view to reach more precise conclusions.

Additionally, “both individual and organizational biases prevent…signals from getting through” that would aid decision making.

How do these biases happen?

SUBJECTIVITY: We subjectively listen almost exclusively to our own prejudiced selves and distort any conflicting information. The net effect is that we do not fully appreciate other possible perspectives or ways of looking at problems. We do this through:

• Filtering—We selectively perceive what we want to and block out anything that doesn’t fit what we want to or expect to see. For example, we may ignore negative information about an IT investment that we are looking to acquire.
• Distortions—Information that manages to get through our mental and emotional filters, may get rationalized away or otherwise misinterpreted. For example, we might “shift blame for a mistake we made to someone else.”
• Bolstering—Not only do we filter and distort information, but we may actually look for information to support our subjective view. For example, “we might disproportionately talk to people who already agree with us.”

GROUPTHINK: “a type of thought exhibited by group members who try to minimize conflict and reach consensus without critically testing, analyzing, and evaluating ideas.” (Wikipedia)

“In principle, groups should be better than individuals at detecting changes and responding to them. But often they are not, especially if the team in not managed well, under pressure, and careful not to rock the boat.”

Interestingly enough, many IT investment review boards, which theoretically should be helping to ensure sound IT investments, end up instead as prime examples of groupthink on steroids.

Concluding thoughts:

If we are going to make better IT decisions in the organization then we need to be honest with ourselves and with others. With ourselves, we need to acknowledge the temptation to take the simple, easy answer that is overwhelmingly directed by personal biases and instead opt for more information from all sources to get a clearer picture of reality.

Secondly, we need to be aware that domineering and politically powerful people in our organizations and on our governance boards may knowingly or inadvertently drown out debate and squash important alternate points of view.

If we do not fairly and adequately vet important decisions, then we will end up costing the enterprise dearly in terms of bad investments, failed IT projects, and talented but underutilized employees leaving for organizations where different perspectives are valued and decisions are honestly and more comprehensively vetted for the betterment of the organization.

If we shut our ears and close our eyes to other people’s important input, then we will miss the planning mark.

Why We Miss the Planning Mark

Leadership Should Integrate Spirituality and Mission

I remember learning in religious day school that people are half spiritual beings and half animal and that it was a person’s duty (or test in life) to imbue the carnal part of our existence with spirituality.

It was nice to see a book today that brought this topic home; it is called “G-d is My CEO” by Larry Julian.

The premise of the book is that “we usually want to do the right thing, but often succumb to the short-term, bottom line demands of daily business life.”

Julian states: “The bottom line had become their G-d. It was insatiable. No matter how hard they worked, it was never enough, nor would it ever be enough.”

As I see it, people have two faces (or more) and one is their weekend persona that is family and G-dly oriented and the other is the one for the rest of the week—for business—that is driven by materialism, accomplishment, and desire for personal success.

This is where the test of true leadership comes into play.

We can and must do better in our business lives by “doing the right thing regardless of the outcome” and “expanding the definition of success from making money to making a difference.”

BUT, BUT, BUT…

We’re all experts at making excuses, why we need to be successful in business, achieve results, make lots of money, get the next promotion (and the next and the next) and that “the end justifies the means; you get to the outcome regardless of how you accomplish it”!

In Information Technology, it’s no different than in any other business function. It’s a competitive environment and most of the time, people’s raw ambitions are somewhat obscured (but still operating there) and occasionally you see the worst come out in people—not working together (like system operating in stovepipes), or worse criticizing, bad-mouthing, and even back stabbing.

As a CIO or CTO, we must rise above this and lead by a different set of principles. To this end, I like the “Servant Leadership” doctrine put forward by Julian.

In short, the servant leader, leads by example and puts people first and in essence, spiritually elevates the baser ambitions of people.

The servant leader is “one who serves others, not one who uses others. He/she “serves employees so they can serve others.”

“When we [as leaders] serve others, we help them succeed” and thereby we can accomplish the mission even better than pure individual greed ever could.

WOW!

The CIO/CTO can lead people, modernize and transform the enterprise with innovation and technology, to accomplish the mission better than ever and we can do it by integrating spirituality and kindness to people into what we do every day in our working lives.

Unfortunately, IT organizations are often run not by elevating people and making them significant, but instead by running them into the ground. The mission is demanding the latest and greatest to stay competitive. The technology is changing rapidly. IT specialists are challenged to keep up with training on new hardware, programming languages, systems development and project management techniques, best practice frameworks, and so forth, The Help Desk and Desktop support people are routinely yelled at by the customers. Security and privacy issues are a constant threat to operations. IT is denigrated as a support function, whose people don’t understand the business; IT is viewed as a utility and it’s people often pushed out for outsourcing.

Truly, in this type of demanding and challenging environment, it is tough for any IT organization and its people to maintain their dignity and spirituality. But that is precisely where the CIO/CTO must lead and demonstrate humanity and care for people. The true IT leader will impose structures to create order out of chaos and in so doing elevate people as the critical asset they truly are to the organization.

Here’s some ways we can do this:

1. Treat all employees with respect and dignity by representing their interests in the organization, as well as abiding by at the very least minimal standards of professionalism and courtesy
2. Partner with the business so that it’s not us versus them, but just one big US.
3. Develop a meaningful architecture plan and sound IT governance so everyone understands the way ahead and is working off the “same sheet of music.”
4. Manage business expectations—don’t overpromise and under deliver, which leads to frustration and anger; instead set challenging but attainable goals.
5. Filter requirements through a “single belly button” of seasoned business liaisons, so that the rank and file employees aren’t mistreated for doing their sincere best.
6. Provide training and tools for people to do their jobs and stay current and understand not only the technology, but the business.

Through these and other servant leader examples, we can integrate our spiritual and material lives and be the types of leaders that not only deliver, but that we can really be proud to be.

Leadership Should Integrate Spirituality and Mission

Bridging the Business and IT Divide

Leadership is all about people. In the simplest terms, you can’t be a leader without followers. And to inspire and motivate people to follow, you need a clear vision and the ability to articulate it. Moreover, leaders need to be professionally and technically competent; they need to understand their industry and the competitive environment, and be able to effectively engage decision makers, subject matter experts, and employees across the enterprise and stakeholders outside of it.

For a CIO, leadership can be even more challenging because of the balance needed between the business and technical aspects of job and the need to communicate to those two communities in their respective languages and to be able to translate between them. Often, sitting in meetings I see the best intentioned IT folks often talking techie “right past” their business counterparts and the business folks discussing mission to IT people who may never have been outside the confines of the IT environment.

As the CIO, it’s key to bridge the divide and help the business and IT communities in the organization work together and learn to speak and understand each other. Only this way, can the IT folks understand the business requirements and the business folks understand the technical solutions being proposed.

To accomplish this, the CIO should have the business and IT people work together in integrated project teams (IPT’s), tiger teams, task forces, and so on to accomplish IT projects, rather than the business just being consulted at the beginning of the project on the requirements, and handed a “this is what we thought you wanted” deliverable at the end.

Further, the CIO should appoint business liaisons or customer relationship managers to routinely work with the business, understand their needs and work to address them—until completion and satisfaction. The business liaisons need to “own the customer” and should not just be a pass-through to the help desk with no follow up, closure, or performance measurement

Where appropriate, I think it is even a good idea to collocate the business and IT people together, rather than in their separate fiefdoms and functional silos to so they really become a cohesive team—sharing business and IT knowledge and working together to implement an IT enabled business.

Of course, the CIO should encourage training, field trips, work details, and other cross-pollinating initiatives.

Finally, a robust enterprise architecture and IT governance helps to effectively bring the business and IT people together to jointly build the plan and make the decisions, so that it is not one side or the other working in a vacuum or imposing little understood requirements or solutions on the other.

In the book, The New CIO Leader by Boardbent and Kitzis, one of the basic premises is that “every CIO will follow one of two paths:” as follows:

--either they will be a “chief technology mechanic,” narrowly focused on IT to the exclusion of the business.

- or they will be a “new CIO leader,” where “IT is at the heart of every significant business process and is crucial to innovation and enterprise success.”

To be the new CIO leader, and truly integrate IT into the very fabric of the mission, you need to “weave business and IT strategy together” and also integrate the business and IT people to work effectively together.

Of course, this starts with building a high-performing IT organization, but must also involve regularly reaching out to the business at every opportunity and including them as full partners in build effective and efficient enterprise architecture planning, IT governance, and full systems life cycle execution.

In my opinion, the new CIO leader, does not think just IT, but lives and breathes the business and does everything in their power to bring the two not just in alignment, but in true partnership.

How important is this?

As Broadbent and Kitzis state: “If you don’t think like a constantly ‘re-new-ing’ CIO, you may be on our way to becoming an ex-CIO.

Bridging the Business and IT Divide

User-Centric Enterprise Architecture on YouTube

Click here for YouTube post on User-centric Enterprise Architecture.

http://www.youtube.com/watch?v=SkRgh8mjbpM

Enjoy and I appreciate your (constructive) comments.

User-Centric Enterprise Architecture on YouTube

IT Governance and Enterprise Architecture

I came across an interesting IT Governance Global Status Report 2008 from the IT Governance Institute.

The study and report was conducted by PriceWaterhouseCoopers (PwC) was the third one of its kind—the first two conducted in 2003 and 2005. In this latest study for 2007, interviews were conducted with 749 CIOs and CEOs in 23 countries.

Here are some interesting findings from the study on how enterprises are fairing on IT governance and my thoughts on these:

Championed by—in most cases CIOs champion IT governance (40%), followed by CEOs (25%), and then by CFOs (9%).

Since CIOs are predominantly responsible for IT governance, they need to step up and elevate governance as well as its complementary function, enterprise architecture, and resource it as a priority for effectively managing IT investments.

Business management engagement—68% of respondents said that business management participates (42%), leads (14%), or is fully accountable (12%) for IT governance.

From my experience, often business managers are more engaged in IT governance than IT managers; we need to work with the all the SMEs (IT and business) to understand the importance of IT governance and encourage and engage them for their active participation.

Positive view of IT—“Non-IT people…have a much more positive view of IT” than do IT people. 72% of general management agree strongly on the value creation of IT investment versus only 46% of CIOs.

We need to explore why IT professionals have a more negative view of IT than our customers on the business side of the house have and to reconcile this. Is it just that we are professionally self-critical or that know more about our dirty laundry?

Importance of IT to overall corporate strategy—“93 percent of respondents answered that IT is ‘somewhat’ to ‘very important’ to the strategy.”

IT is important to the business achieving its strategic goals. We need to ensure sufficient time, attention, and resources are allocated to developing an IT strategy and enterprise architecture that aligns to and support the business strategy.

IT governance implementation—Only 52% are ‘in the process of’ (34%) or ‘have already implemented’ (18%) IT governance; however, another 24% are considering implementing.

We need to pick up the pace of IT governance implementation. IT governance is critical establishing and enforcing the IT Strategic Plan and enterprise architecture, to vetting IT investment decisions and sharing risks with project shakeholders, and providing oversight and due diligence to ensure successfully project delivery.

Current IT governance practices—Some of these include: “IT resource requirements are identified based on business priorities” (80%), “boards review IT budgets and plans on a regular basis” (72%), “IT processes are regularly audited for effectiveness and efficiency” (67%), “Central oversight exists of overall IT architecture (IT Architecture Board or Committee)” (63%), “IT project portfolio is managed by business departments supported by the IT department” (59%), “Some form of overall IT Strategy Committee exists” (58%), Standard procedures exists for investment selection (IT Investment Committee)” (55%).

IT governance best practices are well established through frameworks such as COBIT, ITIL, and ISO20K. We need to leverage use of these frameworks to develop our organization’s IT governance solutions and ensure this vital enterprise architecture enforcement mechanism!

IT Governance and Enterprise Architecture

Andy Blumenthal Presents How Enterprise Architecture Shapes IT Governance

Check out this SlideShare Presentation:

Andy Blumenthal Presents How Enterprise Architecture Shapes IT Governance

View more Microsoft Word documents from ablumen.

Andy Blumenthal Presents How Enterprise Architecture Shapes IT Governance

IT Project Failures and Enterprise Architecture

Based on a number of studies done in the last 10 years (such as The KPMG Canada Study, The Chaos Report and others), it has been established that more than 50% of IT projects fail outright!

Why do IT projects fail? More often than not, it’s because managing IT has become a by the seat of the pants proposition—where things get decided by gut, intuition, politics, and subjective management whim. And we know that is not how to manage IT.

The way to make order out of IT project chaos is through enterprise architecture and IT governance.

EA is how we plan IT, synthesizing business and technology information, and driving business process reengineering, improvement, and the introduction of new technologies.

Governance is how we administer structured, consistent, and collaborative decision making, so managing IT is no longer a black box affair.

Together EA and IT governance provide for sound IT investment decision making, where EA serves as a strategic information asset to guide and influence capital planning and investment control activities of select-control-evaluate to ensure more successful IT project delivery.

Interestingly enough, Federal Times, 4 August 2008, corroborates the true high failure rate of IT projects.

According to the GAO, “Baseline adjustments hide the truth on OMB’s IT projects.”

“OMB considers a project to be over budget and off schedule [i.e. at risk] if it is projected to miss its targets by more than 10 percent.”

The reason though that all the IT projects missing the mark don’t show up on the OMB high-risk list is that “nearly half of the 180 IT projects surveyed by GAO have been rebaselined at least once. Of those, half were rebaselined twice and 11 percent were rebaselined four or more times,” according to David Powner GAO’s director of IT management issues.

What exactly does rebaselining mean?

“Nearly all of the rebaselined projects altered their cost and schedules because of changes in requirements or funding,” according to Karen Evans, OMB’s IT administrator.

So, if your changing the projected IT cost and schedule to match the actual—well then guess what? Naturally, more of your IT projects magically seem to meet their cost and schedule goals, and the true IT project failure rate is obscured.

Note that OMB is only looking at cost and schedule overruns and that doesn’t even take into account missing the mark on IT project in terms of performance parameters—one of the most important aspect of IT projects true success.

Perhaps, if we focus more on truly investing in better enterprise architecture and IT governance, then organizations wouldn’t need to rebaseline their cost and schedule projections to make for faux IT project success.

IT Project Failures and Enterprise Architecture

Prediction Markets and Enterprise Architecture

A very interesting article in ComputerWorld, 7 August 2008, called "Bet on it; Employee wagers help companies predict the future," shows how difficult planning can be and highlights the necessity of bringing stakeholders to the table to get better information (enterprise architecture) and better decisions (IT governance).

Google, for example, has for three years been using employee bets (over 80,000 so far) to predict market technology. “And Google has found that its employee bets are usually right.”

“Forrester Research Inc. suggests that other companies can benefit from putting in place prediction markets to more effectively tap employee opinions on topics ranging from if a store will open on time to picking specific features for a new product.”

Oliver Young, a Forrester analyst, says that “One of the biggest struggles that most companies have—not surprisingly—is predicting the future. Simple things like project updates are full of politics, full of meetings. One of the biggest values of prediction markets is you get a lot more people looking at these major questions.”

Other companies like Best Buy, Corning, HP, and Qualcomm are using predictive markets for sales projects, product evaluations, estimating project delivery, and assessing market conditions.

In predictive markets (a.k.a. crowdsourcing), “employees operate as traders to earn points--and potential prizes and other recognition--for correctly predicting future events…for example, a person who has been good at predicting how new products will be received can be invited into meetings where new product designs are discussed.”

While betting is typically associated with greed and vice and people ending up losing their shirts, in predictive markets, employee betting is used in a positive way to capture information from a broad spectrum of people and thus, enable better governance/decision making.

Predictive markets are an affirmation of the need to bring people in the planning and decision making process. Information needs to be captured from across the enterprise , for example, using predictive markets or other collection techniques.

The more information served up in a user-centric way, the better the decisions.

Prediction Markets and Enterprise Architecture

A Net-centric Military and Enterprise Architecture

Information is central to the Department of Defense’s arsenal for fighting and defeating our enemies and the ability to share information across interoperable systems in the way ahead.

National Defense, March 2008 reports that while a net-centric military is our goal, the transformation is a work in progress.

Brig. Gen. David Warner, director of command and control at DISA stated: “in this war, information is truly our primary weapon. You can’t move, you can’t shoot, if you can’t communicate.”

Yet, “the Defense Department continues to acquire stovepiped systems…the requirements change, the system grows, and then there are cost overruns. One of the first items to cut from the budget is interoperability.”

Air Force Gen. Lance L. Smith says, “the dream of a truly net-centric U.S. military will not happen overnight. But progress could be achieved within the next five to 10 years, It will be a matter of waiting for the stovepiped legacy systems to come to the end of their lifespan. If the services get onboard and stop building non-interoperable technologies now, then the new generation of net-centric communications can take over and become the norm.”

This sounds to me like the problem isn’t limited to legacy systems, but that there are still cultural, project management, and change management issues that are obstacles to achieving the net-centric goal.

The challenges are even greater and more complex when it comes to sharing information with “federal civilian agencies and foreign allies…NATO, for example, has no mechanism to ensure its members are interoperable with each other.”

“Today the normal way to do business is to ‘exchange hostages’ which means sending personnel from one service, agency, or coalition partner to each other’s command centers so they can verbally relay information.” This typically takes the form of interagency operation command center, and is not very net-centric.

So we continue to have stovepipes for “communications or data sharing systems built by different agencies, armed services, or coalition partners that cannot link to each other…[yet] the U.S. military is trying to make itself more lethal, faster, and more survivable. [And] the key to doing that is the ability to share information.”

Net-centricity, interoperability, and information sharing are true cornerstones to what enterprise architecture is about, and it is where we as architects are needed to take center stage now and in the years ahead in the war on terrorism and the other challenges we will face.

From an EA perspective, we need to ensure that all of our agencies’ targets, transition plans, and IT governance structures not only include, but emphasize net-centricity and enforce it through the EA review processes and the investment review board. There is no excuse for these stovepipes to persist.

A Net-centric Military and Enterprise Architecture

To Be A CIO and Enterprise Architecture

Public CIO Magazine, June/July 2008, has some interesting articles on what it takes to be a next generation CIO (and many of these have to do with enterprise architecture).

Here are some tips (adapted from Public CIO):

• Develop your EA and IT Governance Capabilities—one of the first moves of Michael Locatis, the CIO of Colorado, was “hiring an enterprise architecture team leader and the development of new governance structures.” This is critical in effectively planning and change managing the consolidation of IT. In Colorado it means uniting “20 disparate IT departments into a single citywide Technology Services Division.”
• Be a strategist—Liza Massey, CEO of The CIO collaborative, a Las Vegas-based consultancy believes that a “CIO needs to make the leap from being a technologist to being a strategist [what EA planning is all about!]…’you have to be seen as a peer working for the good of the organization, not as the chief geek.’” She says, “if you know the version number of the operating system running on your mainframe, you’re probably not a CIO.”
• Understand that mission drives technology—Pat Schambach, retired CIO of the Secret Service, ATF, and the TSA said “it was his ability to understand his organization’s business imperatives that made him CIO material.” Pat states about the Service, “they wanted someone who knew the mission well and could bring technology to bear against that mission.” Again, this is good EA and IT governance in practice: where business drives technology and not doing technology for technology’s sake.
• Focus on business processes—Vivek Kundra, the CTO of Washington DC believes that “The key is to focus on the business process.” He stated, “My approach is to go after the core of the problem, to look at how the employees do their jobs and then look for how we can affect change.” Again, this is EA synthesizing business and technology to satisfy mission and end-user needs and requirements.
• “Behave like an enterprise”—Dave Wennergren, Deputy CIO for the Department of Defense and prior CIO of the Navy, said “we have to behave like an enterprise. We don’t need 50 smart card solutions or 50 collaboration tools.” He believes “the enterprise can be responsible for tools everyone uses, freeing up agency developers to work on tools specific to their needs.” In other words, we can leverage enterprise architecture and IT governance to develop enterprise solutions that are cost effective and efficient, but at the same time remain nimble in meeting niche or localized needs.
• Be able to translate business to technology and vice versa—Alan Shark, executive director for the Public Technology Institute said, “I’m seeing a big shift from issues that were purely technology to issues have much more to do with IT governance and leadership—being a translator between the technologists who work in the trenches and the politicians or the [higher-level] people who just want to hear the facts.” Again, EA plays a critical role here in synthesizing business and technology to enable better IT decision making for the mission/business.
• Leadership skills—In the latest survey of the National Association of State CIOs, the traits that rose to the top for CIO success: “communication skills, negotiation skills, being able to collaborate and work across the agencies, to work with their executive team.” Laura Fucci, the CIO of Clark County Nevada (home to the Las Vegas strip) echoes these sentiments for a CIO and talks in terms of team building [and networking], being a consensus builder, improving customer service (ITIL), studying metrics, and good project management.

A few other traits worth mentioning from David Wennergren, from DoD, is continuous learning and studying and driving best practices. This again ties strongly to enterprise architecture which builds the target architecture, transition plan, and IT strategic plan, bringing together the best practices from inside and outside the organization to move it steadily forward.

Clearly, the enterprise architecture is the foundation for a successful CIO and the organization he/she serves.

To Be A CIO and Enterprise Architecture

What Not to Tell Your Boss and Enterprise Architecture

ComputerWorld Magazine, 20 June 2008, tells us five things you don’t want to tell the CIO and which I believe tracks closely with the enterprise architecture function and goals, as follows:

1. “All about the technology -- and nothing about the business”—just like enterprise architecture is about business driving technology, rather than doing technology for technology’s sake, so too the CIO is interested in aligning business and technology. So don’t just go to the CIO talking technology solutions unless you have a clear understanding and can articulate the business requirements.
2. “There's only one solution”—in enterprise architecture and IT governance, we validate requirements against the architecture—the baseline, the target, and the transition plan. It is especially important to check if there are existing systems, products, and standard that can be used to meet user requirements, rather than building or acquiring something from scratch. There is rarely only a single technology solution for a business problem. Therefore, we need to evaluate the proposed new IT investment in terms of the return on investment, risk management, strategic business alignment, and technical compliance. Additionally, we need to review the analysis of alternatives to make sure we are effectively managing our scarce IT resources.
3. “Bad opinions about your colleagues”—EA planning and governance makes information transparent and enables better decision making. With EA information, vetting of IT investment and collaborative decision making, there is no need to point fingers at each other over failed IT projects. Instead, through sharing information and bringing IT project stakeholders together, we all have input into the decision process and share the project risk.
4. “There's no way”—With enterprise architecture, rather than say there’s no way to achieve enterprise goals or overcome technical challenges, we develop a target and plan for how we will do it. No, the goals are not achieved overnight, but rather by following a meticulous and vetted plan, usually over a period of three to five years, we can transform the enterprise.
5. “A surprise”—Bosses don’t like surprises. In a professional setting, we usually like rational thinking, process, structure, and planning, so that we can effectively deal with the chaotic world out there. EA planning and structured governance helps the organization stay on course and not get surprised or thrown. The planning process itself involves looking at our strengths, weaknesses, opportunities, and threats, and makes us more self-aware and proactive as an organization, so there are less surprises waiting to ambush us.

EA helps us to NOT have to tell our boss, the CIO, things he doesn’t want to hear, because we are proactive in our approach to planning and governance.

What Not to Tell Your Boss and Enterprise Architecture

Implementing IT Governance

IT governance is often implemented with the establishment of an IT Investment Review Board (IRB) and Enterprise Architecture Board (EAB); but to get these to really be effective you have to win the hearts and minds of the stakeholders.

Here are some critical success factors to making IT governance work:

• Management buy-in and commitment—this is sort of a no-brainer, but it’s got to be said; without senior management standing firmly behind IT governance, it won’t take root and IT projects will continue to fly under the radar.
• Prioritizatuion and resourcing—EA, IT Strategic Planning, and IT governance compete with IT operations for resources, management attention, and prioritization. More often than not, many not so savvy CIOs value putting some new technology in the hands of the end-user over creating strategic IT plans, developing transition architectures, and implementing sound IT governance (they do this at risk to their careers and good names!)
• Policy and procedures—IT governance needs a firm policy to mandate compliance to the user community; further the procedures for users to follow need to be clear and simple. IT governance procedures should integrate and streamline the governance processes for authorizing the project, allocating funding, conducting architectural reviews, following the systems development life cycle, managing the acquisition, and controlling the project. End-users should have a clear path to follow to get from initiating the project all the way through to close-out. If the governance mechanism are developed and implemented in silos, the end users have every reason in the world to find ways to work around the governance processes—they are a burden and impede timely project delivery.
  
• Accessibility—Information on IT governance services including the process, user guides, templates, and job aids needs to be readily available to project managers and other end users. If they have to search for it or stick the pieces together, then they have another reason to bypass it all together.
• Enforcement—there are two major ways to enforce the governance. On the front end is the CIO or IRB controlling the IT funding for the enterprise and having the authority to review, approve, prioritize, fund, monitor, and close down IT projects. At the back-end, is procurement; no acquisitions should pass without having demonstrated compliance with the IT governance processes. Moreover, language should be included in contracting to enforce EA alignment and compliance.
• Cultural change-Organizations need to value planning and governance functions. If operations always supersede IT planning and governance, then both business and technical stakeholders will feel that they have a green light to ignore those functions and do what they want to do without regard to overall strategy. Further, if the culture is decentralized and governance is managed in silos (one manager for SDLC, another for EA, yet another for requirements management), then the processes will remain stove-piped, redundant, and not useable by the user community.
• Communication plan—the governance process and procedures need to be clearly communicated to the end users, and it must address the what’s in it for me (WIIFM) question. Users need to understand that their projects will be more successful if they follow the IT plan and governance processes. Those are in place to guide the user through important and necessary project requirements. Further, users are competing for resources with other important IT projects, and user will benefit their projects by making the best business and technical case for them and following the guidelines for implementing them.

Implementing IT Governance

10 Obstacles to Enterprise Architecture

Here is an interesting list of 10 obstacles to the enterprise architecture from a colleague and friend, Andy Wasser, Associate Dean, Carnegie Mellon University School of Information Systems Management:

1. “Lack of Senior Management [Commitment] Support
2. Inability to obtain necessary resources (funds, personnel, time)
3. Business partner alienation
4. Internal IT conflicts and turf issues (no centralized authority)
5. Lack of credibility of the EA team
6. Inexperience with enterprise architecture planning or inexperience with the organization
7. Entrenched IT team [operational focus versus strategic]
8. Focus on EAP methodologies and tools [rather than on outputs and outcomes]
9. Uncertain payback and ROI
10. Disharmony between sharing data vs. protecting data

This is a good list for the chief enterprise architect to work with and develop strategies for addressing these. If I may, here are some thoughts on overcoming them:

1-4,7,9: Obtain Senior management commitment/support, resources, and business/IT partnership by articulating a powerful vision for the EA; identify the benefits (and mandates); preparing an EA program assessment, including lessons learned and what you need to do to make things “right”; developing an EA program plan with milestones that shows you have a clear way ahead. Providing program metrics of how you intend to evaluate and demonstrate progress and value for the business/IT.

5,6,8: Build credibility for EA planning, governance, and organizational awareness by hiring the best and the brightest and train, train, train; getting out of the ivory tower and working hand-in-hand in concert with business partners; building information products and governance services that are useful and usable to the organization (no shelfware!); using a three-tier metamodel (profiles, models, and inventories) to provide information in multiple levels of details that makes it valuable and actionable from everyone from the analyst to the chief executive officer; looking for opportunities (those that value EA and want to participate) and build incrementally (“one success at a time”).

10: Harmonize information sharing and security by developing an information governance board (that includes the chief information security officer) to vet information sharing and security issues; establishing data stewards to manage day-to-day issues including metadata development, information exchange package descriptions, discovery, accessibility, and security; creating a culture that values and promotes information sharing, but also protects information from inappropriate access and modification.

10 Obstacles to Enterprise Architecture

Honda and Enterprise Architecture

Enterprise architecture helps to define, structure, and govern the business processes and enabling technologies of the organization. It packages this into an identification of the as-is, to-be, and transition strategy. EA is a methodology for planning and governing.

Some companies though, such as Honda, function more by a seat-of-the-pants approach than by EA.

Fortune Magazine, 17 March 2008, reports that “the automaker’s habit of poking into odd technical corners sets it apart—and gives it a big edge on the competition.”

Honda is a huge, highly successful company. “Since 202 its revenues have grown nearly 40% to $94.8 billion. Its operating profits with margins ranging from 7.3% to 9.1% are among the best in the industry. Propelled by such perennial bestsellers as the Accord, the Civic, and the CR-V crossover, and spiced with new models like the fuel-sipping Fit, Honda’s U.S. market share has risen from 6.7% in 2000 to 9.6% in 2007.”

What is Honda’s secret to success?

The wellspring of Honda’s creative juices is Honda R&D, a wholly owned subsidiary of Honda Motor.”

"Honda R&D is almost the antithesis of EA’s planning and governance."

Honda R&D “lets its engineers, well dabble,” so much so that even the president and CEO of Honda says “I’m not in a position to give direct orders to the engineers in R&D.” Honda gives a lot of latitude to its engineers to “interpret its corporate mission” to the extent that their engineers have been known “to study the movement of cockroaches and bumblebees to better understand mobility.” R&D pretty much has free rein to tinker and figure out how things work, and any application to business problems is almost an afterthought.

This “more entrepreneurial, even quirky” culture has helped Honda find innovative solutions like fuel cells for cars that are “literally years ahead of the competition”. Or developing a new plane design “with engines mounted above the wings; this has made for a roomier cabin and greater fuel efficiency.”

At the same time, not having a more structured EA governance approach has hurt Honda. “When Honda launched the hybrid Insight in 1999 for example, it beat all manufacturers to the U.S. market (the Toyota Prius came six months later). But while the Prius looked like a conventional car, the Insight resembled a science project; it didn’t even have a back seat. Honda halted production in September 2006 after sales dropped to embarrassing levels. Toyota sold more than 180,000 Priuses last year.”

Honda is learning its lesson about the importance of planning and good governance, and now, they “tie [R&D] more closely to specific business functions” and “as a project approaches the market, the company is asserting more supervision.”

R&D and innovation is critical, especially in a highly technical environment, to a company’s success; however even R&D must be tempered with sound enterprise architecture, so that business is driving technology and innovation, rather than completely doing technology for technology’s sake.

Honda and Enterprise Architecture