Tower of Babel and Enterprise Architecture

“And the whole earth was of one language, and of one speech…and they said, go to, let us build us a city and a tower whose top may reach unto heaven…and the Lord said…the people is one and they have all one language, and this they begin to do, and now nothing will be restrained from them, which they have imagined to do…[and he] confounded their language, that they may not understand one another’s speech. So the Lord scattered them abroad from then upon the face of all the earth.”

Am amazing story from the Torah (Bible)!

As an enterprise architect, some lessons that are striking to me are the following:

• LEXICON: When everyone has a common language or lexicon (something we strive for in EA), “nothing will be restrained from them, which they have imagined to do.”—i.e. with a common enterprise lexicon, data standards, and mechanism for discovery and exchange, we can do great things and our imagination is the limit.
• EA PLANNING: When everyone functions together (“the people is one”) to undertake a tremendous task (such as building a city and a tower), they can really get things going. As the adage states: there is power in numbers. From an enterprise architecture standpoint, when the enterprise is unified in its planning and governance, they can achieve amazing business and technical feats.

A major question that I am left with is…

Why is G-d displeased when people work together, communicate (the same language), and undertake to follow their imagination (have a vision) and achieve great things (“build a city and a tower”)?

From a religious didactic stand point, I understand that G-d wants us to be humble and not think that we have any real power to take on these tasks without him! And that we have to recognize and worship him (where all power and vision ultimately comes).

From a User-centric EA perspective, the ideals of unifying the organization towards common business and technical plans, goals, standards, solutions, lexicon, and so on, helps us build a better, stronger organization that can achieve great things (as long as we always remember that we are doing HIS bidding).

Tower of Babel and Enterprise Architecture

Adam Smith and Enterprise Architecture

Adam Smith, known as “The Father of Economics”, is best known for his "laissez-faire" economic theory. Smith believed in the right to influence your own economic progress freely, without the puppet strings of guilds and/or the state. His theory caught on and changed much of Europe into a free trade domain, allowing the emergence of the entrepreneur. Smith's work helped to build the foundations of free market economics that includes:

• Capitalism (an economic system in which the means of production—land, labor, and, capital—are privately owned and operated for profit, and in which production and distribution of goods and services are determined through the operation of a ‘market economy’—free markets and free pricing system)
• Libertarianism (belief that all persons are the absolute owners of their own lives, and should be free to do whatever they wish with their persons or property)
• Free Trade (trade in goods and services between or within countries flow unhindered by government) (Adapted from Wikipedia)

“Smith laid the intellectual framework that explained the free market and still holds true today. He is most often recognized for the expression "the invisible hand," which he used to demonstrate how self-interest guides the most efficient use of resources in a nation's economy, with public welfare coming as a by-product. To underscore his laissez-faire convictions, Smith argued that state and personal efforts, to promote social good are ineffectual compared to unbridled market forces.” (lucidcafe.com)

Here’s the User-centric EA question…

Based on Adam Smith’s framework for an efficient free market unencumbered by the state, how are we to view enterprise architecture planning and governance “hindering” the organizational end-users from making the ‘best’ choices for what systems, products, and standards they want to purchase or use? Based on Smith’s notion of "laissez-faire", doesn’t the end-user know best? And won’t they make the most efficient use of corporate resources? Why does EA ‘interfere’?

The answer is…

The end-user does know best and we do need to let them ‘guide’ decision-making. However, there is a difference between letting them guide decisions and pursuing their own interests completely unimpeded. We do not have to use a great amount of imagination to recognize the wasteful spending on redundant solutions, stove-piped data and applications, and inefficient processes that would exist.

• Taken to an extreme, if all users in the enterprise would purchase and implement whatever business and technology solutions they desire, without any form of governance what-so-ever, you would have total chaos!

So the User-centric EA view is that we put the user front and center in the decision process. We work diligently and ongoingly to understand user requirements. And as architects, we work to satisfy those requirements by rationalizing them, enforcing enterprise standards, developing enterprise solutions, and looking out for the greater good of the enterprise. This is the great EA balancing act!

Adam Smith and Enterprise Architecture

Building a Winning Team and Enterprise Architecture

To build a winning team for developing and maintaining a successful User-centric EA program, there are 7 key positions:

