June 29, 2008

Bill Gates and Enterprise Architecture

On July 1, Bill Gates is stepping down from his day-to-day duties at Microsoft, but will continue to serve as Chairman. Bill Gates grew Microsoft into the worldwide software development leader with revenue of $51 billion for fiscal year ending June 2007 and 78,000 employees in 105 countries and regions.

As the prior CEO and chief software (and technical) architect it is definitely worthwhile to look at the legacy that Bill is leaving behind at Microsoft.

Fortune Magazine, 7 July 2008, provides four lasting imprints that Bill Gates is leaving on Microsoft and here are my thoughts on these as relates to enterprise architecture:

  1. Software can do anything—Gates has a “utopian view of software. He believes it can do anything.” Like Bill Gates, we need to believe in the mission of our organization. Such belief is critical in inspiring passion for and dedication to what we do. However, blind belief that any one thing can do anything is folly. For example, software without hardware is a no-go as is hardware without software. Both are non-starters without the people to innovatively apply them to our greatest challenges.
  2. Engineers rule—“Microsoft employees about 30,000 programmers among its 90,000 employees. In operating groups, engineers are involved in every major decision…Microsoft $8 billion computer science R&D lab is the world’s largest” Engineers are critical to solving our challenges, but you should not ignore marketing and sales either. Marketing and sales reach out and touch the people. You cannot ignore the human aspect to solving problems. Maybe it partially Microsoft’s obsessive engineering approach that has left it vulnerable on the people side, for example: “Apple’s biting ad campaign has successful painted Windows as uncool.”
  3. “Institutionalize paranoia”—“’It’s very Microsoft to prepare for the worst,’ says Gates…Bill and Steve (Ballmer) created what I guess I’d characterize as a culture of crisis,’ says chief software architect, Ray Ozzie. There’s always someone who’s going to take the company down.” Paranoia is a disorder, but fighting for competitive advantage is reality. Your competitors are not laying down to die; they are fighting for their professional lives, and you need to meet the challenge every day if you want to be the best out there.
  4. “Invest for the long term”—“Whatever the cycle is, we will keep investing through the cycle, because we know on the other side of whatever cycle happens, there is opportunity,” says entertainment division president Robbie Bach. The approach for long term planning is very enterprise architecture focused. However, the architecture planning without the good governance to administer structured, consistent, collaborative decision making is not very workable. Planning without effective decision making and enforcement falls short on the execution side. Again, perhaps here too, Microsoft could benefit from a less top heavy culture and a more open decision process, where all project and product stakeholders have a serious voice at the table. Then turning over the reins from Bill will not be as traumatic requiring approximately four years of preparation and turnover.

In the end, Microsoft is truly terrific company and Bill Gates is leaving a company that is nothing short of spectacular. Of course, even the best can get better with continuous learning and innovation and that is the next chapter for Microsoft in the world of the likes of Google and Apple.


Share/Save/Bookmark

June 27, 2008

Architecting a Balance

As a child, we learn from our parents, teachers, and mentors, that too much of even a good thing is bad for you: be it sweets or hard work—in fact, just about anything taken to an extreme is deadly.

The lesson of finding a balance in life has been captured in religious and philosophical teaching about practicing a middle of the road or golden path approach in life. In architecture as well, developing a strong viable architecture is also premised on balancing conflicting demands and finding that delicate balance.

In simple terms, architecting a balance shows up in having to manage scarce IT resources. So that while on one hand, we may like to have the latest and greatest technologies to give us every edge, we have to balance to promise of those technologies with the cost involved. We do not have endlessly deep pockets.

Similarly, while on one hand, we it would be wonderfully customer-centric to provide each and every one of our customers the customized business processes and technology solution that they want, prefer, or are simply most familiar or comfortable using; on the other hand, we must balance the innovativeness and agility that our customers demand with the need to standard around enterprise and common solutions, which provide a more structured, deliberate, and lower cost base on which to service the enterprise.

As we know from childhood, it is not easy to find the “right” balance. That next bite of cotton candy tastes great going down and we won’t feel the stomachache till later that evening.

National Defense Magazine, November 2007, has an article about architecting a balance in the Coast Guard mission of maritime security, titled “License to Boat?”

The threats from small boating vessels are threefold:

  1. Smuggling—“the use of a boat to smuggle people or weapons of mass destruction into the United States.”
  2. Waterborne improvised explosive device (IED)—“that a boat will be used as a weapon itself by a suicide bomber” (such as the attack in 2000 on the USS Cole). “Imagine…the consequences of waterborne IEDs against passenger ships, against tankers, against port facilities themselves.”
  3. Weapons’ platform—“boat used as a platform to launch a weapon, such as a short-range ballistic missle,” says Dana Goward, Director of MDA, at the U.S. Coast Guard

Despite these serious security threats, the article discusses the challenges of architecting a balance between increased security/maritime domain awareness (such as through requiring of boating licenses and/or automated identification systems for the more than 17 million small vessels that operate in U.S. waterways) and the desire to “ensure that future regulations don’t compromise boaters’ way of life or disrupt the flow of commerce.”

Of course, there is more than one way to skin a cat, so if security options don’t include boating licenses, Goward states, “the answer could be something as simple as a combination of rules, extra patrols, and increased monitoring on the waterways.”

When it comes to balancing competing interests, nothing is really simple. National Defense Magazine reports that in terms of maritime security, the Congressional Research Service (CRS) report on “Maritime Security: Potential Terrorist Attacks and Protection Priorities,” states that “terrorists are more likely to use small boats for waterborne attacks because they ‘satisfy the overwhelming terrorist requirements for simplicity,” Now, we need to continue architecting solutions that meet these security threats head-on, but at the same time preserve freedoms, our way of life, and support international commerce.

