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.

Disaster Preparedness and Enterprise Architecture

Requirements Management and Enterprise Architecture

Requirements management is critical to developing enterprise architecture. Without identifying, understanding, and rationalizing the organization’s requirements, no meaningful enterprise architecture planning can occur.

“The purpose of Requirements management is to manage the requirements of a project and to identify inconsistencies between those requirements and the project's plans and work products. Requirements management practices include change management and traceability.”

Traceability is the identification of all requirements back to the originator, whether it be a person, group, or legal requirement, or mandate. Traceability is important to ensure alignment of end products with the origination of the requirements, prioritization of requirements, and determining requirements’ value to specific users. Traceability should ensure that requirements align to the organization’s mission (intended purpose) and its strategic plan. (Wikipedia)

How is requirements management done?

1. Stakeholders—identify program/project stakeholders.
2. Requirements—capture, validate and prioritize stakeholder requirements.
3. Capabilities—analyze alternatives and plan for capabilities to fulfill requirements.
4. Resources—ascertain resource needs for capability development
5. Activities—perform activities to develop the capabilities to meet the requirements.
6. Measures—establish measures to demonstrate requirements have been met.

How does EA bridge requirements and capabilities?

Enterprise architecture captures strategic requirements—high-level mandates or needs. It uses this to establish an integrated set of functional requirements areas or cross-cutting categories of requirements. These drive strategic capability development to meet mission needs and achieve results of operation. Strategic capabilities are reflected in the enterprise architecture in the target and transition plan. This is used to evaluate proposed new IT projects, products, and standards to ensure that they align to and comply with the EA.

EA is the glue that binds sound IT investment decision making to strategic requirements and technical alignment.

Requirements Management and Enterprise Architecture

Don’t Get Put Out To Pasture and Enterprise Architecture

When an organization and its people don’t meet the needs of their users, they are sidelined; users will get their needs met elsewhere. It’s the nature of competition and the free market. And as enterprise architects, we need to make sure that our organizations are always meeting our users’ needs. The target architecture must reflect changing consumer tastes, needs, desires, and requirements.

The Wall Street Journal, 29-30 March 2008, reports that in India, milkmen, who used to be respected and productive civil services, have been put “out to pasture.”

In Mumbai, 300 milk delivery drivers show up for work each day, only to sit idle for their eight hour shifts—they read, nap, or play cards or sudoku. “The state government lost its monopoly on milk and consumer tastes changed. But because Indian work rules strictly protect government workers from layoffs,” the workers remain in a perpetual state of limbo.

In 2001, “private careers with higher quality milk swiftly won customers [away from the government dairy] by delivering milk to doorsteps [instead of to curbside milk stalls like the government milkmen did].”

Once the customer got the taste of the better milk and more convenient delivery, they “swiftly deserted.” The bar had been raised and now the consumers wanted, no demanded, the better product and service.

In the past, milkmen “lived in government housing near work, retired with a pension and often passed their jobs to their sons. ‘We enjoyed doing our work because it was a public service. Time flew by.”

But the government milkmen don’t meet the consumers’ needs anymore and now “most of the deliverymen, plus around 4,000 other dairy workers statewide” are on the “surplus list.”

“The dairy used to deliver around 250,000 gallons of milk each morning. Now it sends less than a quarter of that, delivered by private carriers, since the milk trucks were sold.”

One milkman stated: “We want work. Just give us something to do and we will work 10 hours a day instead of eight. I really miss my truck.”

The lesson is clear for organizations and their workers: deliver exceptional products and services to your customers and meet their every realistic need or they will go elsewhere (to the competition) and you will soon be joining the Indian milkmen and missing your delivery truck.

Don’t Get Put Out To Pasture and Enterprise Architecture

Census is Back to Bean Counting and Enterprise Architecture

So much for EA enabling business process with technology enablement!

The Wall Street Journal, 4 April 2008, reports “Census Bureau Scraps Plans for a High-Tech Count.” Now census takers will have to “go back to paper-based canvassing to count the millions of households that don’t return their census forms.”

“The bureau’s decision to shelve technology that was supposed to make the count more accurate will add $3 billion to the cost of the count,” an almost 30% increase in cost.

Census’s EA plan was to “give hand-held computers to its half million census takers, who would use them first to verify and map every address in the country, and then to follow up on households that didn’t return the six question census form that will be mailed in March 2010. The census takers would then send completed questionnaires electronically to a database, saving the bureau time and money.”

What went wrong?

1) Unclear Requirements—GAO “has been warning for years that the Census Bureau wasn’t spelling out technical requirements for the devices and last month put the census on its short list of high-risk government undertakings.”