1. Chief Enterprise Architect (CEA)—The CEA is the executive responsible for leading the enterprise architecture program; the CEA has the vision and the ability to communicate and execute on that vision.
2. Requirements Manager—The requirements manager is the individual who is responsible for understanding the users’ requirements for EA information, planning, and governance.
3. Solutions Manager—The solutions manager is responsible for developing EA products and services to fulfill (superbly) the requirements of the end-users.
4. Configuration Manager—The configuration manager maintains the relevancy of the EA products by ensuring they remain current, accurate, and complete.
5. Communications Manager—The communications manager markets and communicates all EA products and services, and is responsible for end-user training and outreach.
6. Technical Writer—The technical writer produces EA product textual content for all EA communications media (such as the website, printed handbook, policy, practices, and so on)
7. Graphic Designer—The graphic designer creates innovative visual and graphics displays for EA products, especially profiles (high-level, strategic views of the EA) and models (mid-level EA views that show relationships of processes, information flows, and system interoperability.

Of course, there are many others on the EA team that contribute to its success, including all the architects, analysts, planners, and data specialists.

Together, the 7 key positions and various specialists develop the organization’s User-centric EA and focus on helping the organization execute its mission and generating value to the enterprise through information, planning, and governance.

Building a Winning Team and Enterprise Architecture

Getting People to Use Enterprise Architecture

There is a terrific white paper from the National Institute of Health (NIH) called Enterprise Architecture: Engaging and Empowering People while Creating Opportunity for Change.

NIH conducted a qualitative research study involving 15 users to understand how user behave and work in order to identify opportunities to foster adoption of EA.

First, NIH identified a clear mandate to not only develop and maintain EA, but for its end use:

“Enterprise Architecture (EA) is a critical part of IT strategy in any organization. However, just defining enterprise architecture doesn’t bring its true value of efficiency to the organization nor support for the organization’s strategic objectives. In the EA Assessment Framework 2.0 published by the Office of Management and Budget (OMB) in December 2005, three capability areas, Completion, Use, and Results are defined as primary objectives of every government agency’s EA program. It is clear that EA is not just an assignment for CIOs to document architecture standards for the agency—for the future value to be realized, it must be used to achieve results.”

Second, NIH identified 3 user segments that are each looking toward the architecture for satisfying different needs. (While the study views all three segments as belonging to EA, I believe that only the first is EA, while the other two are segment and solution architecture.)

• Trend Finders—want to know “where we are going?” They are interested in understanding the current and future business and IT landscape. (I believe this equates to enterprise architecture and its focus on developing the as-is, to-be, and transition plan.)
• Fit Seekers—want to know “Does it fit my projects?” They want to find a solution for the project. (I believe this equates to segment architecture and its focus on developing solutions at the line of business (LOB) level.)
• Fixer-Doers—want to know “How to make it work?” They want to build, maintain, or support a project. (I believe this equates to solutions architecture and its focus on developing technical project solutions for the end-user.)

While the study posits that user segments are not mutually exclusive and that users can actually evolve from one segment to another (and of course this is possible in some cases), I believe that generally speaking the segments do represent unique architecture perspectives in the organizations (enterprise, segment, and solutions architectures as defined in the Federal Enterprise Architecture Practice Guidance, December 2006).

In summary, architecture users are looking to understand the big picture (the EA and IT strategic plan), justify decisions (develop segment architectures that are ‘justified’ by aligning to and complying with the overall EA), and make it work (develop solutions architecture using technical details from the enterprise and segment architectures).

User-centric EA can satisfy the various segment needs by following the opportunities identified in the study to improve EA use. These are as follows (modified to more accurately represent what I believe is their correct application to users.)

For trend seekers/EA:

• Show the big picture—high-level, non-technical information about the EA (this equates to EA profiles) and the direction of overall business and IT initiatives (this is the business, EA, and IT strategic plans)
• Provide access to the source—ways to find more information and points of contact

For fit-seekers/segment solutions:

• Lead to the right information—clear guidance through understandable nomenclature and information structure

• Provide proof—through IT investment Review Board and EA reviews that include findings and recommendations.

For fixer-doers/solutions architecture:

• Give specifics for immediate help—through more detailed EA models and inventories as well as SDLC job aids.

For all:

• Share and enhance—capture performance metrics on EA program and products, especially use of EA information and governance services.

At the end of the day, EA needs to fulfill user’s requirements and empower them to leverage use of the information and services.

Getting People to Use Enterprise Architecture

Enterprise Architecture Filters the Technology Landscape

User centric EA helps to filter out those technologies that seem “new and cool”, but are often really quite useless to the enterprise.

In the Wall Street Journal, 17 August 2007, it is reported that of the more than 442,000 new patent applications filed in the U.S. last year, few of them qualify as a success (i.e. those that sell 100,000 units or more).

The fact that few new innovations are actually successful is one reason that EA must filter out the ‘good’ ones from the ‘bad’ ones.

Any modern day organization can be easily inundated with evaluating the fast and constantly changing technology landscape (especially one where innovations number in the hundreds of thousands annually). It is the role of EA to help manage the governance process for approving new IT systems, products, and standards, and for developing the target and transition plan to phase in organizational change in a structured and deliberate manner.

Of course, the organization cannot afford to purchase, incorporate, and maintain every new technology "toy" that its employees identify in either IT magazines or trade shows or from vendors making cold calls. Rather, new technology investments need to be closely aligned with the mission, and be prioritized for best value results.

Enterprise Architecture Filters the Technology Landscape

The Peter Principle and Enterprise Architecture

The Peter Principle—Formulated by Laurence J. Peter, the Peter Principle states that "in a hierarchy every employee tends to rise to his level of incompetence." More generally speaking, anything that works will be used in progressively challenging applications until it causes a disaster (i.e. ‘The Generalized Peter Principle’).”

How does the Peter Principle work?

“The Peter Principle's practical application allows assessment of the potential of an employee for a promotion based on performance in the current job, i.e. members of a hierarchical organization eventually are promoted to their highest level of competence, after which further promotion raises them to incompetence. That level is the employee's ‘level of incompetence’ where the employee has no chance of further promotion, thus reaching his or her career's ceiling in an organization…One way that organizations attempt avoiding this effect is to refrain from promoting a worker until he or she shows the skills and work habits needed to succeed to the next higher job. Thus, a worker is not promoted to managing others if he or she does not already display management abilities.” (adapted from Wikipedia)

The Peter Principle demonstrates various human capital issues in the organization that range from performance management to leadership development. While there are no simple answers, there is clearly a need to focus on these issues and for them to be included as part of overall enterprise architecture planning and governance. Perhaps (a far-fetched idea, although one that the military successfully uses) promotions—like new IT systems, products or standards—would be managed through a human capital review board that would catch some of these faulty promotions before they turn into disasters for the employees and the organization.

Let’s add a Human Capital Perspective to the FEA:

To clarify, EA is not only a technology function but is a business function, and as part of the business function, I am calling for the addition of a human capital perspective to the Federal Enterprise Architecture!

Further, while some erroneously consider EA an information or documentation endeavor, it is much more than that—it is a planning and governance mechanism for the organization. And to effectively plan and govern (to execute on mission and achieve success), EA must include a human capital perspective, since people are our organization’s most valuable asset.

In User-centric EA, issues like how to mitigate negative effects of the Peter Principle could be addressed with the addition of a human capital perspective (see usercentricea.blogspot.com posting for 29 July 2007), which would deal with the many behavioral, cultural, and managerial issues regarding human capital facing the enterprise.

A Human Capital perspective to EA would include the following types of information:

• Professional and management development
• Leadership development
• Succession planning
• Performance management
• Skills management
• Training
• Team building
• Labor relations
• Recruiting
• Retention
• Morale

I encourage and call for the adoption of a human capital perspective to the Federal Enterprise Architecture (FEA).

The Peter Principle and Enterprise Architecture

Segway and Enterprise Architecture

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

An example of technology for technology’s sake:

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

Requirements should come first.

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

There is an important place for innovation.

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

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

Segway and Enterprise Architecture

Culture of Merit and Enterprise Architecture

While User-centric EA is focused on the user and meeting their requirements, user-centric EA is not for a culture of entitlement in the organization.

• Meeting user requirements is driven by the relative merit of those requirements and ultimately, their value to the enterprise.
  

In the book, Up Your Business by Dave Anderson, the author states that to achieve organizational excellence, we need to "replace your culture of entitlement with a culture of merit."

• In general, while equity and fairness in the workplace is a core value, organizations can only thrive in a culture of merit.
  

For organizations to achieve excellence, they must foster an environment that promotes and rewards excellence:

• Entitlement equates to mediocrity; merit equates with excellence!
  

In User-centric EA, requirements are fulfilled based on their merit and alignment to mission, and individuals are motivated and rewarded based on merit, contribution, and the achievement of results.

Culture of Merit and Enterprise Architecture

Information Sharing Best Practices

There are currently two major federal best practices for information sharing: Netcentricity and the Information Sharing Environment.

The Department of Defense (DoD) adopted a Netcentric Strategy in May 2003.

• Netcentricity—Netcentricity seeks to ensure data visibility, availability, and usability to accelerate decision-making. This includes data tagging (metadata), posting data to shared spaces, and enabling the many-to-many exchange of data (i.e. many users and applications can access the same data instead of point-to-point interfaces). Netcentricity is the realization of a networked environment.
• Global Information Grid (GIG)—The GIG is a globally interconnected, end-to-end set of information capabilities, associated processes and personnel for collecting, processing, storing, disseminating and managing information on demand to warfighters, policy makers, and support personnel. The GIG includes all owned and leased communications and computing systems and services, software, data, security services and other associated services necessary to achieve information superiority.

Netcentricity is a strategy for sharing information. As the DoD strategy states: The data strategy is to “shift from private data to community or Enterprise data as a result of increased data “sharing” in the netcentric environment. Tagging, posting, and sharing of data are encouraged through the use of incentives and metrics.” (adapted from DoD Net-Centric Strategy from defense.link.mil, public site)

In 2004, the concept of Netcentricity was extended to the Director of National Intelligence (DNI)’s Information Sharing Environment with the passing of the Intelligence Reform and Terrorism Prevention Act (IRTPA).

• Information Sharing Environment (ISE)—The IRTPA requires the President to establish an ISE “for the sharing of terrorism information in a manner consistent with national security and with applicable legal standards relating to privacy and civil liberties” and the IRTPA defines the ISE to mean “an approach that facilitates the sharing of terrorism information.”

The ISE seeks to “facilitate trusted partnerships among all levels of government, the private sector, and foreign partners…[and to] promote an information sharing culture among partners by facilitating the improved sharing of timely, validated, protected, and actionable terrorism information.” (adapted from Information Sharing Environment Implementation Plan from ISE.gov, public site)

Both Net-centricity and ISE are best practices at increasing information sharing to improve and speed up decision-making and protect our nation and its citizens!

• As the DoD Net-Centric Strategy states: “the core of the net-centric environment is the data that enables effective decisions.”
• And similarly, in the ISE Implementation Plan, we read, “the highest priority in creating the ISE must be on facilitating, coordinating and expediting access to protected terrorism information.”

In User-centric EA, information sharing, as appropriate, is one of the primary goals of the architecture. Information is one of the six perspectives (performance, business, information, services, technology, and security, and a seventh to be added is human capital) of the EA. The primary principal of the Information perspective is information sharing and accessibility. Further, the Federal Enterprise Architecture (FEA) Data Reference Model (DRM) is driven by the enablement of sharing information across the federal government and to its partners. The methodology is as follows:

• Consistently describe data (via metadata)
• Register the data (to make it discoverable)
• Develop standards for the exchange of data (to enable interoperability and accessibility)
  
• Provide sound governance (including data policy and stewardship).

User-centric EA is driven to fulfill the vision of Net-centricity and ISE.

Information Sharing Best Practices

Information Exchange Matrix and Enterprise Architecture

The Information Exchange Matrix (IEM) —a.k.a. OV-3 from the Department of Defense Architecture Framework (DODAF)—identifies the information exchanged between entities and the relevant attributes of that exchange such as source, destination, type of information, trigger for the exchange, media, frequency, quality (timeliness, completeness, etc.), quantity, and security.

Major characteristics include:

• Information requirements: IEMs document information exchange requirements for the enterprise. They identify who is exchanging what information to whom, when, why, where and how. The IEM describes the flow of information in the organization.
• Business Process Driven: IEMs are driven by business processes and activities and demonstrate what information is required to perform the mission-business functions of the organization.
• Major Information Exchanges: IEMs are usually not comprehensive, but rather capture the major information flows that support the mission-business.

In User-centric EA, information exchange matrixes are one of the most critical products in the architecture. By knowing and understanding the information required by the enterprise (as identified in the IEM), architects are able to do the following:

• Identify the systems that are providing information required by users.
• Identify systems that are providing information that is not (or is no longer) required by users.
• Determine which systems are redundant (i.e. meeting identical requirements).
• Determine where there are system gaps (i.e. no system is providing the requisite information) .
• Plan new technology solutions to meet new or changed information requirements.
• Develop an environment conducive to information sharing by distinguishing which information exchanges must be on a need to know basis (secure) and where greater openness and sharing can occur.
• Pinpoint what business processes should be reengineered or improved to better make use of available information and meet performance outcomes.

IEMs must have user participation. They cannot just be reversed engineered from existing systems, since that will only tell what information is currently being provided (and what information should be provided). Also, pulling the IEM information from systems does not address existing manual information exchanges that could very possibly be automated going forward.

Information Exchange Matrix and Enterprise Architecture

Marketing and Enterprise Architecture

In the book Marketing Insights from A to Z by Philip Kotler, the author states:

“Marketing is too often confused with selling. Marketing and selling are almost opposites…Marketing is not the art of finding clever ways to dispose of what you make. Marketing is the art of creating genuine customer value. It is the art of helping your customers become better off. The marketer’s watchwords are quality, service, and value.”

Kotler goes on as follows:

“Selling starts only when you have a product. Marketing starts before a product exists. Marketing is the homework your company does to figure out what people need and what your company should offer. Marketing determines how to launch, price, distribute, and promote your product/service offerings to the marketplace. Marketing then monitors the results and improves the offering over time.”

User-centric EA is based in marketing: In User-centric EA, we don’t serve up esoteric, incomprehensible, technology laden jargon filled “artifacts” that is destined to become shelfware; instead,

• EA exists only to create genuine customer value.
• EA is driven by the business and works for the business users.
• EA works to understand their needs and strives diligently to fill them.
• EA provides the enterprise with business and technology information, planning, and governance as required by the business!

The business drives the product and service offering of EA, participates in the creation of the actual EA deliverables, and provides continuous feedback to help tailor and improve the EA over time.

Just like marketing, EA must identify their customer base, discover their need set, and provide ongoing customer value so as to get, keep, and grow their customers.

Marketing is about being customer minded and so is User-centric EA.

Marketing and Enterprise Architecture

CEO and Enterprise Architecture

An organization’s performance is closely linked to the lives and state of mind of its leadership.

The Wall Street Journal (WSJ), 5 September 2007 reports that based on a 10 year study of 75,000 Danish companies, profitability of companies declined after the CEO suffered from the death of a child (-21.4%), spouse (-14.7%), parent (-7.7%). [Further, the study reports that profitability actually increased when the CEO lost his/her mother-in-law (7%).]

These results are really not surprising nor or they hard to understand.

Leaders are people first—as human beings, we are all vulnerable to the tragedies of life and these affect us profoundly!

The WSJ puts it this way: “These are individuals…It’s important to understand they’re not automatons.”

The study called, “It’s All About Me” goes on to state the company’s profitability also typically fell after the CEO purchased a mansion. Researcher speculate that the leadership is either cashing out of the company (i.e. they no longer believe in the company’s future prospects) or that the leaders have become distracted by their own narcissism (i.e. enjoying their wealth rather than working hard).

For a quite a while, people have questioned the hefty executive pay packages, but as the WSJ states, perhaps these questions will be somewhat muted by these “studies [that] generally conclude CEOs do matter to their companies’ performance.”

In User-centric EA, people matter and leadership matters. If the leader is distracted or physically or emotionally wounded, the enterprise most certainly suffers. However, EA can help function as shock-absorber in the organization, since it provides for broad-based business and technical input, planning, and governance. By having the long-term mechanisms in place, such as a well researched and accepted EA plan and vetting mechanisms for how to invest corporate resources, the reliance on any single individual or individuals is lessoned. Leadership will always play a crucial part in organizational success (or failure) and as individuals we are all at the mercy of heaven above, but developing sound mechanisms by the which the organization can weather some of life’s shocks is a role EA can play.

CEO and Enterprise Architecture

Groupthink and Enterprise Architecture

Groupthink is a type of thought exhibited by group members who try to minimize conflict and reach consensus without critically testing, analyzing, and evaluating [alternate] ideas. A variety of motives for groupthink exist, such as a desire to avoid being seen as foolish, or a desire to avoid embarrassing or angering other members of the group. Groupthink may cause groups to make hasty, irrational decisions. (Adapted from Wikipedia)

Why is the concept of groupthink important?

If the enterprise allows conditions to flourish where groupthink tends to occur, then poor decision are made and these decisions may have disastrous consequences for the organization. Some examples of this are the following:

- Space Shuttle Challenger exploded because of the faulty o-rings, which engineers discovered prior to launch.

- The Bay of Pigs Invasion, which was a flawed plan, but which Kennedy’s advisors remained mum about.

Social psychologist Clark McCauley's identifies three conditions, under which groupthink tends to occur:

• Directive leadership
  
• Homogeneity of members' social background and ideology
• Isolation of the group from outside sources of information and analysis

User-centric EA can be a valuable tool for thwarting groupthink and improving decision making in the organization in the following ways:

• Consensus-driven: User-centric EA is consensus driven, not directive. Input from subject matter experts is not only desired, but also is required and strongly encouraged at all phases. While the chief architect does provide structure and direction, the architecture must reflect the expertise of the business and technical experts. Thus, the architecture, plans, and governance for the enterprise are driven by accord and not any autocratic process.
  
• Diversity: EA is a diverse discipline, which by definition spans multiple business and technical domains. EA is an example to the organization of how variety of thought and expertise, as well as individual and cultural diversity is valued and necessary for the organization to grow and mature.
  
• Idea-friendly: EA looks at both internal and external factors affecting the organization. These are inputs to the EA process, which integrates and assimilates the information, analyzes and catalogues it, and serves it up as information products and governance services to the end-users. EA is a prime source for bringing in external inputs, best practices, and innovations and using this to drive the plans for the enterprise. This is especially relevant in terms of identifying new technology products and standards, new IT systems, and new and improved business processes.

EA is the antithesis of groupthink and should spark creativity and “next generation” thinking in the organization. In User-centric EA, there are no stupid questions—it’s only stupid not to ask, not to challenge the status quo, and not to raise viable alternatives.

Groupthink and Enterprise Architecture

Systems Theory, Community Model, and Enterprise Architecture

The Community Model is a way of presenting a high level view of function and the actors and their relationships in an organization. The model is then decomposed into activities, data, and requirements for establishing enterprise architecture. (adapted from Booz Allen Hamilton).

In the community model, the circle (representing the enterprise) is divided in half. The top half represents the mission functions. The bottom half represent the support functions. The Support functions act on the behalf of the mission function above and hence are connected by arrow from the support to the mission. The mission semi-circle above has arrows towards customers on the outside above the circle. The support semi-circle below has arrow towards supplies on the outside beneath the circle. There are additional arrows from the sides of the circle toward partners and towards organizational sub-entities that function independently (and have their own circle with mission and support), but that interfaces with the primary organization. I believe there should also be arrows connecting the prime circle to stakeholders, such as unions, associations, distributors, oversight authorities, even competitors.

This is a pretty cool way to get a high-level snapshot of the organization and the “community” it functions in.

In my view, the community model is an adaptation from Systems theory, which studies the nature of complex systems in society, nature, and science. In systems theory, organizations are compared to organisms; they are open and interact with their environment and must achieve effective relationships with the various actors in the environment to survive and thrive.

Systems theory is used as a framework to analyze and/or describe a group of objects that work in concert to produce some result. In this context, a system means a configuration of parts connected and joined together by a web of relationships. In the case of an EA community model, the enterprise and its affiliates are working to provide products and/or services to its users. The various actors in the system interact in a network of relationships to provide execute, support, consume, supply, distribute, partner, oversee, or compete. Every actor in the system has a role and every actor is impacting the others.

In User-centric EA, system theory and community model are terrific ways to understand and describe the enterprise, its functions, actors, interactions, and dependencies. It is also a good starting point for decomposing business, data, and system models to further understand the specific nature of the relationships and how these can be reengineered or improved prospectively.

Systems Theory, Community Model, and Enterprise Architecture

Business Intelligence and Enterprise Architecture

“Business intelligence (BI) refers to applications and technologies that are used to gather, provide access to, and analyze data and information about company operations. Business intelligence systems can help companies have a more comprehensive knowledge of the factors affecting their business, such as metrics on sales, production, internal operations, and they can help companies to make better business decisions.” (Wikipedia)

Business intelligence includes warehousing data and mining data (sorting large amounts of data to find relevant information). Metadata (data about data) aids in the mining of useful nuggets of information. The warehousing and mining of data for business intelligence is often referred to as a decision support system.

User-centric EA is business (and technology) intelligence!

• EA is a knowledge base and warehouse of information: BI warehouses date for decision support applications in the organization. Similarly, EA synthesizes and stores business and technical information across the enterprise to enable better decision making. EA uses applications like Systems Architect, DOORS, Metis, Rationale, and others to capture information in a relational database repository and model business, data, and systems. The intent is to develop a knowledge base for the capture, mining and analysis of data to enhance IT planning and governance.
• EA provides for mining, querying, and reporting: BI tools use online analytical processing (OLAP) tools like Cognos, BusinessObjects, Hyperion, and SAS that utilize multi-dimensional database cubes for manipulating data into different views, and provides for analysis and reporting. Similarly, User-centric EA provides for analysis and reporting of performance measures, business functions, information requirements, applications systems, technology products and standards, and security measures. While EA tools are more limited than general BI tools in terms of OLAP capabilities like online queries, I believe that these tools will move in this direction in the future.
• EA uses information visualization to communicate effectively: BI tools provide executive dashboard capabilities for displaying executive information in a user-friendly GUI format. Like an executive dashboard, EA often displays business and technology information in profiles and models that make extensive use of information visualization to communicate effectively and at strategic, high-level views to decision makers.

In is the role of the chief enterprise architect to sponsor, communicate, and educate on the use of EA for business and technology intelligence in the organization.

Business Intelligence and Enterprise Architecture

Functional Requirements and Enterprise Architecture

In User-centric EA, it is important to facilitate the delivery of IT systems that meet user requirements. While it is solutions architecture that is actually involved in the development of the technology solutions and systems, EA is the guiding strategic architecture for the organization that specifies the overall target architecture and transition plan.

For systems to be developed to meet user needs, a solid set of functional requirements need to be captured. These functional requirements should meet the following criteria:

• Needed
• Verifiable (i.e. they can be tested to see if they are met)
• Attainable
• Clear
• Simple (i.e. one requirement per phrase)
• Consistent
• State “what” (not “how”)

A clear set of functional requirements is a critical step to the development of IT systems that meet user needs and help the enterprise achieve its target architecture.

Functional Requirements and Enterprise Architecture

My Dear Technology and Enterprise Architecture

Oh how dear is my technology?

The Wall Street Journal, 1-2 September 2007, wrote about a dying woman and her last words to her daughters:

“In the past four years, I have replayed that moment again and again. The beeping of machines. The manic bustle of nurses. Doctors spouting terms like ‘lung failure.’ And, ultimately, my mom toiling to draw a breath…so that she could ask that my sister, Lizzie, and I safeguard her eBay reputation.” !!!!!

There’s more…

“Mom radiated fear throughout her illness…once, when my sister brought to my mom an old photo album, my mom told her she didn’t want to look through it. And then Mom slid her Mac unto her lap and logged on to eBay.”

The daughter’s conclusion…

“She was dying. But with her iMac and wireless internet connection, she found life.”

I am sure that this article is as shocking to many of you as it was to me. Not that we can or should judge anyone. Hopefully, we will never be in this lady’s shoes. But it does seem bizarre that even when the mother is deathly sick, she is neither interested in her faith, her family, her memories, or her good deeds—the things that are usually the treasures of most of us—but rather is apparently all consumed by her computer, her wireless connection, and her website.

As a professional in EA, I have frequently encountered people at work at their love affair with their pet technologies. They saw it in a trade mag; got this “unbelievable” brief or slick brochure from ABC company; viewed this demo at a trade show; and now they “gotta gotta have it!”

In a sense, adults are just big children. They have to have their toys. They won’t stop whining and bellowing until they get it. And once they get it, they play with it for a short time, and then it goes into the corner to collect dust.

This is exactly what User-centric EA and IT governance is supposed to protect the enterprise against. EA and capital planning & investment control are designed to help filter out the technology winners from the losers, and those that align with the needs and strategies of the organization from those that are merely toys. There are a lot of whiners and bellowing customers out there, buying them their toys is not user-centric, but just foolish and a waste of valuable corporate investment dollars.

My Dear Technology and Enterprise Architecture

SOA Best Practices

I came across these Service-Oriented Architecture (SOA) best practices and thought they aligned well with User-centric EA and were worth sharing:

(adapted from Naval Post Graduate School, Monterey, CA, Masters Thesis—SOA for Coast Guard Command and Control by Dash and Creigh, March 2007 — approved for public release):

• Know when to use services – Explicitly define the extent to which we will and will not use services; services are selected with intent and do not randomly spring up.
• Think big, start small – This allows us to validate the architecture, while giving the organization value, realized as usable services.
• Build on what you have – Reuse legacy application functionality and data wherever possible.
• Use SOA to streamline business processes – SOA is an inherently flexible and interoperable model for hosting application functionality; this provides an opportunity to rethink and improve business processes.
• Incorporate standards – Use industry web service standards for navigation, application logic, integration, data stores, and enterprise infrastructure.
• Build around a security model – Functional design needs to be built around security, and not vice versa (security cannot be added as an afterthought).
• Design with quality in mind – Quality must be designed into the product, and not inspected into it.
• Organize development resources – Group development team around logical business tasks, and not around technologies.
• Train developers – Ensure designers and developers have the skills to implement SOA properly.

Basic definitions:

SOA is a software design methodology that uses loosely coupled services to perform business functions and processes.

A service is an implementation of a well-defined piece of business functionality, with a published interface that is discoverable and can be used by service consumers when building different applications and business processes.

In general, I think SOA is a great fit with User-centric EA, because the focus is on providing functional business services to the end-user, as opposed to developing monolithic, stove-piped, and redundant applications. The end-user should not have to use countless non-integrated applications systems (or even computers) to get their information, but rather the information should be technically transparent and readily accessible based on their business requirements.

SOA Best Practices

IT Governance and Enterprise Architecture

User-centric EA provides Information Technology (IT) governance services by providing technical reviews for new or substantial changes to IT projects, products, and standards in the enterprise. The IT governance process assures there is alignment to and compliance with the EA.

The EA Board (EAB) consists of business and technical members. The EAB conducts technical reviews and answer the following types of questions in support of IT governance:

• How does the proposed system align with mission, vision, strategy, and goals (for example, how does the proposed change fit within the strategic, tactical, and operational plans of the organization)?
• How will information be shared across the enterprise and with its partners (for example through use of metadata and repositories)?
• How will the system be interoperable (for example, through open standards and modular components); also, are there any existing systems in the organization that can meet the needs of the user?
• How will technology standardization and simplification be met (for example, through use of approved enterprise products and standards)?
• How will performance be measured (for example, what indicators will be used and what represents success)?
• How will information be secured (for example, does the system have authority to connect and authority to operate)?
• How is compliance being met for such things as the Privacy Act, Federal Records Management Act, Section 508 of the Rehabilitation Act, and Federal Information Systems Management Act, and so on?

The EAB provides its finding and recommendations to the IT Investment Review Board (IRB), which has decision authority for all phases of capital planning and investment control (CPIC)—select, control, and evaluate. The IRB is responsible for evaluating, authorizing, prioritizing, and authorizing funding for IT investments and then for the ongoing oversight of cost, schedule, and performance of the investment. The IRB manages its investments as a portfolio (i.e. portfolio management) and ensures that the mix of investments meets business objectives and optimizes value (value, risk, and cost) for the enterprise. The IRB cannot do its job without input from EAB (in a sense, the EAB is the technical, working arm of the IRB).

EA has a critical role in IT governance. EA ensures that IT projects, products, and standards align to and comply with the architecture requirements and planning goals of the organization.

IT Governance and Enterprise Architecture

CONOPS, Proof of Concepts, Prototypes, Pilots, and Enterprise Architecture

User-centric EA seeks to implement successful IT governance for the enterprise. As such, it seeks to ensure that new systems not only meet users’ requirements, but also that organizational investments in new IT are successful.

There are a number of ways to phase in a new system to help ensure its success for the organization.

By first developing a clear definition of capabilities (CONOPS), and moving from proof of concept to prototype and to pilot, risk is mitigated on new system implementations and more systems are successfully brought to fruition. This phased systems development approach helps User-centric EA meets it target architecture and transition plan for the organization.

• Concept of Operations (CONOPS)—evolves from a concept and is a description of how a set of capabilities may be employed to achieve desired objectives or a particular end state for a specific scenario.”
• Proof of Concept—a partial solution to a problem intended to prove the viability of the concept. A proof of concept may involve a small number of users acting in a business (non-IT) role using the system to establish that it satisfies some aspect of the requirements for the complete solution. The proof of concept is usually considered a milestone on the way of a fully functioning prototype.
• Prototype—an original instance of some thing serving as a typical example for other things of the same category. A prototype is built to test the function and feel of the new design before starting production of a product.
• Pilot—an initial roll out of a system into production targeting a limited scope of the intended final solution. The scope may be limited by the number of users which can access the system or by the business categories affected or the business partners involved or other restrictions as appropriate to the domain. The intent of a pilot project is to validate that the system is working in production as designed and limiting the business exposure if it is not.”

Note: Definitions of proof of concept, prototype, and pilot project were adapted from Wikipedia. The Definition for CONOPS was adapted from Navy Warfare Development Command (public website).

CONOPS, Proof of Concepts, Prototypes, Pilots, and Enterprise Architecture

SDLC, CPIC, PMBOK, and EA

User-centric EA seeks to align the various life cycle IT system processes to help users understand, navigate, and complete these as simply and smoothly as possible.

Below is an alignment of the processes for System Development Life Cycle (SDLC), Capital Planning and Investment Control (CPIC), Enterprise Architecture (EA), and the Project Management Book of Knowledge (PMBOK).

SDLC	CPIC	EA	PMBOK
Conceptual Planning	Select	Business Alignment	Initiating
Planning & Requirements	Control	Technical Alignment	Planning
Design			Executing
Development & Testing
Implementation
Operations & Maintenance	Evaluate	Architecture Assessment
Disposition			Closing

The graphic demonstrates that the various IT system processes align quite nicely, and that user seeking to stand up a new system or make major changes to existing systems can follow the basic 7 steps of the SDLC and complete the requirements of CPIC, EA, and PMBOK along the way (the touch points are all identified).

The way to read this graphic is as follows:

For example, in the first phase of the SDLC, the conceptual planning stage, the user does the following: 1) defines their need (SDLC process) 2) develop their business justification and seek to obtain approval and funding from the IT Investment Review Board (CPIC process) 3) develops their business alignment and seeks approval from the Enterprise Architecture Board (EA process), and 4) define their project and seek authorization to proceed (PMBOK process).