Creating balance between alternate views/needs is one of the biggest challenges, but also has the potential for some of the greatest benefits, because by striking a balance, we have the potential to satisfy the greatest number of stakeholders and optimize our ability to meet conflicting requirements. It’s easy to (as the Nike slogan says) “just do it,” but it’s hard to do it and not mess up something else in the process. For example, it’s relatively easy to do security, if you aren’t concerned with the affect on quality of life, commerce, and so on. However, this is not realistic.

Like all things in life, finding the right balance is an art and a science, and requires ongoing course corrections.


Share/Save/Bookmark

Information Warriors and Enterprise Architecture

In the digital age, information is critical to decision making. This is the case in the board room as well as on the battle field.

Information superiority is critical to our warfighters ability to intelligently and efficiently defeat our enemies. Many of the Department of Defense‘s modernization initiatives are aimed at getting the right information to the right people at the right time. Unfortunately, there are still some information gaps.

National Defense Magazine, December 2007, reports “troops in digital age, disconnected.”

Apparently, not everyone in the military is getting all the information they need (at least, not yet).

The problem often is described as a ‘digital divide’ between the technology haves—the upper echelons of command—and the have-nots---the platoons and squads that are deployed in remote areas. These small units for the most part are disconnected from the Army’s main tactical networks and only are able to communicate with short-range voice radios…[however,] at the top echelons, commanders can tap into loads of data—maps, satellite images, video feeds, and reams of intelligence reports.”

Often though it is the small units on the front lines that need to send and receive critical information on combatants or other situational updates that can have life and death implications. This is why the net-centric strategy for virtually connecting all units is so important to achieving the vision of true information dominance.

Here are just a few important ways that information can help our warfighting capabilities:

  • Providing information to soldiers to locate enemy combatants (such as from “live video from unmanned aircraft)
  • Enabling location tracking of soldiers to save lives when they are endangered (such as from GPS locators)
  • Sending information updates back to command for coordination and enhancing decision capabilities (such as from streaming voice and video, instant messaging, etc.)

The good news is that there are a lot of new information technologies coming online to aid our military, including the Future Combat Systems (FCS) and Joint Tactical Radio Systems (JTRS).

To ensure the success of these technologies, we need to manage the solutions using enterprise architecture to validate requirements, reengineer the processes, and effectively plan and govern the change.

  1. Requirements management—“how to identify essential needs for information as opposed to providing information indiscriminately”
  2. Business process reengineering—according to Marine Corps. CAPT Christopher Tsirlis “it’s not just about the latest and greatest technology but also changing the organization to use new technology.”
  3. Planning/governance—we need link resources to results;“the technology exists, the question is how we resource it, and what is the right amount for each level.”

With a solid enterprise architecture and innovative technologies, we can and will enable the best information warriors in the world.


Share/Save/Bookmark

June 23, 2008

The Water Crisis and Enterprise Architecture

According to Wikipedia: “The Earth has a finite supply of fresh water, stored in aquifers, surface waters and the atmosphere. Sometimes oceans are mistaken for available water, but the amount of energy needed to convert saline water to potable water is prohibitive today, explaining why only a very small fraction of the world's water supply derives from desalination.

There are several principal manifestations of the water crisis.

  • Inadequate access to safe drinking water for about 1.1 billion people
  • Groundwater overdrafting leading to diminished agricultural yields
  • Overuse and pollution of water resources harming biodiversity
  • Regional conflicts over scarce water resources sometimes resulting in warfare

Waterborne diseases and the absence of sanitary domestic water are one of the leading causes of death worldwide. For children under age five, waterborne diseases are the leading cause of death. At any given time, half of the world's hospital beds are occupied by patients suffering from waterborne diseases. According to the World Bank, 88 percent of all diseases are caused by unsafe drinking water, inadequate sanitation and poor hygiene.

How critical is water to life?

