What Not to Tell Your Boss and Enterprise Architecture

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

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

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

What Not to Tell Your Boss and Enterprise Architecture

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.

Fusion Centers and Enterprise Architecture

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.

Information Addicts and Enterprise Architecture

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.

Employee Onboarding and Enterprise Architecture

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.

Emergency Incident Management and Enterprise Architecture

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.

Preventing Another 9/11 and Enterprise Architecture

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.

What Goes Around Comes Around and Enterprise Architecture

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.

Cognitive Styles and Enterprise Architecture

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?

TEOTWAWKI and Enterprise Architecture

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!

Information Sharing Standards and Enterprise Architecture

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.

Life Expectancy and Enterprise Architecture

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.

The Visionary and Enterprise Architecture

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.

Good to Great and Enterprise Architecture

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.

24 Hour Knowledge Factories and Enterprise Architecture

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.

When the Plan Fails and Enterprise Architecture

Occam’s Razor and Enterprise Architecture

“Occam's razor (sometimes spelled Ockham's razor) is a principle attributed to the 14th-century English logician and Franciscan friar William of Ockham…The principle is often expressed in Latin as the lex parsimoniae (‘law of parsimony’ or ‘law of succinctness’)..This is often paraphrased as ‘All other things being equal, the simplest solution is the best.’… it is more often taken today as a heuristic maxim (rule of thumb) that advises economy, parsimony, or simplicity.’” (Wikipedia)

In Occam’s razor, “razor refers to the act of shaving away unnecessary assumptions to get to the simplest explanation.”

Thomas Aquinas made a similar argument in the 13th century: "If a thing can be done adequately by means of one, it is superfluous to do it by means of several; for we observe that nature does not employ two instruments where one suffices." (Pegis, A. C., translator (1945). Basic Writings of St. Thomas Aquinas. New York: Random House, 129.)

The principle of Occam’s razor is very applicable to enterprise architecture—how?

Occams razor is a call for simplicity, and this principle is a foundation for enterprise architecture in terms of consolidation, integration, and cost efficiency and takes specific form in terms of:

• Systems interoperability and component re-use
• Technology standardization and simplification

Paul O’Neill, the former Secretary of the Treasury was a true advocate of Occams razor and frequently asked “if not one, why not one?”

“The philosopher of science Elliott Sober once argued along the same lines as Popper, tying simplicity with ‘informativeness’: The simplest theory is the more informative one, in the sense that less information is required in order to answer one's questions.” (Wikipedia)

In this sense, Occam’s razor is a validation for User-centric Enterprise Architecture, which seeks to make information simpler, easier to understand, and generally more valuable and actionable to the end-user to enhance decision making. Moreover, Occam’s razor is also evident in User-centric EA application of principles of communication and design like simplifying complex information and maximizing use of information visualization in order to more effectively communication EA information.

Occams razor makes clear the need to transform from traditional EA’s development of “artifacts” that are often difficult for the user to understand and apply and instead develop more useful and usable information products and governance services.

Occam’s Razor and Enterprise Architecture

Eisenhower and Enterprise Architecture

Dwight David Eisenhower (October 14, 1890 – March 28, 1969), nicknamed "Ike", was a five-star General in the United States Army and U.S. politician, who served as the thirty-fourth President of the United States (1953–1961). During the Second World War, he served as Supreme Commander of the Allied forces in Europe, with responsibility for planning and supervising the successful invasion of France and Germany in 1944-45. In 1951, he became the first supreme commander of NATO. As a Republican, he was elected the 34th U.S. President, serving for two terms. As president, he oversaw the cease-fire of the Korean War, kept up the pressure on the Soviet Union during the Cold War…” (Wikipedia)

Dwight D. Eisenhower said that “in preparing for battle I have always found that plans are useless, but planning is indispensable.”

What does this mean when it comes to User-centric EA and target architecture and transition plans?

1. Plans are agile—you can plan, but you can’t control the situation on the ground. Therefore, EA plans are by definition undependable. A plan developed for one situation may be completely useless or actually counterproductive in another set of circumstances. Further, there are essentially infinite factors in every scenario and you can’t plan for every combination and permutation. Therefore, you can never really plan effectively, since in some aspects, the plan will always be off.
2. Planning is a learning process—while a specific EA plan itself may ultimately be useless, the planning process itself is extremely valuable. Bringing subject matter experts and stakeholders together to brainstorm, evaluate various scenarios, analyze alternatives, and “hash it out” helps everyone involved to understand the objectives, the battleground, the force structure (assets), and unify everyone around a common way ahead. This is the true value of planning.