For CPIC, users identify the following:

• Select—How does the investment meet business decision criteria?
• Control—Is the investment being managed with the planned cost, schedule, and performance criteria?
• Evaluate—Did the investment meet the promised performance goals?

For EA, users demonstrate the following:

• Business Alignment—Does the investment support the agency mission?
• Technical Alignment—Does the investment interoperate within the technology infrastructure and meet technical standards?
• Architecture Assessment—Is there a need to update the architecture?

For PMBOK, users complete various project management processes:

• Initiating—Define and authorize the project.
• Planning—Define objectives and plan course of action.
• Executing—Integrates resources to carry out project management plan.
• Closing—Accept product or service.

Note: The EA/CPIC alignment is adapted from Architecture Alignment and Assessment Guide, Chief Information Officers Council, August 2001. The PMBOK definitions are adopted from the Project Management Book of Knowledge, Third Edition.

User-centric EA promotes the alignment of the various IT system processes to help users to easily understand the touch points in the various life cycle steps to getting their system up and running. Moreover, the alignment enables the CIO to develop processes and job aids to assist and ‘speed’ users through the process. Thus, the processes are transformed from inhibitors to facilitators of systems progress for the enterprise.

SDLC, CPIC, PMBOK, and EA

Psychopaths and Enterprise Architecture

