>Enterprise Architecture Plans that Stick

>I read a great little book today called Made to stick by Chip and Dan Heath about “Why some ideas survive and others die.”

As I read this, I was thinking how very applicable this was to User-centric Enterprise Architecture in terms of making architecture products and plans that stick—i.e. they have a real impact and value to the organization and are not just another ivory tower effort and ultimately destined as shelfware.

The Heath brothers give some interesting examples of stories that stick.

Example #1: A man is given a drink at the bar by a beautiful lady that is laced with drugs and he finds himself waking up in a bathtub on ice with a note that tell him not to move and to call 911—he has been the victim of a kidney heist and is in desperate need of medical attention.

Example #2: Children Halloween candy is found tampered with and there is a scare in the community. The image of the razorblade in the apple is poignant and profoundly changes people’s perception of and trust in their neighbors.

Now, you may have heard of these stories already and they probably strike a deep chord inside everyone who hears them. Well, surprise—neither story is true. Yet, they have lasting power with people and are remembered and retold for years and years. Why do they stick, while other stories and ideas never even make it off the ground?

Here are the six necessities to make ideas have lasting, meaningful impact and how they relate to enterprise architecture:

Simplicity—drilldown to essential core ideas; be a master of exclusion; come up with one sentence that is so profound that an individual could spend a lifetime learning to follow it. In enterprise architecture, keep information products and plans straightforward and on point.

Unexpectedness—violate people’s expectations; surprise them, grab people’s attention; I call this the shock factor. In architecture, we can use principles of communication and design (for example identify critical relationships in the information) to garner people’s attention, and help them come away with actionable messages.

Concreteness—use concrete images to ensure our idea will mean the same thing to everyone. In enterprise architecture, we can use information visualization to make information and ideas more concrete for the users (i.e. “a picture is worth a thousand words.”)

Credibility—promote ideas in ways that they can be tested, so that they are credible to the audience. An example is when Reagan was running for president and he asked Are you better off today than 4 years ago. This brought the message home and made it credible with voters in ways that pure numbers and statistics could not. For architects, the roadmap provided to the enterprise must be credible—it must have the level of detail, accuracy, comprehensiveness, and currency to garner acceptance.

Emotions–make your audience feel something; people feel things for people not for abstractions. In architecture and planning, we need to inspire and motivate people in the organization effectively influence, shape, and guide change. Remember, there is a natural resistance to change, so we need to appeal to people intellectually and also emotionally.

Stories—tell stories that are rich and provide for an enduring mental catalogue that can be recalled for critical situations in later life. Often, architects create isolated products of information that describe desired performance outcomes, business processes, information flows, systems, and technology products and standards; however, unless these are woven together to tell a cohesive story for the decision makers, the siloed information will not be near as effective as it can be.

These six principles spell out SUCCES, and they can be adeptly used successfully by enterprise architects to hone information and planning products that enable better decisions. These are the types of architectures that stick (and do not stink) and are truly actionable and valuable to the organization.

>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.

>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.

>Disaster Preparedness and Enterprise Architecture

>

There are several disaster preparedness exercises that test and train our government and private sector partners’ ability to respond to incidents that could have catastrophic consequences. These exercises can be supported by a robust enterprise architecture; here is a brief description followed by a sketch of how EA can support disaster preparedness.

TOPOFF

“Top Officials (TOPOFF) is the nation’s premier terrorism preparedness exercise, involving top officials at every level of government, as well as representatives from the international community and private sector. Thousands of federal, state, territorial, and local officials engage in various activities as part of a robust, full-scale simulated response to a multi-faceted threat.” [Exercises have tested responses to chemical, biological, and radiological attacks.]