2) Requirements creep—“large scope of requirements changes,” which will now not only delay the use technology from use in 2010, but also will drive the contract cost with Harris Corp. up from $600 million to $1.3 billion.

3) Inexperience—“attributed some of the Census Bureaus problems to its inexperience at managing big contracts, especially big technology projects.”

4) Overconfidence—“’The Census Bureau might have been overconfident in how easy it would be’, said Terri Ann Lowenthal of the Census Project, a nonpartisan group.”

Why is getting the census count so important?

“The count has enormous political implications. Census data are used to apportion House seats, Electoral College votes and about $300 billion a year in funding.”

From an EA perspective, the success of achieving a target architecture and transition plan, such as the one at Census for hand-held computers for the census-takers, hinges in large degree of having clear and scoped requirements and line of sight all the way to the technical solution.

Certainly, many IT projects fail to meet their cost, schedule, and performance parameters precisely because of poor requirements management processes.

We cannot be successful with our IT investments and meeting EA transition plans if we don’t start with a clear and definite vision of where we’re going.

Census is Back to Bean Counting and Enterprise Architecture

Information Integrity and Enterprise Architecture

We are in an information economy and now more than ever business needs information to conduct their functions, processes, activities, and tasks.

To effectively conduct our business, the information needs to be relevant and reliable. The information should be current, accurate, complete, understandable, and available.

Information integrity is essential for enabling better decision-making, improving effectiveness, and reducing risk and uncertainty.

However, according to DMReview, 8 February 2008, “information within the [corporate] data warehouse continues to be inaccurate, incomplete, and often inconsistent with its sources. As a result, data warehouses experience low confidence and acceptance by users and consumers of downstream reports.”

“The Data Warehousing Institute estimates that companies lose more than $600 million every year due to bad information.”

What are some of the challenges to information integrity?

1. “Complex environments, [in which organizations] constantly generate, use, store, and exchange information and materials with customers, partners, and suppliers.”
2. “Accelerating change in the business environment [and] changing needs of business users”
3. “Increasing complexity of source systems and technology”
4. “Expanding array of regulations and compliance requirements”

“Change and complexity introduce information integrity risk. Accelerating change accelerates information integrity risk. Compliance makes information integrity an imperative rather than an option.”

What are the particular challenges with data warehouses?

1. Questionable input information—“Several source systems feed a data warehouse. Data may come from internal and external systems, in multiple formats, from multiple platforms.”
2. Lack of downstream reconciliation—“As information traverses through the source systems to a data warehouse, various intermediate processes such as transformations may degrade the integrity of the data. The problem becomes more acute when the data warehouse feeds other downstream applications.”
3. Inadequate internal controls—these include controls over data input, processing, and output, as well as policies and procedures for change management, separation of duties, security, and continuity of operations planning.

From an enterprise architecture perspective, information integrity is the linchpin between the businesses information requirements and the technology solutions that serves up the information to the business. If the information is no good, then what good are the technology solutions that provide the information to the business? In other words, garbage in, garbage out (GIGO)!

As enterprise architects, we need to work with the business and IT staffs to ensure that data captured is current, accurate, and complete, that it is entered into the system correctly, processed accurately, and that outputs are distributed on a need to know basis or as required for information sharing purposes, and is protected from unauthorized changes.

Using business, data, and systems models to decompose the processes, the information required for those, and the systems that serve them up helps to identity possible information integrity issues and aids in designing processes that enable quality information throughput.

Additionally, security needs to be architected into the systems from the beginning of their lifecycle and not as an afterthought. Information confidentiality, integrity, availability, and privacy are essential for an information secure enterprise and for information quality for mission/business performance.

Information Integrity and Enterprise Architecture

Kiwi and Enterprise Architecture

Most of us don’t give must thought to a company like Kiwi, founded in 1906, that makes shoe polish (you know, the ones sold in the round tins with the twist handles that prop open the lid). However, Kiwi has been remaking itself and in 2007 contributed $310 million in sales to Sara Lee Corporation.

The Wall Street Journal, 20 December 2007, reports how two years ago, Kiwi “interviewed 3500 people in eight countries about their shoe care needs” and they found that “on a list of more than 20 attributes people desired in their shoes, shine ranked merely 17th.” Kiwi went on to re-architect the company from being a shoe shine-centric one to one with a varied shoe care product line more in tune with customer needs for fresh smelling and comfortable shoes.

The Chief Executive of Kiwi states─ “‘it became clear: innovation was a key value of ours’…but innovation wasn’t enough…products had to be informed by the needs and desires of consumers.”