In user-centric EA we are very focused on meeting the needs and requirements of the user community. However we need to beware of the fact that some users are "psychopaths" and do not have the best interests of the organization at heart.

In the book Snakes in Suits - When Psychopaths Go To Work by Babiak & Hare the authors identify these ill-intentioned people in the organization and why the organization tolerates them or is fooled by them.

"Psychopaths manipulate the system - they are selfish care only about themselves with little regard for fairness or equity. They allow the responsibility of leadership and the perks of power to override their moral sense. Some have embraced the mantra that greed is good and that success at any cost to others is justifiable and even desirable. And at the extreme some of these people have a true personality disorder rooted in lying, manipulation, deceit, egocentricity, callousness, and other potentially destructive traits."

As enterprise architects, we need to be continually on the lookout for what's best for the enterprise and not get sidetracked by those with ulterior motives or personal agendas.

Have you ever experienced a situation like this?

Psychopaths and Enterprise Architecture

Data Architecture Done Right

Data architecture done right provides for the discovery and exchange of data assets between producers and consumers of data.

Data discovery is enabled by data that is understandable, trusted, and visible.

Data exchange is facilitated by data that is accessible and interoperable.

Together, data discovery and exchange are the necessary ingredients for information sharing.

Why is it so hard?

Primarily it’s a coordination issue. We need to coordinate not only internally in our own organization (often already large and complex), but also externally, between organizations — horizontally and vertically. It’s quite a challenge to get everyone describing data (metadata) and cataloging data in the same way. Each of us, each office, each division, and so forth has its own standards and way of communicating. What is the saying, “you say poTAYtos, and I say poTAHtos”.