In the end, EA plans must be agile and adaptable to the specific situation on the ground, as it evolves. If the planning process has been taken seriously (and not just another annual offsite event), then everyone involved grows professionally, learns about the status of the organization today, and unites around a common way ahead. For this to happen, the planning process needs to be well-structured, yet open to innovative ideas, best-practices, and benchmarking, and should involve a diverse group of subject matter experts. If the planning process is sound, then even if the plan needs to change based on circumstances on the ground, the people involved are able and prepared to adapt.

Eisenhower and Enterprise Architecture

Design and Enterprise Architecture

Design, style, and innovation are important communication mechanisms and are crucial to User-centric EA. These communication mechanisms are used in information visualization and is heavily used in EA to develop useful and usable information products that can be easily understood and applied.

Increasingly, design is taking center-stage across technical and everyday products in our economy.

The Wall Street Journal, 4 January 2008, reports in no less than three separate articles on the importance of design and style for everyday products from computers to hard drives and even storage containers.

Here are some examples from a front page article titled, “PCs Take a Stylish Turn in Bid to Rival Apple”:

• “Dell is trying to inject a sense of style into the company’s PCs, with new shapes, sizes, and color.”
• PC Makers are “racing to replace boring boxes with sexy silhouettes that will differentiate their products, entice new buyers, and command higher prices.”
• Forrester Research “issued a report last June heralding a new ‘age of style’ in the PC market. It concluded that more attractive models could command $150 to $200 more.”
• “During most of the industry’s 30-year history, PC makers didn’t worry much about style. A bigger challenge was boosting technical performance and wringing costs from suppliers.” Now an Intel anthropologist states “there is a sense of, ‘Oh my G-d, why does this have to be so ugly?’”
• Lenovo stated that now “designers have equal weight at the table.”
• Dell has gone from 6 designers in 2001 to 90 designers now and they are still recruiting.
• At the upcoming Consumer Electronics Show, Microsoft will hold a PC ‘fashion show’ with judges picking the top three designs.

Additional articles the same day point to the importance of design and style. For example, the article “Can a Hard Drive Make a Fashion Statement” states that Seagate “kicked off a new strategy at the 2007 Consumer Electronics Show, offering drives with sleek shapes and lights to woo users accustomed to iPod-like elegance.” And in another article titled, “The Struggle to Contain Ourselves,” about the briskly growing $6 billion storage and organization industry where “style is increasingly important” and “once just plastic bins in industrial blue or clear, specialized storage products are now available for most conceivable uses in an array of material, from bamboo to faux leather to sea grass.”

While certainly consumer products are different than information products provided by EA, there is clear understanding now that design, fashion, style, and innovation are critical in reaching out to people, getting them interested in your products (consumer or information), and that design demands a premium in the marketplace. As the Intel anthropologist stated “why does this have to be so ugly?” Similarly, I would ask why do traditional EA products have to so often be so ugly, difficult to understand and apply. Let’s transition the way we do architecture to User-centric EA and design innovative information products that capture our users’ attention, really “talk to them,” clearly identify problem areas, propose alternative solutions, and lead to better decision making. Our executives are busy people with challenging jobs. We owe it to them to provide information in User-centric EA ways.

Design and Enterprise Architecture

Blogs and Enterprise Architecture

Well this is interesting to write: a blog about blogging ;-)

Blogs are becoming a great new tool for enterprise communications and an alternate to clogging up already full email boxes.

CIO Magazine, 15 January 2008, states that “enterprise users can get lost in storms of ‘reply-all’ e-mails while trying to manage projects. Blogs offer a better way.”

The group president of systems and technology for Bell Canada says that “email, used by itself just doesn’t cut it anymore for project management and interoffice communication.”

What’s the interest level and use of blogs?

Forester Research reports that “54% of IT decision makers expressed interest in blogs. Of companies that had piloted or implemented blogs, nearly two-thirds (63%) said they used them for internal communications. Fifty percent said they used blogs for internal knowledge management—and these companies are leading the way of the future.”