Kiwi’s approach was very much in line with User-centric EA. They focused on the user requirements first and foremost. Then, and only then, did they apply innovation to new products to satisfy the needs.

The company went on to develop: “’fresh’ins’ (thin lightly fragranced shoe inserts for women) and ‘smiling feet’ (a line of cushions for heels and the balls of feet, anti-slip pads and strips that can be placed behind the straps of high-heel sling-back shoes.”) Kiwi transformed itself and became “a foot care brand without losing its edge as the world’s shoe-care expert.”

How did they transform themselves?

1) Requirements gathering: They surveyed and sought to understand their customers’ needs.
2) Solution analysis and design: They consulted podiatrists and physiologists “to understand foot anatomy and how bacteria trigger odor buildup in shoes.”
3) Prototype development: Kiwi created “prototypes that customers could actually put on their feet.”
4) Marketing planning: Kiwi designed new packaging and made a new merchandising system for in store displays that grouped “their women’s products, athletic products, [and] shoe shine products by color─moves intended to make the shoe-care aisle easier to shop.”

Kiwi implemented a true User-centric EA approach to its transformation efforts. They did not let advances in foot care products drive the business approach, but rather they let the consumers and their requirements drive the business and its product development expansion. Moreover, the company focused not only on product development, but integrated a comprehensive solution to meet their consumer needs through a whole new line of foot care products (augmenting their shoe care line) and incorporated testing and marketing to ensure a successful launch. What an amazing feat for Kiwi (no pun intended)!

Kiwi and Enterprise Architecture

A Square Envelope and Enterprise Architecture

Would you believe me if I told you that the U.S. Post Office has trouble handling square envelopes? Well, it’s true, and moreover, the post office will actually “charge you a 17-cent surcharge for squareness.” This is called “shape-based postage.” (Wall Street Journal, 15 November 2007)

Why the surcharge? Because the post office sorting machines, “built for oblongs, can’t find the address on a square envelope. [Hence,] people have to do it.” In fact, “at a Manhattan post office…a window clerk…took one look at a square envelope and said ‘nonmachinable. I would not use that shape, period.’”

This is crazy isn’t it; we can put men on the moon, but we can’t send a square envelope easily through the mail system of the United States of America! (FYI, squares are not a problem for the mail system in the United Kingdom.)

I knew that being “square” in the seventies was a bad thing, and maybe even an insult, but what’s up with square now and how does this jive with users needs?

Well in the article, an owner from a graphics company states: “Squares…are the most current and most exciting product in paper communications.” Incredible, that the post office can’t meet their customers’ needs.

Even if squares are still a relatively small percentage of the overall mail (and according to the article they are), that may be because the post office can’t handle the shape versus the overall popularity of it with customers. As another sales rep states: “The post office cracked down…people had bad experiences with square cards. [And] if you put a stigma on something long enough, retailers aren’t going to deal with it anymore.”

So when the post office can’t handle the user needs, the card makers have innovated: “the shop has devised an oblong envelope with a middle pocket that squares slip neatly into.”

This is sounding almost like the post office is making us put a square peg in a round hole.

Just for the record, we shouldn’t blame the good men and women of the U.S. Post Office for the problems with the sorting machines. However, I believe this is clearly a job for User-centric Enterprise Architecture to align post office technology solutions for handling square envelopes with the business requirements for them. Clearly, it’s time for square equality.

A Square Envelope and Enterprise Architecture

Segway and Enterprise Architecture

User-centric EA is based on business driving technology, rather than technology for technology’s sake.

An example of technology for technology’s sake:

Segway today is an example of technology for technology's sake: The basic model has no weather protection or ability to carry family members or luggage. It is innovative and seems like it has a lot of untapped potential, but as of now, has not been aligned with the needs of its potential users.

Requirements should come first.

From a User-centric EA approach, rather than starting with hundreds of new technology patents, Dean Kamen the founder of Segway and his organization should have started with an ethnomethodological study of individual and social mobility and the requirements for the individual and society for transporting people and property under various environmental and personal situations.

There is an important place for innovation.

Mr. Kamen and Segway have developed some innovative and helpful technology: Segway has helped in the energy efficient and personal mobility marketplace. Segway has especially helped disabled people with its amazing stairclimbing technology. So certainly, there is a place for pure innovation and creativity by the engineering community, like the approach Segway has pursued. However, for Segway, the market penetration and potential for benefiting greater numbers of people remains somewhat at a distance.

In contrast to Segway’s pure engineering approach, in User-centric EA, innovation is critical, but user requirements are primary!

Segway and Enterprise Architecture