Can we ever get everyone talking the same language? And even if we could, do we really want to limit the diversity and creativity by which we express ourselves? One way to state a social security number is helpful for interoperability, but is there really only one "right" way to say it? How do we create data interoperability without creating only one right way and many wrong ways to express ourselves?

Perhaps, the future will bring artificial intelligence closer to being able to interpret many different ways of communicating and making them interoperable. Sort of like the universal translator on Star Trek.

Data Architecture Done Right

Five Pitfalls of Enterprise Architecture Review Boards

EA Review Boards are necessary for supporting sound technology investment management decisions (a.k.a. CPIC or capital planning and investment control).

However, the EA Review Boards often fail for the following reasons:

• The board has no power to enforce its decisions — this typically happens when the CIO does not control the IT funding in the organization.


• The board has no visibility to the IT projects being initiated across the enterprise — again, this is common when the CIO does not control IT spending and programs can fund their own IT pet projects.


• The board meetings are not well organized —this can happen when meetings are sporadic instead of regular, when meetings run over their scheduled times, when agendas are not followed, minutes not kept, and members are not given ample opportunity to participate and “be heard” in the meetings.


• The board members do not understand the “what’s in it for me” — the members on the review board feel that they already have “day jobs” and that participating on the EA review board is not their responsibility or is not relevant to what they do day-to-day.