A software social consultant says that “traditional enterprise solutions were designed to keep IT happy. They’ve not usually designed with any thought to the user, like a blog is.” What a nice user-centric EA concept, design technical solutions that meet user requirements; let business drive technology, rather than doing technology for technology’s sake.

Why do people resist blogs?

“People are hung up on this concept of the blog as a diary and as an external marketing medium,” rather than understanding its criticality as a tool for communications and knowledge management.

How can you advance the use of blogs in your organization?

1. Calming the troops─if people are nervous about blogs, consider avoiding the term blog and call it an ideaboard or some other non-technical and non-threatening name.
2. Security and compliance—build the blog behind the corporate firewall and “establish rules of engagement,” so that proper social and legal etiquette is not violated and passive-aggressive behavior or “web rage” is mitigated.
3. Start small—“blogs catch on virally, when you need to introduce the idea to the right test group, which will evangelize the idea to the rest of the enterprise.”
4. Tagging—have people “tag their posts with keywords that will help later with search and discovery needs.”

From an EA perspective, blogs are not a substitute for email; we need email (some of us desperately, like a morning cup of joe), but blogs are a great complementary tool for participatory communications that involve discussion type interaction by more than two users or for capturing enterprise knowledge and making it available for discovery. Also, blogs are a tool that gives a voice to people, who may otherwise remain part of the silent masses; people feel freer to express themselves in blogs, and through freedom of expression comes advancement of ideas, greater buy-in, and better enterprise decision-making.

Blogs and Enterprise Architecture

Backup and Recovery and Enterprise Architecture

Anyone who has lost information on their computer knows how important backing up your computer work is, and organizations spend large sums of money to back up corporate information assets.

ComputerWorld, 4 February 2008, reports that “Corporate IT Warms Up to Online Backup Services.”

It used to be everyone backed up their own data, but now things are changing with major storage vendors entering the online backup market.

Now the benefits are beginning to outweigh the costs:

• Cost savings on specially skilled personnel and equipment for backup and storage administration function
• Productivity gains from outsourcing the systems administration and backup
• Unlimited corporate storage capacity

The information security officer at the University of San Francisco states: “If you asked me three or four years ago [about backup], the economics would say, ‘build it yourself.’ However, as storage vendors enter the online storage business and work to address IT concerns [such as pricing and security], ‘I can’t imagine anyone doing it themselves.’”

Gartner says “the technology is slowly becoming more attractive to large companies, thanks to move into the hosted storage business by EMC and storage and backup rivals such as IBM, Iron Mountain Inc, Symantec Corp., and Seagate Technology LLC.”

“IDC predicts that sales of hosted backup storage services will reach $715 million in 2011, up from $235 million in 2007.”

Vendors are moving quickly to address the following issues:

• Acceptable pricing
• Security including encryption and authentication
• Bandwidth

So are hosted backup services worth the cost?

The vice president of operations and compliance officer of Lisle Savings Bank says “I’m not going to say it cheap; it’s not. [But] we felt what are paying for is really insurance against losing data. I used to cringe when anybody deleted a file and I had to find the tape.”

The IT director of a Fort Worth, Texas law firm noted that “the move to the hosted service quickly blunted management concerns about disaster recovery in the tornado-prone area. The online option also ensures that backup tapes will not have to be stored by a vendor that could carelessly allow them to be lost or stolen…It’s the wave of the future, if it’s not already here.”

From a User-centric Enterprise Architecture perspective, we must ensure the security of business and technical assets. This includes the confidentiality, availability, integrity, and privacy of corporate information. One way to protect vital information assets is through robust information backup and recovery services.

Backup and Recovery and Enterprise Architecture

Managing Human Capital and Enterprise Architecture

Human capital is one of the perspectives of enterprise architecture that I have been advocating for the Federal Enterprise Architecture to adopt.

ComputerWorld, 19 May 2008, has a good article on “How to Manage Brilliant People,” which can be applied to all everyone—brilliant or not.

Here are some of the best dos and don’ts (in my own words for the most part) and my two cents on them:

1. Manage results, not process—Identify the results you’re looking for, but don’t prescribe to others how they need do it. This is micromanagement plain and simple. I don’t like to be micro-managed and I don’t think others do either. Treat people like adults and give them the freedom to do their jobs (assuming they haven’t abused that freedom and trust in the past).
2. Vet ideas, then make a decision—Communicate with your staff openly and creatively. Everyone on the team has good ideas and can contribute to analyzing problems and working out viable solutions. Not everyone will agree on the solution, so after a reasonable discussion and analysis, it time for the manager to make a decision. Analysis paralysis is detrimental to you, your team, and your program. Better to make a timely decision and then course correct as new facts become available, then to wait and wait and wait. Time is a critical success factor for most important decisions. The marketplace waits for no one.
3. Be a good mentor, and learn from everyone—We all have something to teach others and to learn from others, because we all have strengths and weaknesses. It doesn’t matter if you’re the boss or the subordinate. For the boss, it takes a degree of humility and open mindedness to “be bested” and more than that to actually learn from it.
4. Admit what you don’t know, not just what you do know—Generally, we all are more than in a hurry to mouth off what we know and show off what we can do. But how many of us are quick to admit what we don’t know? It takes a degree of maturity to say that I don’t know, but I’ll find out and get back to you, and not “feel insecure and threatened.”
5. Raise the bar, and stretch your staff—Just like when setting organizational goals, you want them to be achievable, yet ambitious, so too with setting personal and team goals, they should be challenging, but doable. That way you keep productivity high and morale high and people know they are growing (not stagnant).

At a manager in the IT world, I have learned that technically, pretty much we can do anything (given the time and resources); however, the trick to good management is not the technical stuff, but rather the people stuff. People can be more complicated than landing a man on the moon that’s why we need solid leaders, plenty of management training, compassion and empathy for people, and the institutionalization of human capital as part of our everyday EA planning.

Some early things that I would suggest in developing a human capital perspective in architecture would be:

1. Identifying best practices and benchmarking leadership and management performance against them;
2. Establishing a framework for professional development and training in these areas;
3. Identifying key knowledge, skill, and ability areas for the organization;
4. Inventorying employees against #3;
5. Identifying gaps;
6. Creating alignment between function and talent; and
7. Developing performance plan templates so that everyone understands their roles, goals, and the rewards available to them for high performance.

Of course, there is much more that can be done, and this is only a beginning. This is something that I am very interested in and about which I would welcome any comments and feedback.

Managing Human Capital and Enterprise Architecture

Compassionate Change and Enterprise Architecture

Enterprise architecture, as John Zachman said, is about managing change and complexity.

Naomi Karten has an interesting op-ed in ComputerWorld, 19 May 2008, on change management.

Naomi writes: “managers don’t want to have to deal with the resistance and objections and pushback and grousing and grumbling that so often accompany change efforts.”

Change causes angst (hey, we’re all human!):

“The reality, however, is that turbulence is a fundamental part of the change experience. Replace what’s familiar and predictable with that which is unfamiliar, confusing, ambiguous or potentially risky, and people react…Almost any change (and sometimes even just the rumor of a change) upsets the relative equilibrium.”

Reaction to change is deep and occurs on many levels:

“People’s reactions are often more emotional and visceral than logical and rational. Some people display shock, anxiety, fear or anger. Some become preoccupied, absent-minded, forgetful, distracted or fatigued—even if they view the change as positive.”

Change management is important to successfully implementing change, modernization, and transformation:

“You can’t eliminate the turbulence. But you can minimize the duration and intensity of the turbulence, and therefore implement the change more smoothly and with less gnashing of teeth.”

So how do we help people see their way through change?

“What people need most in order to cope is communication in the form of information, empathy, reassurance and feedback.”

Aren’t adults really just big children, with fear and anxiety over the unknown? (Remember the “bogeyman” under the bed?) How many of you with children hear them express some nervousness right before the first day of a new school year or going to a new school or summer camp. It’s human nature. We are creatures of habit; change the structure we are used to and we’re like fish out of water, working just to catch our breath.

The truth is, all human beings are mortal and can be hurt by change. Cut them and they bleed. Pull the rug out from under them and they can fall on their face, especially if they don’t know first that the rug will be moving! That’s what change is—it’s moving the pieces around and expecting a person to know where things are.