(http://www.dhs.gov/xprepresp/training/gc_1179350946764.shtm)

Cyber Storm

“The U.S. Department of Homeland Security’s (DHS) National Cyber Security Division (NCSD) successfully executed Cyber Storm, the first national cyber exercise Feb. 6 thru Feb. 10, 2006 [and a second biennial exercise was conducted in March 2008]. The exercise was the first government-led, full-scale cyber security exercise of its kind…Cyber Storm was designed to test communications, policies and procedures in response to various cyber attacks and to identify where further planning and process improvements are needed.”

(http://www.dhs.gov/xnews/releases/pr_1158340980371.shtm)

Government Computer News, 14 April 2008 reports on the Cyber Storm II exercise in which DHS “hosted federal, state, local, and international government agencies along with more than 40 private-sector companies” in these “high-stakes war games.”

Carl Banzhoff, the vice president and chief technology evangelist at McAfee summed it up as follows: “when the internet burns to the ground, how are you going to get updates?”

The goal was to test communication coordination and partnerships across sectors.”

Bob Dix, the vice president of government affairs at Juniper Networks said that “the greatest impediment to sharing information still is trust.”

Whether the preparedness tests are for terrorism or cyber security, the essence is to test our ability in preparing, preventing, responding, and recovering from security incidents. This involves building capability for uninterrupted communications, information sharing, and coordinated response.

How can enterprise architecture support disaster preparedness?

  1. Requirements—EA can capture strategic, high-level requirements from mission areas across the many functional areas of homeland security and weave these into a core map of capabilities to build to. For example, we have a requirement for system security that is mandated by law and policy, and securing our communications and infrastructure is a core capability for our information systems that must be executed. The weakest link in security has the potential to jeopardize all components and their response capability.
  2. Planning—EA analyzes problem areas and uncovers gaps, redundancies, inefficiencies, and opportunities and uses these to drive business process improvement, reengineering, and the introduction of new technologies. Improved business processes and enabling technologies can enable integration, interoperability, standardization, modernization, and information sharing that can enable a better prepared homeland security infrastructure. For example, identifying shared mission communities and building information sharing and collaboration among stakeholders in these improves our preparedness abilities.
  3. Governance—EA brings the various stakeholders to the table to vet decisions and ensure sound business process improvement and IT investments. Governance involves sharing information, building trust, and making decisions towards a unified way forward. For example, through the DHS Enterprise Architecture Board (EAB), the CIOs of all components can collaborate and engage in developing targets that will lead to implementation of best practices and standards across the Department that will improve overall efficiency of all components.

Of course, EA is not the be-all and end-all for preparedness, but it provides critical elements of requirements management, planning, and governance that contributes to disaster preparedness.

>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.

>Robot Warfare and Enterprise Architecture

>

The day has arrived. It’s the Terminator, but for real—a killer robot made to do some serious battlefield harm.

Fortune Magazine (December 2007) reports that its “1% inspiration and 99% obliteration…when engineering talent meets extreme gunsmithing.”

“It’s two feet tall, travels ten miles an hour, and spins on a dime. Remote-controlled over an encrypted frequency that jams nearby radios and cellphones, it’ll blow a ten-inch hole through a steel door with deadly accuracy from 400 meters.”

When firing in automatic mode, it shoots 300 rounds per minute and “delivers the lead equivalent of 132 M16s.”

Two such deadly bots can be carried into battle on a remote-controlled mini-helicopter, called the AutoCopter.

Robotex has built these deadly robots with investor money rather than government research money and has developed these devastating technology marvels for only $30,000 to $50,000.

These robots while new to the market are a sure bet from an enterprise architecture perspective. They meet user requirements as a superb killing machine. They take our military men and women out of harm’s way and instead intelligently use technology to conduct the “business” of war. The technology employed is low maintenance and is the finest, most reliable, firepower available (“It’s made of aircraft-grade aluminum steel, never needs lubrication or cleaning, and won’t rust. Pour sand in it and it won’t clog. It doesn’t recoil.”). It’s extremely cost-effective. And it gives us the technology edge.

Let’s hope and pray that we’re already planning counter-measures for when the bad guys get up-to-speed on these. That is very necessary EA planning for protecting our country and interests.

>Yin and Yang and Enterprise Architecture

>

Yin and Yang describe two primal opposing but complementary principles or cosmic forces said to be found in all non-static objects and processes in the universe.

The outer circle represents the entirety of perceivable phenomena, while the black and white shapes within the circle represent the interaction of two principles or aspects, called “yin” (black) and “yang” (white), which cause the phenomena to appear in their peculiar way. Each of them contains an element or seed of the other, and they cannot exist without each other.

Yin is passive, dark, feminine, downward-seeking, and corresponds to the night. Yang is active, light, masculine, upward-seeking and corresponds to the daytime.

All forces in nature can be seen as having yin and yang states, and the two are in constant movement rather than held in absolute stasis.

Yin and yang is a process of harmonization ensuring a constant, dynamic balance of all things. Excessive yin or yang state is often viewed to be unbalanced and undesirable.

User-centric EA applies the concepts of Yin and Yang—in terms of balance and harmony─to the way the chief enterprise architect relates to and works with users, the way products and services are developed, and the way architecture plans are formulated. Some examples:

  • Working with users: The chief enterprise architect needs to recognize that in planning for the future state of the organization, there are going to be different points of views, diversity of aims and aspirations, and general conflict. The architect can use the principles of Yin and Yang to understand that opposing points of view are complementary and in fact necessary to vet issues and achieve better decision on behalf of the enterprise. The architect works to listen to all viewpoints and reconcile these to achieve a harmonized and optimal way ahead for the organization.
  • Developing products and services: User-centric EA provides useful and useable products and services to the end-user. The philosophy of Yin and Yang helps guide the architect to develop information products that are dynamic (actively pushing out information to the end user), balanced (evenhanded, reasonable, and objective,) and where the information flows clearly and concisely. The point is to effectively communicate with users, so that they can access and use the EA knowledge base to make better decisions. EA communicates up, down, and across the organization as well as with outside entity stakeholders, such as customers, suppliers, partners, and oversight authorities. In all cases clear and balanced communication is a key ingredient to building and maintaining the architecture and leveraging use for all parties.
  • Formulating architecture plans: In developing a User-centric EA plan, the concepts of Yin and Yang help to develop plans that are neither black nor white (absolute) and that are not static (but rather fluid). For architecture plans to be effective, they need to provide “wiggle room” to the organization to adjust to changing needs and environment factors (i.e. plans should not be “black and white”, but should take into account shades of gray or in the case of the Yin and Yang, there is a little Yang in every Yin and vice versa). Additionally, as the flowing symbol of the Yin and Yang indicate, plans need to be fluid and move the organization in phases. You don’t just jump to the next big technology or slice and dice your business processes, but rather you evolve in a careful, planned, and incremental course—flowing from one state to the next and so on.