• Board members lose interest over time — a pretty common symptom of this is when the members start “delegating” attendance and participation to less senior members of the organization (and those people may not have the same level of subject matter expertise or decision authority as the “official” members).

In User-centric EA, the focus of the EA reviews is on the stakeholders presenting their projects, on the members contributing to the reviews, and on both of these seeing that their participation results in better IT investment decisions and more successful projects for the enterprise.

Finally, the CIO through the Investment and EA Review Boards wields control over the allocations of funds and prioritization of technology investments.

Five Pitfalls of Enterprise Architecture Review Boards

Space Elevator and Enterprise Architecture

In User-centric EA, having a vision for the future is critical in developing the target architecture and transition plan.

At one time, man looked up at the heavens, and imagined that one day people would actually walk on the moon — and on July 21, 1969, this once unbelievable vision became a reality.

Today, some very smart people from Las Alamos National Lab, NASA Institute for Advanced Concepts, and MIT are envisioning a space elevator 62,000 miles long that would move along at 120 miles an hour. The top of the elevator would rotate with the earth at 20,000 miles an hour and could be used to springboard to the moon, mars, and beyond. Sounds crazy? Well, NASA has invested millions of dollars and 22 teams (mostly universities) have signed up for a competition to design the space elevator.

The point is that using the imagination to envision the future is a really important part toward actually making the leap forward. The ideas have to start somewhere, and while the ideas need to be moderated and prioritized, big idea thinking is imperative to both evolutionary and revolutionary change. Enterprise architecture is a great place for using creativity, imagination, and vision and opening up often insular organizations to new ideas and ever greater possibilities for the future.