As enterprise architects, leaders, change agents, it is crucial that we treat people with respect, dignity, equality and compassion. Yes, “business is business,” but we can elevate ourselves above the everyday tough business decisions, and recognize that our authority, initiatives, and change efforts have a human impact that we need be sensitive to. Part of enterprise architecture therefore needs to be building communication and sound human capital management into our IT planning and governance processes. For example, our transition plan to move from the baseline to the target state needs to not only address business process improvement and technology modernization, but also human capital management.

People need to worked with. They need to understand the changes taking place and how they fit in. They need to have time to adjust. They need support and encouragement. They need to be treated with humanity. Let’s not lose this in our effort to reach for the future state of the organization.

Compassionate Change and Enterprise Architecture

The Business Analyst and Enterprise Architecture

A business analyst or "BA" is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the business analyst typically performs a liaison function between the business side of an enterprise and the providers of [IT] services to the enterprise. (Wikipedia)

Business analysis is critical to enterprise architecture, because it derives the business functions, processes, activities, and tasks. Coupled with some basic data and systems analysis, BA determines the information requirements of the business and the systems (manual or automated) that serve those up. Through business analysis, we identify gaps, redundancies, roadblocks, and opportunities which are used by enterprise architecture to drive business process improvement, reengineering, and the introduction of new technologies.

Where does the business analyst reside in the organization—in the business or in IT?

The answer is yes to both. The business analyst resides in the business and works on segment architecture for their lines of business and on defining functional requirements. Some business analysts also reside in IT as a relationship manager to translate business-speak to the techies and vice versa. Also, the LOBs may not have business analysts on staff and may request this service be performed by the IT shop. For example, this may be done from the enterprise architecture function to support segment architecture development or alignment to the enterprise architecture. Or it may be done by the IT centers of excellence that develop the systems solutions. If they can’t get the functional requirements from the LOBs, they may send in their own BAs to work with the programs to help capture this information.

ComputerWorld Magazine, 12 May 2008, asks “Is there a place for business analysts in IT today?” And answers, “Not if their primary function is just to analyze business needs…business people want more than analysis; they want workable solutions.”

So aside from business analysis what do you need to come up with a technical solution?

• Resources—$$$$, smart people, the right infrastructure! (this one’s mine, the other two below are from ComputerWorld)
• Creativity—“come up with ideas…to create systems that can meet performance requirements.”
• Synthesis—“best ideas are evaluated and modified until good solutions are found.”

According to the ComputerWorld article, a single person who does the analysis, the creativity, and the synthesis is called a systems designer, but I disagree with this. The analysis and development of the requirements is “owned” by the business (even if IT is called upon to help with this function). While the creativity and synthesis, which is the technical solution, is “owned” by IT. Further, it is typically not a “single person” that develops the requirements and comes up with the solution. The solutions provider (IT) is generally distinct from the business that has the needs, even if sometimes it is difficult for them to articulate these into functional requirements.

ComputerWorld specifies four techniques for identifying requirements and developing a solution:

1. Group facilitation—“getting input from everyone who might have relevant information and insights on a business process.”
2. Process mapping—“create diagrams that capture task sequences for existing and new workflows.” (I believe we in EA all know this as Business Modeling).
3. Data modeling—“diagram the structure of the data those workflows operate in.”
4. User interface prototyping—“use prototypes of user interface screens to illustrate how people can interact with the system to do their jobs.” (Frankly, I don’t believe this one fits with the other three, since prototyping comes somewhat down the road in the SDLC after conceptual planning, analysis, and design. I would replace prototyping with some core system modeling to fill out the business, data, and system model set, so that we can see what systems are currently in use and where the gaps and redundancies are, and where there is potential for component or system re-use and building interoperability.)

I would suggest that 1 and 2 (the facilitation and business modeling) are the functions are the business analyst, but that 3 and 4 (data and systems modeling) are the responsibility of the IT function. Again, it is the business that “brings” the requirements and the IT department that comes up with the technical solution to meet those requirements.

Another thought: Perhaps the organization is struggling with defining the business analyst and those that develop the technical solution because it is really the synthesis of the two that is needed. It is similar to enterprise architecture itself, which is the synthesis of business and technology to enable better decision making. I can envision the further development of segment and solutions architecture to become just such a function that merges the requirements (business) and solutions (IT).

The Business Analyst and Enterprise Architecture