While a person can live 4-6 weeks without food, survival without water is limited to between 3-7 days. (http://www.survivaltopics.com/survival/how-long-can-you-live-without-food/)

The Wall Street Journal, 23 June 2008, reports that that a new invention, “The LifeStraw is a personal, portable water purifier,” “that “has the potential to save many lives.”

The LifeStraw was created in 2005, is 10 inches long, and weighs 4.3 ounces. “One straw is capable of purifying at least 700 liters (182 gallons) of water, removing an estimated 99.9% of bacteria and 99% of waterborne viruses.”

This is a game-changing invention:

“The product, which costs as little as $3, has won a number of awards including the 2008 Saatchi & Saatchi Award for World Changing Ideas.”

So simple, yet so effective:

“When someone sucks through the straw, the water flows through textile and iodine filter, which kill off viruses and bacteria.”

Already hundreds of thousands have been purchased and are being distributed in countries with non-potable water.

As an enterprise architect, nothing is more satisfying than seeing an innovation that saves lives and improves the way of life for millions of people around the world.

While we are all introduced to inventions such as those “As Seen On TV” with new doodads for kitchen appliances, household/personal/car-care, tools, and novelty items, the introduction of something truly extraordinary like the LifeStraw just makes one do a double-take.

As an enterprise architect, I believe we need to hold up transformative innovations, such as the LifeStraw, as examples of best-in-class architectures that combine business process improvement with technology innovation that positively impacts millions of otherwise suffering people around the world.

As I go about my day-to-day responsibilities I’d like to keep this one in mind as an inspiring example of what can be achieved when technology is applied to global problems. Perhaps you’d like to do the same!


Share/Save/Bookmark

June 22, 2008

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.


Share/Save/Bookmark

June 21, 2008

Fusion Centers and Enterprise Architecture

An important way to share law enforcement and intelligence information in a physical setting is through fusion centers.

Government Technology’s Emergency Management Magazine, Spring 2008, states “the ultimate goals of any fusion center is to prevent terrorist attacks and to respond to natural and man-made threats quickly and efficiently.”

“Data fusion involves the exchange of information from different sources—including law enforcement, public safety, and private sector—and with analysis, can result in meaningful and actionable intelligence and information…The fusion process allows relentless re-evaluation of existing data in context with new data in order to provide constant updates.”

Fusion centers bring together federal, state, local, tribal, and private sector subject matter experts to share information, provide risk and threat assessments, and provide a coordinated response.

“Nearly every state now has a fusion center to address gaps in data sharing.” In the fusion center, there is real time video monitoring that can be panned and zoomed, GIS mapping capabilities and the ability to amalgamate information. The advantage of the fusion center is that all participant organizations have the potential of seeing and hearing the same thing at the same time—although local authorities “cited difficulties accessing federal information systems.”

Not all fusion centers are permanent; some only are formed to deal with special security events like the Olympics and so forth. But those that do function 24x7 hone the skills of the participants by having them work together in a steady ongoing fashion.

While you would think that technology would do away with the need for fusion centers, since the information can be shared virtually, and therefore participants would not need to be co-located, there are benefits to having people deal with people from other organizations face-to-face.

As a User-centric enterprise architect and one who believes strongly that the human capital perspective is under-appreciated or neglected altogether, I appreciate the need for fusion centers, joint operations centers, interagency coordination centers, and the like to share not only information and technology resources, but to actually work together, cooperate, coordinate, and build stronger ties across functional and organizational silos. This is really what “enterprise” architecture is all about—breaking down the silos and building a unified, more effective and efficient organization.

The fusion center solution acknowledges that the challenge of law enforcement, intelligence, and counter-terrorism efforts needs to go beyond pure information technology initiatives. We can’t afford to just have siloed agencies and organizations working out of their own “corners.” There is a need for people to come together and collaborate in a face-to-face environment.

As architects, there is an erroneous tendency to focus on technology solutions. This is suboptimal. We need to look at business process improvement and reengineering, the introduction of new technology, and continuing to build an ever more skilled, innovative, and cohesive work force. This User-centric EA approach ties to a three-pronged approach of people, process, and technology.

Share/Save/Bookmark

June 20, 2008

Information Addicts and Enterprise Architecture

As an enterprise architect, my job is to develop plans and governance for IT to meet mission/user requirements, which is typically for more and more information. But is more information the answer?

The Wall Street Journal, 12 June 2008, reports on a new book called Distracted by Maggie Johnson, that talks about instant communication robbing “the workday of any sustained interval of unbroken attention to a particular task…from email to instant messaging to Twitter—an-update service devoted to what-are-you-doing-at-this-moment inanity--the interval between interruptions appears to approaching zero.”

“In the workplace, a distracted knowledge worker is a fallow asset.” Ms. Jackson reports that:

  • “Workers ‘typically change tasks every three minutes’ and ‘take about twenty-five minutes to return to an interrupted task…usually plugging into two other work projects in the interim.’
  • By one estimate, ‘interruptions take up to 2.1 hours of an average worker’s day and cost the economy $588 billion a year.’

“Many distractions turn out to be self-initiated: It appears that we just can’t wait to read the next email or blog entry or check to see what might be happening in an online discussion.”

We are addicted to information. On one hand, we want more and more information and complain bitterly whenever we are out of our carrier’s coverage or otherwise not able to use our cell phones, email, or internet connections. And on the other hand, we are so overloaded with information and so distracted all the time, we are walking around with our heads spinning, not knowing what to focus on next. We are true information junkies!

The information overload and incessant disruptions and distractions are not limited to the workplace. No, indeed.

I don’t know about you, but time for me is an endless deluge of everything information, driven by technology (especially email, blogging, professional networking, internet news and search, and so on).

Yet, while we absorb and spit out more and more information, our quality of life seems in many ways worse and worse. The things that are really important like spirituality, family, friends, charitable giving, and health/fitness is eroded by our incessant need for the next information fix.

We run away to getaway resorts, bed-and-breakfasts, and day trips, only to take our Blackberries or worse yet our laptops. We check our email compulsively. We check our networking sites to see where our friends are and what they are doing. We check for the latest information on this, that, and the other thing. We are checking ourselves into a dizzying numbness, where we are losing touch with real people in the real world in lieu of information ubiquity and life in a virtual world. We are losing important pieces of ourselves in our addiction to information.

So what’s an enterprise architect to do?

  • Baseline—awareness is step #1. We need to recognize that we are creating an information addicted society for ourselves and our children. Information ubiquity, if not our current state, is certainly where we are well on the way to. In fact, I’ve seen many organization’s IT strategic plans that specifically state their vision as information 24x7x365 or anytime, anywhere.
  • Target—planning for a better tomorrow. We need to take control and set a target state that balances the “highs” that we get from more and more information, with the need to be better people—better to ourselves and to others, more inclined towards our spiritual needs, physical health, and more in touch with the real world versus the virtual.
  • Transition Plan—getting from here to there. We need to wean ourselves off the constant information fix. It’s easy to get addicted. I had many a caffeine headache until I got myself some decaf beverages. Similarly, smokers often must substitute a nicotine patch for a cigarette. We need to plan time for spirituality, family, friends, and other activities that wean us off the information addiction we have.

Share/Save/Bookmark

June 18, 2008

Employee Onboarding and Enterprise Architecture

The human capital perspective of the enterprise architecture is often overlooked, and is not yet included in the Federal Enterprise Architecture (FEA), but I’m still hopeful.

A recent article in Federal Times, 9 June 2007, called “First Day on the job, first step to retention” demonstrates that human capital architecture is alive and well although not consistently used.

A report by the Partnership for Public Service found that “the government has no consistent approach to bringing new employees on board; new employees often aren’t taught about and initiated into their new agency’s culture; and technology that could ease the process and improve collaboration is underused.”

However, some agencies are coming up with new ways to welcome new employees, make them feel “at home” on the job, get them situated, acclimated and trained, so they quickly become productive employees with longevity at the agency.

For example in setting up the logistics for a new employee, “GAO and NASA have each developed case management systems to track new hires from the moment they accept the offer. The system alerts information technology offices to set up a computer network access and email account for a new employee; facilities staff will prepare an office and desk; and security staffs work in advance to arrange needed clearances.”

The Office of the Comptroller of the Currency (OCC) goes above and beyond when it comes to onboarding. OCC send new hires “a welcome basket with an agency-branded T-shirt, umbrella, luggage tags, and chocolates.” Not a bad introduction for someone starting new in a place.

GAO, NASA, OCC are all good examples of what human capital enterprise architecture is all about. I would suggest growing this list and building it into a FEA human capital perspective.

We cannot take our employees for granted. Their enthusiasm, determination, innovation, empowerment, and leadership is what will drive the organization ultimately to succeed or not.

The enterprise architecture human capital perspective can look at the lifecycle of the employee from recruiting, hiring, and onboarding all the way through their 30+ year careers and into retirement. The enterprise architecture can assess how we manage the human capital lifecycle in the enterprise today, establish a future target state, and develop the transition plan to move the organization towards best practices for managing our most critical asset, our people.


Share/Save/Bookmark

June 15, 2008

Emergency Incident Management and Enterprise Architecture

When a disaster or emergency strikes, who is in charge—federal, state, local, or tribal authorities? Police, fire, rescue, medical services, public works, environmental response professionals? Who has jurisdiction? How is incident response coordinated?

“The National Response Framework (NRF) presents the guiding principles that enable all response partners to prepare for and provide a unified national response to disasters and emergencies. It establishes a comprehensive, national, all-hazards approach to domestic incident re

  • describes how communities, tribes, states, the federal government, private-sectors, and nongovernmental partners work together to coordinate national response;
  • describes specific authorities and best practices for managing incidents; and
  • builds upon the National Incident Management System (NIMS), which provides a consistent template for managing incidents.” (http://www.dhs.gov/)
National Incident Management System:

  • While most emergency situations are handled locally, when there's a major incident help may be needed from other jurisdictions, the state and the federal government. NIMS was developed so responders from different jurisdictions and disciplines can work together better to respond to natural disasters and emergencies, including acts of terrorism. NIMS benefits include a unified approach to incident management; standard command and management structures; and emphasis on preparedness, mutual aid and resource management.” (http://www.fema.gov/)

Government Technology’s Emergency Management Magazine, Spring 2008, reports that “only willing partners coming to the table, treated as equals, will prove effective in establishing a national standard for incident response.”

Why are there so many issues in coordinating incident response?

  1. Miscommunication—“the ideal scenario is that everyone uses the same system and terminology when responding, which allows disparate agencies to come together quickly and avoid miscommunication when confusion ultimately rules—during disasters.”
  2. Jurisdictional egos—“Jurisdictional egos can become involved, along with personal history and interagency ‘baggage.’…it can be messy at best, especially as leaders emerge, each wanting to highlight their agency’s accomplishments and not be superseded by another.”
  3. Lack of interagency and cross-jurisdictional training—“We need joint training, planning and exercises with all potential partners if we’re ever going to fix the issue of unified command…[additionally, there is a] lack of practice in how, in larger, cross-jurisdictional responses, the elected officials aren’t used to working in tandem with other jurisdictions during emergencies.
  4. Subordination is not in the law—“It is not in our nature and governance for one jurisdiction to subordinate itself to another, especially in crisis. As such, the solution will need to be the establishment of mechanisms that allow for joint action via a coordinated response.”

As a citizen, I frankly do not care about responders’ terminology, egos, training, or distaste for subordination—when there is a true crisis, I (like I believe any sane person) wants help to come, come quick, and come effectively. I want lives saved and property safeguarded.

From an enterprise architecture perspective, I acknowledge the challenge that we face in coordinating incident response among a broad spectrum of stakeholders and emergency response experts. However, at the same time, I cannot help but marvel at the current federated system of emergency response. I believe that emergency response needs to mature to one where there is absolute crystal clear chain of command and a solid, unified approach to dealing with disaster. All necessary and appropriate resources need to be brought to bear to help people in disaster and a coordinated response is a must.

Certainly, while there are technical issues in establishing common data standards, mechanisms for information exchange, interoperable systems, and securing these, it seems that the biggest issue is cultural. People and agencies are continuing to function in a siloed mentality despite the clear need for a unified approach to dealing with disasters as well as with the large, complex, and global problems that we face. I believe that this only underscores the need for “enterprise architecture” and that it is becoming more and more obvious that each of us doing our own thing is not going to enable us to solve the great issues of this century.


Share/Save/Bookmark

June 13, 2008

Preventing Another 9/11 and Enterprise Architecture

From the tragic events of 9/11 came the Intelligence Reform and Terrorism Protection Act, the findings of the 9/11 Commission in 2004, and the Presidential memoranda in 2005 and 2007 to better share information.

ComputerWorld Magazine, 26 May 2008, reports that “nearly seven years after 9/11, information-sharing problems that hobble law enforcement are just beginning to be solved.”

What is the information sharing problem in law enforcement?

There are “20 federal agencies and 20,000 state, county, local, and tribal enforcement organizations nationwide.” The problem is how do you get this multitude of varied law enforcement organizations to share information to identify the bad guys?

While 75% of police agencies use automated systems to manage incident report data, only 25% of those systems are capable of sharing that information.

What’s being done to fix the problem?

First (not mentioned by ComputerWorld), the Office of the Director of National Intelligence (ODNI) is establishing common terrorism information sharing standards (CTISS) to drive and enable information sharing among Law Enforcement, Homeland Security, Intelligence, Military, and Diplomatic information domains.

Additionally, the Department of Justice is developing a data dictionary/schema to establish a “common vocabulary and structure for the exchange of data.” First, this took the form of the Global Justice XML Data Model (GJXDM) in 2003, and later took form in the National Information Exchange Model (NIEM) in 2005 that extended the effort from “law enforcement to other areas of justice, public safety, intelligence, homeland security, and emergency and disaster management.” (Note: Defense and the Intelligence Community have a comparable data standard initiative called U-CORE.)

This past March, DOJ and the FBI’s Criminal Justice Information Service (CJIS) division “began rolling out the National Data Exchange Initiative (N-DEx), a NIEM complaint database and data sharing network.” N-DEx provides “federated search capability across incident reports residing in state and local record management systems nationwide while allowing those records to be updated and maintained by their local owners.”

The goal is to have “the majority of the country participating” by 2009. The biggest obstacle is that many agencies’ systems have been so customized that integration is now challenging and expensive.

According to the FBI’s website, NDEx will be accessible via the internet and “includes several basic but vital capabilities, including searching and correlating incident/case report information and arrest data to help resolve entities (determining a person’s true identity despite different aliases, addresses, etc.). N-DEx will also create link analysis charts to assist in criminal investigations and identify potential terrorist activity.”

According to the NDEx brochure (available online at the FBI website), law enforcement agencies who participate in NDEX will:

  • “Sign an operational Memorandum of Understanding (MOU)
  • Identify and map incident/case data to the N-DEx Information Exchange Package Documentation (IEPD)
  • Obtain network connectivity through an existing CJIS Wide-Area Network (WAN) or connect over the Law Enforcement Online (LEO). “

The architecture concept here is summed up nicely by Linda Rosenberg, Director of the Pennsylvania Office of Criminal Justice: “Now you don’t have to go back and build these data warehouses and totally redo your entire infrastructure.”

Instead, you plug in to the NDEx and share information that’s been mapped to the common data standards. NDEx provides the target infrastructure, while NIEM provides the data exchange standards. Together, we can share information for better achieving our law enforcement mission—protecting the American people.


Share/Save/Bookmark

What Goes Around Comes Around and Enterprise Architecture

As an enterprise architect, I have always wondered about the trend of outsourcing our manufacturing jobs out of country-- where as a nation we erode our manufacturing base and ship this capability to China, India, Mexico, and other countries where labor is plentiful and cheap.

Yes, in the short term we are taking advantage of the lower costs of manufacturing in other countries, but long term, I always questioned the viability of this strategy thinking that surely every nation needs to maintain a core of critical manufacturing and service capabilities and infrastructure to guarantee self-sufficiency, protect itself from eventual global disruptions, and ensure the continuity of its existence.

I believe that some day (and maybe relatively soon), we will regret the near-sightedness of our decisions to move production abroad for the sake of the dollar today.

Interestingly enough, I read in the Wall Street Journal today, 13 June 2008, that “stung by soaring transport coasts, factories bring jobs home again.”

“The rising costs of shipping everything from industrial-pump parts to lawn mower batteries to living-room sofas is forcing some manufacturers to bring production back to North America and freeze plans to send even more work oversees.”

I thought to myself—Hallelujah!

No, I am not happy that oil prices are soaring and that inflation is looming everywhere, but I am cautiously relieved that perhaps, we as a nation will wake up in time to secure our economic interests at home and not send our entire manufacturing base and capabilities out of country.

Ironically (da!), the further we move our factories away, the more it costs now to ship the goods back home.

“The movement of factories to low-cost countries further and further away has been a bitter-sweet three-decade long story for the U.S. economy, knocking workers out of good-paying manufacturing jobs even as it drove down the price of goods for consumers. But after exploding over the past 10 years that march has been slowing. The cost of shipping a standard 40-foot container from Asia to the East Coast has already tripled since 2000 and will double again as oil prices head toward $200 a barrel…In the world of triple-digit oil prices, distance costs money.”

The other thought that always kept coming to mind was that as we continue to move manufacturing abroad, the increasing demand for labor would drive the cost of labor up, and eat away at the cost differential making the overseas move a moot point.

Again, I read today in the Journal the story I always felt was bound to be told and to continue to unfold: “The cost of doing business in China in particular has grown steadily as workers there demand higher wages and the government enforces tougher environmental and other controls. China’s currency has also appreciated against the dollar…increasing the cost of products in the U.S.”

One problem with trying to bring the jobs back home…

“Much of the basic infrastructure needed to support many industries—such as suppliers who specialize in producing parts or repairing machines—has dwindled or disappeared.”

What goes around, comes around. The jobs (some) are coming home (although net-net, we’re still losing manufacturing jobs). As a country, we‘ve benefited in the short-term from outsourcing, but in the long-term, I believe we’ll have done ourselves a good deal of harm.

Does this sound unfamiliar?

Think national deficit—big time. Think gargantuan problems with social security, Medicare, health care, and so on.

All too often, we behave with short-sightedness and like infants, the desire for immediate gratification. But as enterprise architects, I believe we need to think long term and often defer gratification for long-term competitiveness, self-sufficiency, and survival.


Share/Save/Bookmark

June 8, 2008

Cognitive Styles and Enterprise Architecture

We are all familiar with personalizing websites like Yahoo.com to make them more appealing, functional, and easy to navigate.

Now, according to MIT Technology Review, 9 June 2008, websites are being personalized not by the person, but rather by systems “that detect a user’s cognitive style” and changes the website accordingly

What is cognitive style?

Cognitive style is how a person thinks. Some people are more simplistic, others more detail-oriented, some like charts and graphs, and some like to be able to see and get to peer advice.

Why is cognitive style important?

Well, if we can figure out a person’s way of thinking and what appeals to them, then we can tailor websites to them and make them more useful, useable, and more effective at selling to them.

“Initial studies show that morphing a website to suit different types of visitors could increase the site’s sales by about 20 percent.”

So what’s new about this, haven’t sites like Amazon been tailoring their offering to users for quite some time?

Amazon and other sites “offer personalized features…drawing from user profiles, stored cookies, or long questionnaires.” The new method is based instead on system adaptation “within the first few clicks on the website by analyzing each user’s patterns of clicks.”

With cognitive style adaptation, “suddenly, you’re finding the website is easy to navigate, more comfortable, and it gives you the information you need.” Yet, the user may not even realize the website has been personalized to him.

“In addition to guessing each user’s cognitive style by analyzing that person’s pattern of clicks, the system would track data over time to see which versions of the website work most effectively for which cognitive style.” So there is learning going on by the system and the system gets better at matching sites to user types over time!

If we overlay the psychological dimension such as personality types and cognitive styles to web design and web adaptation, then we can individuate and improve websites for the end-user and for the site owner who is trying to get information or services out there.

Using cognitive styles to enhance website effectiveness is right in line with User-centric Enterprise Architecture that seeks to provide useful and usable EA products and services. Moreover, EA must learn to appreciate and recognize different cognitive styles of its users, and adapt its information presentation accordingly. This is done, for example, in providing three levels of EA detail for different types of end-users, such as profiles for executives, models for mid-level managers, and inventories for analysts. This concept could be further developed to actually modify EA products for the specific end-user cognitive styles. While this could be considerable work and must be balanced against the expected return, it really comes down to tailoring your product to your audience and that is nothing new.


Share/Save/Bookmark

TEOTWAWKI and Enterprise Architecture

TEOTWAWKI stands for the end of the world as we know it. It is a term used in the survivalist movement and is sometimes used as a reference to the apocalypse. (The apocalypse though has religious connotations in that the end of the world has greater meaning in terms of revealing G-d’s ultimate purpose for mankind.)

The end of the world—is there such a thing?

As mortal human beings, we know that all living things have a beginning and an end of life. Even inanimate objects are recognized as having a lifecycle, and this is often talked about from a management perspective in terms of administering “things” from their initiation through their ultimate disposition. Some common lifecycles frequently referred to are: organizations, products, projects, assets, investments, and so on.

So how about the world itself?

Well, the answer is of course, yes—even the world will one day come to end. Astronomers have long witnessed even the implosion of stars at their end of life—these are called supernovas. And our world is a lot smaller than a star; in fact, you could fit about a million Earths inside our sun (which is a star).

When times get tough, TEOTWAWKI is something that perhaps we ponder about more and wonder whether this is it!

For example, during the Cold War and the buildup of the nuclear arsenals of the Soviet Union and the United States, there were enough nukes to destroy the world ten times over. And people wondered when the button would actually be pushed.

Nowadays, we wonder less about nuclear holocaust and more about overpopulation (currently at 6.3 billion and expected to reach 9 billion by 2042) and depletion of world energy resources like oil (currently at $140 a barrel and up 44% in cost YTD), demand outstripping supply for silver, copper, aluminum, and many other commodities, and shortages of food (as the UK Times reported in February that “the world is only ten weeks away from running out of wheat supplies after stocks fell to their lowest levels for 50 years.”)

Further, while the population continues to explode and resources continue to be depleted, we continue to overflow the world’s dumps with garbage so much so that there has even been talk of sending garbage into space, just to get it the heck out of here!

And let’s not forget global warming and pollutants that stink up our cities, cause acid rain, asthma, and so many other unfortunate effects on the ecosystem and human health.

The good news is TEOWAWKI talk is often just fear and occasional panic and it is not imminent. The bad news is there are some very real problems in the world today.

The problems are so big that leaders and governments are having a difficult time trying to tackle them. All too often, the problems get passed to the next generation, with the mantra, “Let it be someone else’s problem.”

As an enterprise architect, my frame of reference is to look at the way things are (the baseline) and try to come up with a better state for future (the target) and work up a transition plan, and basically get moving.

We all know that it is extremely difficult to see our way through these extremely complex problems of global magnitude. But if enterprise architecture has taught me anything, it is that we must create a roadmap for transformation; we must forever work to change things for the better. We must do whatever we can to prevent TEOTWAWKI.

Perhaps the field of enterprise architecture can be expanded from one that is IT-focused and now becoming business and IT-focused to ultimately becoming a discipline that can drive holistic change for major world problems and not just enterprise problems. Does this mean that enterprise architecture at some point becomes world architecture?


Share/Save/Bookmark

June 6, 2008

Information Sharing Standards and Enterprise Architecture

In response to the 9/11 Commission’s recommendations, the Intelligence Reform and Terrorism Prevention Act (IRTPA) of 2004 called for an Information Sharing Environment (ISE), “an approach that facilitates the sharing of terrorism information” and that requires the President to designate a Program Manager for the ISE and to establish an Information Sharing Council to advise the President and the Program Manager.

The Common Terrorism Information Sharing Standards (CTISS) Program Manual is a construct for ISE. It defines both functional standards and technical standards.

  • Functional standards—According to the CTISS Program Manual, these are “detailed mission descriptions, data and metadata on focused areas that use ISE business processes and information flows to share information.” From an enterprise architecture perspective, I believe this would correspond to the business and information perspectives of the architecture as well as be extended probably to the performance perspective. In other words, functional standards correlate to the three business perspectives of the Federal Enterprise Architecture. These are the standards that define our requirements, in other words, how we measure performance (for example, Balanced Scorecard), how we engineer business processes (for example, Lean Six Sigma), and how we describe information sharing requirements (for example, NIEM or U-CORE, and Information Exchange Package Descriptions).
  • Technical Standards—“methods and techniques to implement information sharing capability…[for] acquiring, accessing, producing, retaining, protecting, and sharing.” From an enterprise architecture perspective, I believe this would correspond to the services, technology, and security perspectives of the architecture. These correlate to the three technical perspectives of the architecture. The technical standards include how systems will interoperate or share information (for example, J2EE, .NET), what technology standards will be employed (for example, XML, SOAP, UDDI) and how security will be assured (for example, various from NIST/FIPS, ISO, IEEE, and so on).

What I like about the CTISS is that it attempts to define a comprehensive framework for the ISE from the highest-level being the domains of information (such as intelligence, law enforcement, homeland security, foreign affairs, and defense) and drills down to the security domains (SBU, Secret, and US-SCI), reference models, (FEA, DoDAF, IC EA…), standard types (metadata, data, exchange, and service), standards bodies (NIEM, W3C, OASIS…), and then the standards themselves.

As an initial impression, I think next steps are to articulate how I share information with you or you share with me. Currently, we are still defining techniques for future sharing of data, like developing metadata, creating a data dictionary and schema, defining exchange standards, and service standards to discover data through registries. It like responding to someone who asks, how do I get to your house, by saying, we need to pave roads, design and manufacture cars or buses, install traffic signs and lights, and so on. That’s all infrastructure that needs to be built. That still doesn’t tell me how I get to your house. While we are making huge progress with information sharing, we’re still at the early stages of figuring out what the infrastructure elements are to share. But it seems to be a running start!


Share/Save/Bookmark

Life Expectancy and Enterprise Architecture

We all hope and pray for a long and healthy life with our loved ones. Unfortunately, when serious illness strikes, the question is how long does a person have to live?

The Wall Street Journal, 6 June 2007, reports that despite all the diagnostic medical tools today, predicting life expectancy is still “a very inexact science.”

While it does not seem odd to me that “doctors often fumble predicting life expectancy” since this is truly only something G-d can know for sure—what is odd is the magnitude of the discrepancy with doctors predictions. “Doctors overestimated dying patients’ survival by a factor of 5.3”!

Why the gross inaccuracy? And can this provide any lessons for enterprise architecture planning?

  • Forecasting is not a science—“Even some of the best scientific studies of some of the more common medical cases points to one conclusion: we don’t really know.” Similarly, with planning business and technology, we can’t really see into the future or around corners. The best we can do is to extrapolate from events and trends. This is more an art than a science.
  • Old/bad data is a poor basis for planning—“Life expectancy data for such patients are dated. ‘True life expectancy with best treatment is constantly changing.’” Similarly, with business and IT planning, events on the ground are constantly changing, so for planning to be even somewhat accurate, you need real time and quality data.
  • Optimism is an exaggeration—Doctors tend to be overoptimistic with their life expectancy predictions, “in part because they tend to be confident in their abilities and hopeful for their patients.” While we can’t give up hope—ever—we should not be overconfident in our abilities. When architecting the organizing, we must try to be as realistic as we can and not look at the enterprise with rose colored lenses.
  • Overlooking the obvious—“Doctors simply overlook the signs of nearing death.” As architects, we cannot overlook anything. We need to be on the lookout for the latest business and technology trends and plan accordingly for the enterprise.
  • Difficulty communicating bad news—“The pain and difficulty of communicating the prediction exacerbates the error…when estimating life expectancy for patients who, it turned out, had about a month to live, doctors tacked on 15 days onto their private predictions.” Enterprise architects need to be good—no expert—communicators. This is important in translating business-technology speak and in charting a course. If the current roadmap is not right for the organization, architects need to articulate the problems, why and how to fix them.
  • Treatment can cause more problems—“Patients and doctors expecting a longer survival time may agree on more invasive treatment, adding the burden of side effects and complications to patients in their final days.” Similarly, as architects, we may see a business process or technology problem and in trying to fix it, end up doing the wrong thing and exasperate the problem. So like doctors, our first pledge needs to be to do no harm.
  • Feedback and quality control—these “could help hone survival estimates.” So to with planning and governance, doing the assessment/lessons learned and performance metrics can be very valuable for improving practices and processes going forward.

Share/Save/Bookmark

June 5, 2008

The Visionary and Enterprise Architecture

In User-centric EA, we develop a vision or target state for the organization. However, there are a number of paradoxes in developing an EA vision/target, which makes this goals quite challenging indeed.

In the book, The Visionary’s Handbook by Wacker and Taylor, the authors identify the paradoxes of developing a vision for the enterprise; here are some interesting ones to ponder:

  1. Proving the vision—“The closer your vision gets to provable ‘truth,’ the more you are simply describing the present in the future tense.”
  2. Competing today, yet planning for tomorrow—“By its very nature, the future destablizes the present. By its very natures, the present resists the future. To survive you need duality [i.e. living in two tenses, the present and the future], but people and companies by their very nature tend to resisting living in two tenses.” “You have to compete in the future dimension without destabilizing the competition [i.e. your ability to compete] in the present and without subverting the core values that have sustained your business in the past.”
  3. Bigger needs to be smaller—“The bigger you are, the smaller you need to be….great size is great power, but great size is also stasis.”
  4. The future is unpredictable—“Nothing will turn out exactly as it is supposed to…yet if you fail to act, you will cease to exist in any meaningful professional or business sense.”

So how does one develop a viable target architecture?

The key would seem to be in deconflicting past, present, and future. The past cannot be a hindrance to future change and transformation—the past must remain the past; lessons learned are welcome and desirable, but the options for the future should be open to innovation and hard work. The resistance of the present (to the future) must be mitigated by continuous communications and marketing; we must bring people along and provide leadership. The future is unknown, but trends and probabilities are possible for setting a way ahead; of course, the target needs to remain adaptable to changing conditions.

Certainly, any target architecture we develop is open to becoming a "target" for those who wish to take pot shots. But in an ever changing world and fierce global competition, we cannot sit idle. The architecture must lead the way for incremental and transformative change for the organization, all the while course correcting based on the evolving baseline and market conditions. EA is as much an art as it is a science, and the paradoxes of vision and planning need to be managed carefully.


Share/Save/Bookmark

June 4, 2008

Good to Great and Enterprise Architecture

What makes a good organization become great in terms of technology?

In the book, Good to Great by Jim Collins, the author describes a five year study conducted in organizational greatness and what makes a good enterprise become great. Here are some finding in terms of achieving technology success:
  • Align technology with your mission—the key question that drives the enterprise’s technology is whether it fits directly with “what you are deeply passionate about…what you can be the best in the world at…[and] what drives your economic engine.”Through the User-centric EA target architecture, transition plan, and IT governance, EA moderates new investments in IT so they align with mission requirements and priorities.
  • Technology enables mission execution—“Good-to-great companies used technology as an accelerator of momentum, not a creator of it…a company can’t remain a laggard and hope to be great, but technology by itself is never a primary cause of either of greatness or decline." User-centric EA synthesizes business and technology information to enhance decision-making. EA ensures that the organization’s technology direction and investments enable mission.
  • Culture of discipline—Good-to-great companies have disciplined thought and action. They “respond with thoughtfulness and creativity, driven by a compulsion to turn unrealized potential into results; mediocre companies react and lurch, motivated by fear of being left behind." User-centric EA is a structured approach to managing and integrating business and technology. EA ensures that the organization follows an adaptable plan and does not get lurched around by the changing market, competition, or technology tides.
  • Change incrementally—“‘crawl, walk, run’ can be a very effective approach, even during times of rapid and radical technological change.” User-centric EA develops the target and transition plan for the organization, which ensures an approach of incremental change. New IT investments and business process improvements are done in a phased approach, rather than trying to “eat the elephant in one bite.”
In short, User-centric EA is a perfect fit with the conclusions of Jim Collins research into good-to-great companies.
Share/Save/Bookmark

June 3, 2008

24 Hour Knowledge Factories and Enterprise Architecture

Enterprise Architecture is strategic information asset base that defines the business, information necessary to operate the business, technologies necessary to support the business operations, and transitional processes for implementing new technologies in response to the changing needs of business."

In the information economy we live in today, information is certainly an asset with expected returns for the numerous businesses in the services sector and the millions of people working as knowledge workers.

The Wall Street Journal in conjunction with MIT Sloan School of Management on 15 September 2007 reports that “today, we are witnessing the advent of the 24-hour knowledge factories…thanks to more robust information technology and a growing acceptance of offshoring, the concept is feasible.”The key to the organization being able to support 24 hour (round the clock) knowledge work is to have “an online repository of information accessible to all groups.”

What makes for a successful knowledge repository for sharing information between sites and teams?

  • Acquisition— capturing all relevant knowledge that can support users knowledge work.
  • Discovery—making data discoverable so it can be mined for those nuggets that can aid in job performance.
  • Management—developing data standards including a common lexicon and metadata to deal with differences in semantics and formats.
  • Dissemination—making the information accessible for standardized reporting or ad-hoc queries.
In User-centric EA, we are in the information business (providing information for planning and governance). And whether or not the information is needed 24.7, or during "regular" business hours, we need to develop information products, relate the data in useful ways, and make the information easy to understand and readily accessible to end-users. To do this, a robust EA knowledge center or repository is essential.
Share/Save/Bookmark

June 1, 2008

When the Plan Fails and Enterprise Architecture

Enterprise architecture develops the roadmap for the organization and no roadmap is foolproof. With any roadmap, sometimes there’s a traffic jam, an overturned tractor-trailer, or a washed-out bridge. Whatever the scenario, the EA plan is not the right way to go all the time, every time. That is why the plans need to be agile and responsive to the events as they unfold on the ground.

Similarly, in our personal lives, not every road we take is going to lead us to success. In business school we learn that 90% of new businesses fail within the first 5 years. Nowadays, even marriages fail at a rate close to 50%. And according to ExecuNet, the “average executive tenure is less than four years…[and] 18% of executives do not survive their first year in a new job.” So as individuals and as organizations, we can plan for success, but there are no guarantees.

Fortune Magazine, 9 June 2008, reports “a reversal or two can pave the way to triumph…[or] adversity makes you stronger.” Here’s how you can persevere in the face of adversity (adopted from Fortune, but my thoughts on what they mean):

  1. Calculated risk taking—just because you or your organization fails at something, doesn’t mean it’s the end of the line. You have to pick yourself back up onto the proverbial horse and start riding again. It is risky to keep trying, of course. Life is full of risks. You can’t avoid risk. So you take calculated risks and keep trying until you succeed.
  2. Get rid of the naysayers—doubters and naysayers can take the wind out of your plans and ambitions. Yes, listen to reason and experience and learn from it. But don’t just abandon your dreams. If you believe you can do something and can make a difference, you owe it to yourself to try.
  3. Live a purpose-driven life—similar to an organization needing a mission, vision, strategy, and architecture to provide a purpose and roadmap for the organization, so to an individual needs a purpose and a plan to advance their personal goals and aspirations.
  4. Visualize success—I’ve heard this one many times used successfully for those in sports, entertainment, going into interviews, and even those with illness and disabilities. You have to train your mind to think, feel, and actualize the success experience. If you can just visualize success, you are truly a step closer to it.
  5. Lessons learned---We all make mistakes. It’s part of being human. The key though is to learn from those mistakes, so that you do better the next time around. Life’s lessons build on each other. That’s why with age comes wisdom. Experience can go a long way to a new round of success.
  6. Failure is not a life sentence—While we may certainly feel that failure is the end of the world, more often than not, failure is temporary. We’ve got to see past the failure—see the light at the end of tunnel and make our way toward it. That light is success waiting for us.

In the end, we have to be strong to deal with the bumps and bruises we call life. I see enterprise architecture as a structure for dealing with risk and uncertainty. In its most simplistic form, identifying where you are, setting a target of where you want to go, and charting a course to get there is a lens that we can use in almost every aspect of our organizational and personal lives. Rather, than wandering along aimlessly, let’s set a path and try to have an interesting journey filled with learning, growth and hopefully some success for our efforts.


Share/Save/Bookmark