Space Elevator and Enterprise Architecture

Darwin and Enterprise Architecture

User-centric EA seeks the long term preservation, maturation, and growth of the organization and its ability to deliver mission execution.

Charles Darwin stated that "in the struggle for survival, the fittest win out at the expense of their rivals because they succeed in adapting themselves best to their environment.”

In the book Images of Organization by Gareth Morgan, Darwin’s theory of survival is extended from the individual to the enterprise. “Organizations, like organisms in nature, depend for survival on their ability to acquire an adequate supply of resources necessary to sustain existence. In this effort they have to face competition from other organizations, and since there is usually a scarcity of resources, only the fittest survive.”

Even in cases where resources are abundant and self renewing, organizations are always competing to survive. This competition takes the form of who can supply the end user with the products or services they need better, faster, and cheaper. The competition, in this case, is not for resources, but to be the resource to others. For in being the supplier of choice to its customers or stakeholders, the enterprise thrives and survives in executing its mission.

Indeed, in a competitive economy, there is always the opportunity for a competitor to arise and challenge the organization’s role in the marketplace. It is this competition that is considered not only healthy, but also a cornerstone for continuously improving product and service quality and keeping prices at bay for customers.

Even in government, where some may think there is no competition, agencies not only compete for limited resources (funds, people, and so on), but also for being the provider of choice to the citizens. As one example, in the federal government, there are several agencies that can provide banking regulation, such as the Office of the Comptroller of the Currency (OCC), the Office of Thrift supervision (OTS), the Federal Deposit Insurance Corporation (FDIC), and the Federal Reserve.

In a competitive environment, EA is a tool for business and technology planning and governance that helps an organization deliver on its mission and be the provider of choice to its customers.

Darwin and Enterprise Architecture

Why Isn’t There a Chief Data Architect in the Federal Government?

In the federal government, there is a Chief Enterprise Architect in the Office of Management and Budget (OMB) — this is a good thing.

But the question that I have is why there isn’t a Chief Data Architect as well?

We all know that one of the essentials to good architecture is having strong data architecture that provides for data descriptions (or metadata) to uniformly describe data, data context (or taxonomies) for discovery, and that supports data sharing (or exchange).

In the Federal Enterprise Architecture (FEA), there is a Data Reference Model (DRM). Moreover, in the FEA, data is the crucial touch point between on one hand, the business functions toward achieving desired performance outcomes, and on other hand, the services and technologies that serve up the data in order to perform the functions and activities of the enterprise.

Furthermore, in developing technology solutions of the enterprise, one very important question for the business is what their information and data requirements are. The answer to this helps drive the technology solution.

For the federal government, the benefits of maturing its data architecture could be significant, especially in being able to share vital information, and thereby fill gaps and reduce redundancy across the federal enterprise. Given the size and important scope of the federal government missions, the imperative is great!

The Chief Data Architect would focus on data issues and drive such things as data standardization, common lexicon, metadata development, exchange standards and directories, service oriented architecture, and overall information sharing.

What do you think--would a Federal Chief Data Architect be a good idea to help progress this?

Why Isn’t There a Chief Data Architect in the Federal Government?

Maslow’s Hierarchy of Needs and Enterprise Architecture

User-centric EA helps an organization meet its needs on many levels.

The great psychologist Abraham Maslow, in the Hierarchy of Human Needs, theorized that people seek to fulfill successively higher level of needs: first is basic needs like physiological and safety needs (sustainment needs), then loving and belonging (social needs), and finally self actualization (innate growth and upward movement).

I believe that Maslow’s Hierarchy of Human Needs can be extended to organizations as well.

User-Centric EA helps an organization fulfills the basic need to sustain itself and carry out its day-to-day mission (tactical), but also its higher order needs of socialization — to be connected, accepted, and held in esteem by its peers, partners, “masters” (those with oversight and budget authority), and stakeholders — and finally, its need to self actualize, where it finally achieves its core mission (strategic) and purpose for being and strives to be the best it can be, growing and broaden its reach and impact in the world.

How does EA do this?

• EA looks at the business and information needs of the organization to fulfill its mission and achieve results from operations (sustainment).
• EA seeks to develop common platforms and enterprise solutions — i.e. horizontal and vertical integration and cost-efficiency — as well as information sharing with its peers i.e. to work collaboratively with others in partnership and achieve its mission more effectively and efficiently (social).
• EA is forward looking and strategic, and seeks to drive business process reengineering and improvement and make use of emerging technologies and other best practice advances to help the enterprise be better in the future than it is today (self-actualization).

Maslow’s Hierarchy of Needs and Enterprise Architecture

Leadership Styles and Enterprise Architecture

Is being a good leader about being a dictator or facilitating decision by consensus?

The Wall Street Journal, 11 August, 2007 reports that Mr. Gou the founder and chief of Hon Hai Precision Industry Company, the largest exporter in China (a company with annual revenue of $40 billion and 450,000 workers) believes that "the important thing in any organization is leadership…a leader must have the decisive courage to be a dictator for the common good".

In America, we do not like the idea of dictators, nor do we believe that we get good decisions from that style of leadership. However, certainly, we've all seen organizations where competing interests, personality conflicts, scarce resources, and silo mentalities contribute to stagnation and floundering performance. In these environments, a strong leader can sometimes be a welcome antidote — Not that anyone wants to be dictated to, but a leader that can provide a clear vision, direction, and unclog the routine bottlenecks can sometimes set an organization back on path of forward momentum.

User-centric EA is a proponent for "bringing people along", for decision by consensus, and for valuing individual and cultural diversity. We get a better decision and a better product by hearing opposing points of view and working things out. At the same time, organizational leadership is a necessity and sometimes a leader has got to hear the opposing points of view and then "get off the dime" and make a decision.

Leadership Styles and Enterprise Architecture

Austerity and Enterprise Architecture

User-centric EA believes in planning for the future —often uncertain, but always full of potential.

Fortune Magazine, 20 August, 2007, identifies an important tenet of Carlos Slim (the richest man in the world) as follows: “maintain austerity in prosperous times (in times when the cow is fat with milk); it accelerates corporate development and avoids the need for drastic changes in time of crisis.”

While user-centric EA cares about the individual, it also must take into account the needs of the overall organization and “the greater good.”

User-centric EA is not about being miserly, but rather about being frugal. It’s not about being pessimistic about the future, but about having a plan to weather whatever may come. In user-centric EA, planning includes alternative analysis and looking at the spectrum of all options. User-centric EA is about diversifying capabilities and at the same time building competencies and differentiating.

User-centric EA adopts planning as the mechanism to “maintain austerity”, to “accelerate corporate development”, and to “avoid the need for drastic change in time of crisis”. EA is a stabilizing factor for an organization in an ever changing world.

Austerity and Enterprise Architecture