Terascale Computing and Enterprise Architecture

In MIT Technology Review, 26 September 2007, in an article entitled “The Future of Computing, According to Intel” by Kate Green, the author describes terascale computing— computational power beyond a teraflop (a trillion calculations per second).

“One very important benefit is to create the computing ability that's going to power unbelievable applications, both in terms of visual representations, such as this idea of traditional virtual reality, and also in terms of inference. The ability for devices to understand the world around them and what their human owners care about.”

How do computer learn inference?

“In order to figure out what you're doing, the computing system needs to be reading data from sensor feeds, doing analysis, and computing all the time. This takes multiple processors running complex algorithms simultaneously. The machine-learning algorithms being used for inference are based on rich statistical analysis of how different sensor readings are correlated.”

What’s an example of how inference can be used in today’s consumer technologies?

For example, sensors in your phone could determine whether you should be interrupted for a phone call. “The intelligent system could be using sensors, analyzing speech, finding your mood, and determining your physical environment. Then it could decide [whether you need to take a call].”

What is machine learning?

As a broad subfield of artificial intelligence, machine learning is concerned with the design and development of algorithms and techniques that allow computers to "learn." At a general level, there are two types of learning: inductive and deductive. Inductive machine learning methods extract rules and patterns out of massive data sets. The major focus of machine learning research is to extract information from data automatically, by computational and statistical methods. (Wikipedia)

Where’s all this computational power taking us?

Seems like we’re moving ever closer to the reality of what was portrayed as HAL 9000, the supercomputer from 2001: A Space Odyssey—HAL was“the pinnacle in artificial machine intelligence, with a remarkable, error-free performance record…designed to communicate and interact like a human, and even mimic (or reproduce) human emotions.” (Wikipedia) An amazing vision for a 1968 science fiction film, no?

From a User-centric EA perspective, terascale computing, machine learning, and computer inference represent tremendous new technical capabilities for our organizations. They are a leap in computing power and end-user application that have the capability to significantly alter our organizations business activities and processes and enable better, faster, and cheaper mission execution.

Terascale Computing and Enterprise Architecture

Linux and Enterprise Architecture

The Wall Street Journal, 17 October 2007 reports that Linux is “barely scrapping a single percentage point of the market share” for desktop users.

What is Linux? “Linux is the free operating system whole development is overseen by Mr. [Linus] Torvalds.” Linux is open source and is used at Google other major companies.

However, adoption by users to replace Windows at the desktop has been slow and neglible. Even Mr. Torvalds’ father and sister resist using his Linux creation!

People are continuing to pay hundreds of dollars for Microsoft Windows, instead of the free alternative, for a few reasons:

1. Bundled with the PC—“For most consumers, Windows is ‘free,’ coming as it does [bundled] with their new PCs.”
2. Philosophical heartburn, not!—“Typical consumer user has none of the philosophical objections to Windows of some members of the open-source community.”
3. Net utility—“Windows works well enough that the difficulty involved in switching operating systems outweighs any sling and arrows of using it.”

Linux now comes bundled with other software like web browsers, word processors, and so on in a product called Ubuntu, into an “easy-to-install package.” However, one Ubunto’s main backers implies that it’s really not all that easy to install, as the backer states, “anyone can use it as a primary operating system, as long as they have a technically savvy friend to help with rough patches.”

Mr. Tovalds states “I’m a technical guy, so I tend to believe in the ‘if you build it, they will come’ motto.” However, from a User-centric EA perspective, we believe that business drives technology, and not technology for technology sake. So while Linux is a great option, it’s got to be a product that is truly business-driven. And to be a business-driven product, Linux must become a real alternative to the consumer so that is easy to install, user-friendly, secure, full featured, and responsive to future marketplace changes. Linux should not be selected for end-users or the enterprise based on philosophical discourses or subjective biases, but rather based on net utility.

Linux and Enterprise Architecture

The Atomic Bomb and Enterprise Architecture

J. Robert Oppenheimer (April 22, 1904 – February 18, 1967) was an American theoretical physicist, best known for his role as the director of the Manhattan Project, the World War II effort to develop the first nuclear weapons, at the secret Los Alamo laboratory in New Mexico. Known as "the father of the atomic bomb," Oppenheimer was shocked by the weapon's killing power after it was used to destroy the Japanese cities of Hiroshima and Nagasaki…After the war, Oppenheimer was a chief advisor to the newly created United States Atomic Energy Commission and used that position to lobby for international control of atomic energy and to avert the nuclear arms race with the Soviet Union.” (Wikipedia)

Oppenheimer believed that technology and science had their own imperatives, and that whatever could be discovered or done would be discovered and done. "It is a profound and necessary truth," he told a Canadian audience in 1962, "that the deep things in science are not found because they are useful; they are found because it was possible to find them." Because he believed that some country would build a nuclear bomb, he preferred that it be the United States, whose politics were imperfect but preferable to those of Nazi Germany or the Soviet Union…Oppenheimer was a fatalist about the evolution of technology and science…He looked to humanity's most progressive institutions to restrain the malignant use of technology. Oppenheimer was asked to build a nuclear bomb, and he hoped reason would dictate that it be used twice, in a just war, and then never again. (MIT Technology Review, “Oppenheimer's Ghost”, November/December 2007)

From a humanistic perspective—I am intrigued by the polarity of Oppenheimer’s acknowledgement that in building the atomic bomb and supporting its use against Japan in WWII that he had blood on his hands, but at the same time believing that its use in WWII was justified to prevent further loss of life as well as it existence being a deterrent for future conflicts.

From a User-centric EA perspective—I am interested in Oppenheimer’s fatalistic belief in the evolution of technology. Are technology advances predetermined and inevitable as Oppenheimer believed or is there an element of human control?

Of course, organizations determine through their IT governance (i.e. investment review boards and enterprise architecture strategy), what IT projects to invest in. However, looking beyond distinct individuals or organizations, it seems that nothing will truly impede global technological progress, if there is any gain to be had economically, politically, socially, or otherwise. Net utility (cost-benefit analysis) determines whether innovation is funded and pursued.

EA and IT governance can broker IT investments, but just like the building of the atomic bomb, if it can be done and it benefits someone, it will be done by someone, somewhere!

The Atomic Bomb and Enterprise Architecture

Circumventing the CIO—What’s the Harm?

One of the most difficult challenges we face as enterprise architects is when end-users don’t ask permission, but instead ask forgiveness.

The typical scenario is that a division or unit or group of end-users decides to go out and purchase some new IT widget, gadget, or system without going through the CIO shop. (I know this shouldn’t happen if the CIO controls the IT funding, but even then someone always finds some money squirreled away and decides to use it for something they weren’t supposed to or in some cases even bypasses the money channels altogether, getting a freebie from a eager vendor looking to build or test some new capabilities to sell later to other customers).

Well, where’s the harm?

Oh my G-d, where should I start…

Innovation from the field and operators is great, but bypassing the CIO shop circumvents the structured processes and good governance that is in place to ensure projects succeed. Without these mechanisms, IT project can be at tremendous risk:

1. Business Case—Without a business case, the justification for the IT project was never made, return on investment not calculated, alternatives not considered, and the best course ahead not properly laid.
2. Investment Review Board—Without IRB vetting, the senior-level sponsorship has not been solidified, the project has not been authorized, and its priority has not been set with respect to other, maybe more critical, projects that the enterprise needs; further, the project may not have adequate life cycle funding; additionally, the project is likely not being ongoingly monitored and managed by leadership and enterprise subject matter experts for cost, schedule, and performance.
3. Enterprise Architecture Review—Without an EA technical review, the IT project may align with the target architecture and transition plan, may not be interoperable with other systems, may not meet enterprise technical standards, may overload or be incompatible with existing infrastructure, may be duplicative of other investments, may not be the best or most cost-effective technical solution, may not meet various legal, regulatory, and other compliance requirements.
4. System Development Life Cycle—Without following a defined, repeatable, and measureable SDLC process, the project risks failure by not having adequate and documented planning and requirements, design, development, testing, implementation, training, operation and maintenance, and disposition.
5. Project Management Plan—Without a project management plan, projects are at risks for being mismanaged, having cost-overruns, schedule delays, and quality problems.
6. IT Security Plan—Without an IT security plan, the project is at risk in terms of the confidentiality, integrity, availability, and privacy of the information.

No question, from an end-users perspective, there are quite a few hurdles to go through in implementing a new IT project. An if we’re honest with ourselves, the process can be onerous. Therefore, the CIO and his staff needs to work to streamline the processes, integrate them, provide the users with job aids and excellent customer support. Additionally, there should be a quick pass process for getting those “emergency” (must have now) projects through quickly (although not any less comprehensively).

The key is to balance the needs of the enterprise (ensuring mission execution and sound stewardship of enterprise resources), end-users (supporting innovation and operators ability to do their jobs successfully and safely), and customers or citizens (bringing new products or services to market quickly, reliably, and at high quality levels). To do this we have to balance the necessary processes and governance to ensure IT projects’ success with the imperative to foster innovation and deliver quality and speedily to market.

So as an enterprise architect, what do you do when a end-user asks forgiveness, instead of permission?

Circumventing the CIO—What’s the Harm?

Leadership Development and Enterprise Architecture

Fortune Magazine, 1 October 2007, reports on the world’s best companies are finding out that “no matter what business they’re in, their real business is building leaders.”

“’People are our greatest asset’, CEOs always say that. They almost never mean it. Most companies maintain their office copiers better than they build the capabilities of their people.” But now companies are finding in this high liquidity market, that they are less dependent on financial capital, and more on human capital, and so they are getting serious about leadership development!

Fortune provides a number of good ideas for organizations to help develop their future leaders:

1. Invest in leadership—“you don’t build leaders on the cheap.” You’ve got to invest not only money, but also the time of the organization’s executives to help develop leaders.
2. Identify leaders early—“begin to evaluate leadership capability on day one of employment.” Moreover, begin their leadership development early.
3. Assign leadership positions strategically—assign promising leaders to work on things they need work on, rather than those things they are already good at: challenge them!
4. Give lots of honest feedback—Provide feedback on a continuing basis and make it candid!
5. Inspire leaders to perform—motivate performance through sense of mission; passion for one’s job in an organization is contagious.

In a world economy built on human capital, organizations must develop their leaders and mean it!

While many incorrectly think of enterprise architecture as simply a technology-based endeavor, EA is really a broad-based blueprint for the organization.

In User-centric EA, we look to build the capabilities of the organization to meet mission requirements: this includes everything from technology solutions, to more efficient business processes, to information sharing, to human capital development.

Previously, I have called for a human capital reference model (and persepctive) to be added to the Federal Enterprise Architecture (FEA):

• Peter Principle and Enterprise Architecture
• Human Capital is Missing Perspective
  

The pressing need for more and better leadership (and management) development is yet another reason to finally get this done by really focusing attention on the organization’s human capital needs through its inclusion in the FEA.

Leadership Development and Enterprise Architecture

IT Strategic Plan and Enterprise Architecture

User-centric Enterprise Architecture supports the development of a meaningful IT strategic plan for the organization. Based on my experience in strategic planning, there are a number of core goals that should be represented in the IT Strategic Plan. These are as follows:

1. Information —delivering the right information to the right people at the right time; providing for information management, including information sharing, information assurance, privacy, accessibility, and records management.
2. Technology — developing and maintaining a sound, secure, reliable, cost-effective IT infrastructure that enables mission execution.
3. Process — supplying world-class service to customers, by providing defined, repeatable, and measurable processes for systems development life cycle, configuration management, change control, and problem resolution; also, facilitating business process improvement and reengineering.
4. People — ensuring the education, training, certification, and personal and professional development of IT staff.
5. Governance — managing IT though structured governance processes including capital planning and investment control, enterprise architecture, IT planning, and portfolio management.
6. Stewardship — administering resources including IT assets, finance, and human capital for the design, development, maintenance, and operation of IT solutions.

Together, these six goals provide the foundation for a sound IT strategic plan.

As a visual representation, I see these goals in the following way: First there is a Venn diagram in the center composed of People, Process, and Technology. This diagram is surrounded by a circle made up of sound Governance. Emerging from this circle and Venn diagram is Information (and IT capability) provided to the organization to optimize business processes and enable mission execution. And underlying all this is a foundation of responsible Stewardship of IT resources.

IT Strategic Plan and Enterprise Architecture

IT Projects - Get It Right or Fix It Later?

The Wall Street Journal 25 September 2007 reports on a new model being called the “wave of the future”, where IT projects are rolled out “on schedule…even if all the kinks haven’t been worked out” and then fix it later, as problems arise.

The idea of this model is that by rolling out and fixing problems on the fly, you avoid extensive schedule delays and cost-overruns common with IT projects.

Arizona University followed this model in rolling out their enterprise resource planning (ERP) system and it was hailed as “highly successful” by a VP at Oracle, even though “there were payroll mistakes that left some [3000!] workers unpaid, underpaid, or overpaid.”

“Oracle hailed it as a model for both universities and corporations to follow.” The strategy is to “implement, adapt, grow.”

This model of fix it later is being used by “Internet companies like Google Inc. These companies label the software they release ‘beta,’ meaning that it is good enough to use, but it isn’t finished. Sometimes they keep it that way for years, using feedback from users to create ever more-refined versions.”

In the fix it later model, you “admit from the start that there will be mistakes; then work through the glitches [after rollout] with users’ help. This is the opposite of the traditional model that says companies “take their time and don’t start using a new computer system until they are convinced almost everything works right.”

Which approach is better?

From a User-centric Enterprise Architecture point of view, we have to balance two competing drivers.

• One is the importance of meeting user needs and mission requirements, and this means that we don’t delay important IT rollouts unnecessarily, incurring schedule delays, cost overruns, and unmet requirements—This sides with the Fix It Later model.
• On the other hand, we don’t compromise the mission by taking unnecessary risks and rolling out IT systems that are not tested ready and reliable—This sides with the Get It Right model.

Perhaps, the best IT model is a hybrid that I would call—“Get It Right, On Schedule and Within Budget!”

IT Projects - Get It Right or Fix It Later?

The Art of War and Enterprise Architecture

Sun Tsu (544 BC – 496 BC) is the author of The Art of War (an immensely influential ancient Chinese book on military strategy).

The following are three lessons from The Art of War for Enterprise Architecture:

1) Strategy is Critical

“Tzu-lu [a disciple of Confucius] said, supposing you had command of the Three Hosts, whom would you take to help you? The master [Sun Tsu] said, the man who was ready to beard a tiger or rush a river without caring whether he lived or died—that sort of man, I should not take. I should certainly take someone who approached difficulties with due caution and who preferred to succeed by strategy.” (The Art of War)

Sun Tsu recognizes the importance of strategy and the danger of rash actions. Similarly, User-centric EA identifies the needs of the organization and its users and develops an appropriate plan for the enterprise to execute. The well thought out EA plan guides the organization in lieu of rash and flailing actions of individuals.

2) Agility is Tactic #1

“Just a water adapts itself to the conformation of the ground, so in war one must be flexible…this is not in any sense a passive concept, for if the enemy is given enough rope he will frequently hang himself. Under certain conditions, one yields a city, sacrifices a portion of his force, or give up ground in order to gain a more valuable objective.”

User-centric EA must always be flexible and adapt to the needs of its users and the enterprise. It’s easy to get caught up in ivory-tower architecture efforts, rigid EA plans, and governance structures that hinder rather than help progress. But if we remember that the “more valuable objective” is the mission execution of the organization, then we put these needs first and foremost and adjust the architecture to it.

For example, in Hurricane Katrina, when action on the ground was needed to be taken immediately to save lives, governance was loosened to allow the enterprise to adapt quickly.

3) Unification is strength

“He whose ranks are united in purpose will be victorious…the appropriate season is not as important as the advantages of the ground; these are not as important as harmonious human relations.”

In User-centric EA, the enterprise is unified (and focused) in meeting user requirements, executing on mission, and moving the organization forward in a structured, orderly way. By everyone following the same script (the target and transition plan), organizational progress is faster, deeper (the change is up and down the organizational ranks), and more meaningful (since everyone is on board).

The Art of War and Enterprise Architecture

Agile Planning and Enterprise Architecture

The Wall Street Journal in conjunction with MIT Sloan School of Management on 15 September 2007 reports that “markets, technologies, and competition are becoming more dynamic by the day. To succeed in this environment…requires a whole new level of flexibility.” Instead of strategy that “too often locks managers into decisions that may turned out to be flawed, because something outside their control doesn’t go as planned. What is needed is…flexibility into strategy—a plan that lays out a series of options for managers to pursue or decline as developments warrant.”

By practicing agile planning (as I call it), decisions are broken down into stages, where management can review events and decide whether “to proceed, hold back, or retreat at each stage” or alter course altogether.

From a User-centric EA perspective, I really like the idea of agile planning in coming up with the architecture target and transition plan. What we may think today is the best business or technical plan to meet user needs, may not be the case 6 months or a year later. Moreover, as plans extend beyond 3-5 year timeframe, the ability to hit the target is often grossly exaggerated.

The concept of agile planning is to come up with milestones and then based on event-driven triggers follow through to a series of next steps. Agile planning gives the enterprise tremendous flexibility to adjust to changes (whether internal or external-driven), and not get trapped in the “planning pit” , whereby decision-makers are caught in the decision hole that they dug for themselves.

While as planners, we cannot be wishy-washy—we must develop a clear way ahead for the organization—developing the capability to move forward, yet be nimble enough to adjust to changing circumstance is the way to build a truly wonderful plan.

Agile Planning and Enterprise Architecture

Vision, Goals, and Enterprise Architecture

In the book, First Things First by Stephen Covey, the author provides insight into setting vision and goals that can be applied on a personal and leadership level.

What is VISION?

“The power of vision is incredible!”

“Vision is the best manifestation of creative imagination and the primary motivation of human action. It’s the ability to see beyond our present reality, to create, to invent what does not yet exist, to become what we not yet are. It gives us capacity to live out of our imagination instead of memory.”

“The passion of vision…we call it ‘passion’ because this vision can become a motivating force so powerful it, in effect, becomes the DNA of our lives. It’s so ingrained and integrated into every aspect of our being that it becomes the compelling impetus behind every decision we make. It is the fire within—the explosion of inner synergy…this passion can empower us to literally transcend dear, doubt, [and] discouragement.”

What are GOALS?

“When we set a goal, we’re saying, ‘I can envision something different from what is, and I chose to focus my efforts to create it.’ We use our imagination to keep the goal in mind, and independent will to pay the price to achieve it.”

“Self-awareness prompts us to start where we are—no illusions, no excuses—and helps us to set realistic goals. On the other hand, it also doesn’t allow us to cop out with mediocrity. It helps us recognize and respect our need to stretch, to push the limits to grow. So much of our frustration in life comes as a result of unmet expectations, the ability to set goals that are both realistic and challenging goes a long way to toward empowering us to create peace and positive growth in our lives.”

“A principle-based goal is…the right thing, for the right reason, in the right way.” This is based on the following:

• Conscience—“through conscience, we connect with the passion of vision and mission and the power of principles.”
• Creative Imagination—“through creative imagination, we envision possibility and synergistic, creative ways to achieve it.”
• Self-Awareness—“though self-awareness, we set goals with realistic stretch and stay open to conscience-driven change.”
• Independent Will—“through independent will, we make purposeful choices and carry them out; we have the integrity to walk our talk.”

As EA practitioners, we are leaders in our organizations. As leaders, we need to have a clear vision for motivating, synergizing, and giving us the imagination to see beyond our present reality. Additionally, as EA leaders, we need to develop principle-based goals that focus efforts, are challenging yet realistic, and help us to maintain our integrity.

EA leaders must have a vision and goals for not only the development of the EA program to further IT planning and governance and enhance decision-making in the enterprise, but EA leaders must also have vision and goals for the enterprise itself—what is the right things for the organization, for the right reason, and in the right way—this is manifested in the EA target architecture and plans.

Of course, the executives and subject matter experts in the organization ultimately have the vision and goals that drive mission execution and performance. However, EA is in a unique position to integrate those various views and bring synergy and consensus to a way ahead.

EA is an awesome responsibility to lead. EA is a stewardship, a trust. As stewards, EA is called to exercise responsible care over the enterprise baseline and target architectures, IT plans, and governance.

Vision, Goals, and Enterprise Architecture

Shooting the Messenger and Enterprise Architecture

The Wall Street Journal, 11 September 2007 reports that the “everyone knows blaming the blameless bearer of bad news doesn’t help, but we do it anyway. It’s…the gulf between knowing a problem and solving it.”

The article continues, “Big bureaucracies are set up to place human barriers around decision makers. Today there’s the added protection of automated phones and web sites that bury contact information for real people. So the buck stops in the lower rungs of the hierarchy.”

“The government agency…sent lower level staffers to break news to clients that they didn’t get approved…’the true irony of the situation is sending in someone who is less qualified to address a hostile situation, and that creates more hostility, which makes it more likely for him to get shot.’”

The following day, 12 September 2007, the Wall Street Journal reported in another article about another situation of shooting the messenger, as follows: “American Airlines told the Transportation Security Administration in July, that a passenger on a flight to New York had slapped a flight attendant across the face when the plane was ordered emptied in Miami after bad weather kept the flight from leaving. Police were called.”

“Those middlemen aren’t responsible for disruptive decisions or business failures. But they’re the poor souls held accountable.” (WSJ, 11 September 2007)

As EA practitioners, we are often the messengers of corporate news; we analyze problems areas and uncover gaps, redundancies, inefficiencies, and opportunities. Often, others in the organization do not want to hear about these problems and do not want EA to be providing the solutions. Instead, they look to shoot the EA messenger. Rather than pointing fingers and letting off steam at the EA folks doing their jobs, how about teaming up, collaborating, and working to improve the organization and make things better for everyone!

Shooting the Messenger and Enterprise Architecture

NASA and Enterprise Architecture

First all of all let me say that NASA and its people are totally awesome.

“On July 20, 1969, the human race accomplished its single greatest technological achievement of all time when a human first set foot on another celestial body.” (NASA)

The trip to from the earth to the moon is approximately 240,000 miles!! (adapted from Wikipedia)

“Neil Armstrong and Edwin Aldrin spent a total of 21 hours on the Moon, two-and-a-half of them outside the landing module. A further 10 astronauts traveled to the Moon in another six missions with the final manned lunar landing, Apollo 17, completed in December 1972.” (adapted from http://news.bbc.co.uk/)

On 20 September, 2005, NASA Administrator Michael Griffin announced a New Spaceship Designed for Travel to Moon and Mars. Griffin defended the $104 billion dollar lunar program, saying it is intended to make President Bush's Vision for Space Exploration a reality. The price of the new lunar program will be spread out over 13 years and adjusted for inflation represents about 55 percent of what the Apollo space program cost in the 1970s. (adapted from globalsecurity.org)

Question:
Why haven’t we been able to send man back to the moon (or to other planets in the last 35 years)? And why do we need to invest another $104 billion to do something that we should already know how to do? Finally, if we were able to go to the moon before the unbelievable technological advances of the last 35 years, why can’t we do it today?

Honest answer:
I don’t really know.

Hypothetical answers:

• The alien technology that we acquired to make the trips to the moon has either been depleted or destroyed by the Russians. (Ha ha ha)
• User-centric EA wasn’t around 35 years ago, and therefore, the business and technical processes, information, and means of governance weren’t well documented and have been lost to mankind, and now we need to recreate the whole darn thing (hopefully not).

Barring another Roswell alien landing, we will have to thank the Clinger-Cohen Act for helping us ensure that this critical (and expensive) information is better documented going forward.

NASA and Enterprise Architecture

Information Management and Enterprise Architecture

What is the Information Age?

“Alvin Toffler, a famous American writer and futurist, in his book The Third Wave, describes three types of societies, based on the concept of 'waves' - each wave pushes the older societies and cultures aside.

• First Wave—the society after agrarian revolution that replaced the first hunter-gatherer cultures.
• Second Wave—the society during the Industrial Revolution (ca. late 1600s through the mid-1900s), based on mass production, mass distribution, mass consumption, mass education, mass media, mass recreation, mass entertainment, and weapons of mass destruction. You combine those things with standardization, centralization, concentration, and synchronization, and you wind up with a style of organization we call bureaucracy."
• Third Wave—the post-industrial society, also called the Information Age, Space Age, Electronic Era, Global Village, scientific-technological revolution, which to various degrees predicted demassification, diversity, and knowledge-based production.”

What is a knowledge worker?

“Peter Drucker, in 1959, coined the term Knowledge worker, as one who works primarily with information or one who develops and uses knowledge in the workplace. Knowledge Workers are now estimated to outnumber all other workers in North America by at least a four to one margin (Haag et al, 2006, pg. 4). A Knowledge Worker's benefit to a company could be in the form of developing business intelligence, increasing the value of intellectual capital , gaining insight into customer preferences, or a variety of other important gains in knowledge that aid the business.” (Toffler and Drucker sections are adapted from Wikipedia)

How does EA fit in the Information Age and support the knowledge worker?

EA is a process for capturing, analyzing, and serving up information to achieve improved IT planning, governance, and decision making. So, EA works with data and information and supports the knowledge worker in the following way:

• Acquisition—captures business and technical information
• Analysis—analyzes information problem areas and identifies gaps, redundancies, and opportunities for standardization, consolidation, integration, interoperability, and so on
• Description—describes data and information using metadata and various information products, such as profiles, models, and inventories
• Classification—catalogues data using taxonomies (i.e. schemas) and ontologies (that relate the data)
• Warehousing—stores the data in a repository
• Dissemination—makes the information available for discovery, exchange, reporting, and queries
• Management—establishes data standards, institutes policies and practices for describing, registering, discovering and exchanging information; administers configuration management of the data; ensures data backup and recovery.

In User-centric EA, all aspects of information management (in terms of development, maintenance, and use of information products) are done with the enterprise and end-user in mind. User-centric EA seeks to make all aspects of EA information useful (i.e. relevant—current, accurate, complete) and usable (i.e. easy to understand and readily accessible) for the information age enterprise and knowledge workers that we support!

Information Management and Enterprise Architecture

Engaging Employees Hearts and Minds and Enterprise Architecture

The Wall Street Journal, 1 October 2007 reports that “employers should—and increasingly do—care about creating a great workplace.”

Companies are realizing the “the human beings who execute the goals of business are more than just cogs in a wheel.” Companies are now showing they do care more about their workers, through:

• Best workplace lists—vying for venerated positions on best-workplace lists
• Luring recruits—“pledging their devotion to work-family balance” and other employee-friendly benefits
• Employee engagement—boasting about their level of worker-commitment, which manifests itself in low employee turnover; or employees volunteering to make an extra effort on the job

In the traditional rigid, controlling workplace, workers’ needs are left unmet; over time, this “erodes concentration, commitment, and creativity.” Good workplace policies “enable employees to manage their large lives, freeing them to apply more brainpower to complex information-age jobs.”

What’s more, organizations are finding that creating a great workplace for employees actually pays off in dollars (i.e. it “actually causes an increase in a company’s overall financial performance.”)

The New York Conference Board found in a study last year “clear and mounting evidence that employee engagement is strongly correlated to ‘productivity, profit, and revenue growth.’”

User-centric EA is driven to mission execution and meeting end user needs (including employee satisfaction). This is why I have been a long-time proponent for adding a human capital reference model and perspective to the Federal Enterprise Architecture. Balancing these two approaches (mission and employee) creates the synergy that organizations need for long-term success. There is a motto that I often use that expresses this right on—“mission first, people always!”

Engaging Employees Hearts and Minds and Enterprise Architecture

Guns versus Butter Model and Enterprise Architecture

“In economics, the guns versus butter model is the classic example of the production possibility frontier. It models the relationship between a nation's investment in defense and civilian goods. In this model, a nation has to choose between two options when spending its finite resources. It can buy either guns or butter, or a combination of both. This can be seen as an analogy for choices between defense and civilian spending in more complex economies.” (Wikipedia)

The guns versus butter model teaches us that you cannot have it all! There are clear limitations to resources, and it is not possible to produce or spend beyond that.

Yes, of course, our resources can be extended by increasing the limits of production through for example, advances in technology that make us more efficient (like advances in automation or agricultural production). Similarly, we can spend more than we have on both guns and butter, through deficit spending, although this is a temporary phenomenon where we borrow to spend now, and this must be repaid in the future.

The point is that as society, organizations, or individuals with finite resources, we must make choices, since we can’t have it all. Even Bill Gates and Warren Buffet with their billions of dollars, have to make choices too (although their choices may be a little bit larger than ours—should I buy this mega-company or that one).

From a User-centric Enterprise Architecture perspective, the lesson of the guns versus butter economic model is very important. As we baseline the architecture of the organization and see all that is wrong with it (gaps, redundancies, inefficiencies, and opportunities), we are tempted to want to fix everything, right away. In other words, the target architecture becomes an unrealistic wish list and one that seeks to solve all that is wrong in the enterprise. One of my associates calls this the feed the world solution, which he promptly points out are those initiatives that never really go everywhere, because you can’t “swallow an elephant in one bite.”

In EA, we have to develop a target architecture and transition plan that is realistic: one that takes into account the limitations of resources as well as the limitations of the organization to rapidly undergo change. It becomes an issue of priorities. A good architect not only helps the organization identify the possibilities for improvement, but also works with leadership and stakeholders to prioritize those and phase them in. realistically, through the transition plan.

Guns versus Butter Model and Enterprise Architecture

First Things First and Enterprise Architecture

In the book “First Things First” by Stephen Covey, the author describes an important dilemma of what’s important to us in life versus how we actually spend our time. Covey uses the metaphor of the clock and the compass to explain this.

• The clock—“our commitments, appointments, schedules, goals, and activities—what we do with, and how we manage our time.”
• The compass—“our vision, values, principles, mission, conscience, and direction—what we feel is important and how we lead our lives.”

The idea here is that we “painstakingly climb the ‘ladder of success’ rung by rung—the diploma, the late nights, the promotions—only to discover as we reached the top rung, that the ladder is leaning against the wrong wall.”

“Absorbed in the ascent, we left a trail of shattered relationships or missed moments of deep, rich living in the wake of the intense overfocused effort. In the race up the rungs we simply did not take the time to do what really mattered most.”
What is really important?

Covey sums it up nicely, as follows:

• To live—our physical needs (“food, clothing, shelter, economic well-being, health”)
• To love—our social needs (“to relate to other people, to belong, to love, to be loved”)
• To learn—our mental needs (“to develop and to grow”)
• To live a legacy—our spiritual needs (“to have a sense of meaning, purpose, personal congruence, and contribution” and most important of all to serve and sacrifice for the one almighty G-d)

In case you don’t recognize it, these align nicely to Maslow’s Hierarchy of Needs.

http://usercentricea.blogspot.com/2007/08/maslows-hierarchy-of-needs-and.html

Maslow “in his last years, revised his earlier theory and acknowledged that the peak experience was not “self-actualization, but “self-transcendence,” or living for a higher purpose than self.

George Bernard Shaw put it this way:

“This is the true joy in life…being used for a purpose recognized by yourself as a mighty one…being a force of nature instead of a feverish selfish clod of ailments and grievances, complaining that the world will not devote itself to making you happy…I am of the opinion that my life belongs to the whole community and as long as I live it is my privilege to do for it whatever I can…I rejoice in life for its own sake. Life is no brief candle to me. It’s a sort of splendid torch which I’ve got to hold up for the moment and I want to make it burn as brightly as possible before handing it on to future generations.

Covey says it this way:

“The main thing is to keep the main thing the main thing.”

As an enterprise architect, who works everyday to build a better organization, with efficient and effective business processes, timely and meaningful information supporting the business, and information technology solutions that drive mission execution, I thought it was important to put this important job in perspective. Because in order to be effective in the role as an enterprise architect, we have to realize that “balance and synergy” among the four needs—physical, social, mental, and spiritual—are imperative.

As Covey states: “we tend to see them [these needs] as separate ‘compartments’ of life. We think of ‘balance’ as running from one area to another fast enough to spend time in each one of a regular basis [or not!]…but [this] ignores the reality of their powerful synergy. It’s where…we find true inner balance, deep fulfillment, and joy.”

First Things First and Enterprise Architecture

Functionalism and Enterprise Architecture

“Functionalism is about the structure and workings of society. Functionalists see society as made up of inter-dependent sections which work together to fulfill the functions necessary for the survival of society as a whole. The theory is based around a number of key concepts. First, society is viewed as a system – a collection of interdependent parts, with a tendency toward equilibrium. Second, there are functional requirements that must be met in a society for its survival (such as reproduction of the population). Third, phenomena are seen to exist because they serve a function. Functionalists believe that one can compare society to a living organism, in that both a society and an organism are made up of interdependent working parts (organs) and systems that must function together in order for the greater body to function.” (Wikipedia)

User-centric EA is firmly grounded in functionalism. EA sees the enterprise as composed of interrelated parts that rely on each other in order to function and survive. Each individual, group, department, division and so on plays a critical role (like organs in a body).

Enterprise architects develop models of the business, data, and systems that show exactly what the parts (or elements) in the organization are and how they interrelate and function—this is functionalism. For example, in the business model, the actors perform activities (or tasks); the activities make up processes, and the interrelated processes make up functions. Clearly there is a structure and interdependency of like components that fulfills enterprise functions. Similarly, the organization’s IT hardware and software products are combined with databases to make up applications with specific business functions. The functionally interrelated applications combine to make up systems. Again, the collection of independent parts (products, applications, systems) forms collections that serve specified functions for the organization.

If a business activity or process or an IT product or application no longer serves a necessary or viable function for the growth and “survival” of the organization or if there are redundancies in these, then the architect recommends that those unnecessary components be discontinued. Similarly, if there are gaps or inefficiencies in the business or IT, where required functions are not being served or served well, then the architect recommends a those gaps be filled or those business or IT areas be reengineered.

EA’s basis in functionalism is what makes it grounded in the realities of the organization needs for survival and maturation.

Functionalism and Enterprise Architecture

Hoshin Kanri and Enterprise Architecture

“Hoshin Kanri is a strategic planning methodology that uses a Shewhart Cycle (Plan-Do-Check-Act) to create goals, assign measurable milestones, and assess progress.” (Adapted from Wikipedia)

In Hoshin Kanri (HK) “the vision must be shared by all, so that everybody acts (at his own level) consistently to hit targets. Each company layer or function defines its own targets, according to the top ones. The principle goes cascading down to the base (vertical diffusion) or in coordination between divisions (horizontal collaboration) or a mix of both. The concept’s idea states: if all underlying objectives are met, the higher objective is automatically met, and so on, cascading up.”

(http://membres.lycos.fr/hconline/hoshin_us.htm)

The four phases:

1. Plan— higher objectives set by uppermost authority and in cascading fashion, each sub-division defines its own objectives, based on the level above (alignment phase).
2. Do—everyone carries out their objectives
3. Check—monitor, evaluate, and report on progress
4. Action—make course corrections to improve the process and achievement of results (Adapted from Wikipedia)

In general, setting the ‘right’ objectives means they should be SMART:

1. Specific
2. Measurable
3. Achievable (yet ambitious)
4. Realistic
5. Time-Specific

(adapted from http://www.valuebasedmanagement.net/)

In HK objectives should also:

• Improve current ways of doing things (efficiency, effectiveness, cost-savings…)
• Innovate (new techniques, technologies…)

How does HK differ from Management By Objective (MBO)?

• HK is focused on the process, while MBO is focused on the target
• HK defines how it will achieve the target, while MBO does not
• HK uses lot of communications and builds consensus (horizontally and vertically in the organization), while MBO is more top-down management

(adapted from http://membres.lycos.fr/hconline/hoshin_us.htm)

In short, Hoshin Kanri seems like an evolution of Management by Objective.

The methodology and principles of Hoshin Kanri is a terrific match with User-centric EA. Both focus on developing SMART plans, improving processes, using innovative (yet trusted) technologies to meet mission and user needs, communicating clearly with stakeholders, and building consensus on a way ahead.

Hoshin Kanri and Enterprise Architecture

Succession Planning and Enterprise Architecture

“Succession Planning—is the process of identifying and preparing suitable employees to replace key players within an organization. From the risk management aspect, provisions are made in case no suitable internal candidates are available to replace the loss of any key person…a careful and considered plan of action ensures the least possible disruption to the person’s responsibilities and therefore the organization’s effectiveness. A succession plan clearly sets out the factors to be taken into account and the process to be followed in relation to retaining or replacing the person.” (Adapted from Wikipedia)

How difficult can succession planning be?

The Wall Street Journal, 8-9 September, 2007, describes how difficult succession planning can be and especially for an organization such as Cirque du Soleil (where 21 performers are former Olympians and the majority has backgrounds in acrobatics or traditional circus arts): “Working with such singular talent forces Cirque to walk a tightrope. The artistic side is always looking for new acts. The business side wants to make sure they aren’t irreplaceable.”

How far will some organizations go to manage their succession planning?

Scouts [from Cirque]…travel the world, scour the internet, and vet thousands of unsolicited applications to fill 500 new roles. In their quest, they have created a database of 20,000 potential performers. Among them: 24 giants (including a Ukrainian who is 8 foot 2), 23 whistlers, 466 contortionists, 14 pickpockets, 35 skateboarders, 1,278 clowns, 8 dislocation artists, and 73 people classified simply as small.”

In User-centric EA, succession planning, although not normally part of an EA program, should be considered for future addition. Particularly, with the addition of a human capital perspective to EA, the development and maintenance of succession plans would be an excellent fit!

Succession Planning and Enterprise Architecture

Enterprise Architecture: Catalogues, Portfolios, and Inventories

There are three levels of architecture in the organization: enterprise, segment, and solutions. This is explained in a prior post.

Each level of the architecture identifies and categorizes business and technical information. However, the information captured in the three architecture levels (enterprise, segment, and solutions) differs as to their level of detail.

Here’s how this works:

• Catalogues—Enterprise architecture maintains catalogues of strategic-level enterprise assets. For example, EA provides catalogues of enterprise business functions and activities, enterprise systems, and enterprise hardware and software products and standards.
• Portfolios—Segment architecture maintains portfolios of items scoped to the individual lines of business (LOB), at a medium level of detail, with impact focused on business outcomes. For example, a portfolio of systems or databases relevant to the functioning of a specific LOB such as for Finance, HR, and so on.
• Inventories—Solutions architecture maintains inventories of configuration items for the enterprise. The configuration items are at the maximum level of detail for maintaining control of changes. This is used, for example, for software configuration management and for engineering support of IT infrastructure.

All three types of information products types—Catalogues, Portfolios, and Inventories—contain similar types of information pertinent to the organization; however, each product functions at a different level in the architecture—enterprise, segment, and solutions. Each of the information product types should be traceable and align to the next, so that inventories roll up into portfolios, and portfolios roll up in total to the enterprise asset catalogues. In this way, the architecture framework is consistent throughout the organization, items are traceable at all levels—from the solutions developers up to the strategic-level EA—and items can be viewed at the appropriate level of detail depending on whether the viewer is a senior leader, an executive decision-maker in the LOB, or a solution provider (“fixer-doer”).

Some organizations have chosen for simplicity’s sake to call all three of these product types “inventories.” That is acceptable, with the understanding that these “inventories” are providing different levels of detail corresponding to the different levels of architecture.

Enterprise Architecture: Catalogues, Portfolios, and Inventories

Gestalt Theory and Enterprise Architecture

"Gestalt theory is a theory...that the whole is greater than the sum of its parts...This is in contrast to the "atomistic" principle of operation of the digital computer, where every computation is broken down into a sequence of simple steps, each of which is computed independently of the problem as a whole." (Wikipedia)

Gestalt theory and the atomistic principle are important lenses with which to understand User-centric EA. Both gestalt and atomistic views are used to build the enterprise architecture.

• Modeling—“A model is a pattern, plan, representation, or description designed to show the structure or workings of an object, system, or concept.”(Wikipedia) Enterprise decompose the business and IT of the enterprise to view functions and activities, information and data, and manual and automated solutions for supporting those. In modeling the organization and decomposing it into its foundational elements, we view both the distinct parts as well as the relationship between those; this is the atomistic principle is at work. architects develop business, data, and systems models to show the elements and relationships in the enterprise, identify the business processes, information requirements, and technology solutions. To perform this modeling the architects
• Planning and Governance—EA develops the baseline, target, and transition plan, and develops or supports the IT strategic and tactical plans. Further, EA facilitates the IT governance process by conducting IT projects, product, and standard reviews and providing finding and recommendations to ensure business and technical alignment and architecture assessment for the organization. Both of these functions of EA require the synthesis of “boat loads” of business and technical information to develop realistic plans and valuable reviews in support of sound investment and portfolio management. In developing the plans and managing the IT governance for the organization, we are synthesizing information to create a holistic view of where we are, where we going, and how we will get there. This involves bringing together the multiple perspectives of the architecture (performance, business, information, service, technology, security, and hopefully soon to be added human capital) to get a view of the organization that is larger than the sum of its parts. The architecture is more than just a federation of these perspectives, and incorporates the analysis of gaps, redundancies, inefficiencies, and opportunities used to drive business process and technical reengineering and improvement in the organization. This is the gestalt theory at work.

Together, the gestalt theory and atomistic principle show us how enterprise architects decompose or break down the organization into its parts and then synthesize or build it back together again, such that the whole is now greater than the sum of its parts. The ability to do this is the marking of a true enterprise architect master!

Gestalt Theory and Enterprise Architecture

Use Cases and Enterprise Architecture

User-centric EA fulfills many different needs (as portrayed through Use Cases) in the enterprise.

In the Journal of Enterprise Architecture (JEA), August 2007, the authors of the article “Analysis and Application Scenarios of Enterprise Architecture: An Exploratory Study” (Winters, Bucher, Fischer, and Kurpjuweit) provide a variety of these “application scenarios” for EA.

Use Cases can help us understand the importance and benefits of Enterprise Architecture by showing its application to real-world scenarios. Below is a list of key use cases for EA (adapted from JEA):

1. Adoption of Commercial and Government Off-The-Shelf Software (COTS/GOTS)—informs on enterprise IT products and technical standards for integration, interoperability, and standardization.
2. Business Continuity Planning—identifying the dependencies between business processes, application systems, and IT infrastructure for continuity of operations.
3. Business Process Optimization—reengineering or improving business processes based on modeling of the business processes, the information required to perform those, and the technology solutions to support those.
4. Compliance Management—helps verify compliance with legal requirements such as privacy, FOIA, Section 508, records management, FISMA, and so on.
5. Investment Management—supports Investment Review Board; determines business and technical alignment and architecture assessment of new IT investments.
6. IT Business Alignment—aligning IT with “business, strategies, goals, and needs.”
7. IT Consolidation—“reveals costly multi-platform strategies and wasted IT resources originating from personal preferences of certain IT stakeholders and/or a lack of enterprise-wide coordination.”
8. IT Planning—develops target architecture and transition plan; develops or supports IT strategic plan and tactical plans.
9. Performance Management—Management of IT Operations Costs through the development of IT performance measures to manage IT resources.
10. Portfolio Management—categorizes IT investments into portfolios and prioritizes those based on strategic alignment to the target architecture and transition plan.
11. Post Merger and Acquisition Integration—identifies gaps, redundancies, and opportunities in business processes, organizational structures, applications systems, and information technologies.
12. Procurement Management—aids sourcing decisions; specifies standards, provides reviews of new IT investments.
13. Project (Initialization) Management—specifies projects requirements, looks at the potential for existing systems to meet user needs, and avoids redundant development activities.
14. Quality Management—document business processes, information requirements, and supporting IT; helps ensure performance.
15. Risk Management—managing technology risks; understanding which technology platforms support which business processes.
16. Security Management—documenting business and IT security and defining user roles and access rights.

When done right, EA helps to create “order out of chaos” for the execution of business and IT in the organization.

Use Cases and Enterprise Architecture

Strategy and Enterprise Architecture

There are many schools of thought when it comes to strategic planning in which the organization develops its strategic plan through the following means:

• Design – facilitating a fit between the internal capabilities and external possibilities; strategy is prescriptive.
• Positioning – selecting the competitive positions in the marketplace they desire to occupy (examples include: low cost leader, high quality supplier, niche player, #1 service provider, and so on).
• Entrepreneurial – grounding it on the leader, who is the visionary guiding the organization forward; there is no formal strategic plan.
• Cognitive – understanding and responding to how customers and competitors perceive us.
• Power – Negotiating, persuading, networking, developing alliances, and lobbying; all based on power and politics.
• Cultural – Deriving organizational shared beliefs and social interactions.
• Learning – trial and error based on results of strategy implementation.

(Adapted from American Management Association)

In User-centric EA, it is helpful to understand all these approaches to strategic planning. The schools of though are not mutually exclusive, but rather all affect—to a greater or lesser degree—how the EA target and transition plan is formed.

What I believe is fascinating is that planning is only partially about the plan itself (i.e. what the plan actually contains and prescribes), and that much of planning is about the process for developing it.

The process of planning benefits the organization almost as much as the end-product plan itself, since the process is a journey of self-discovery for the organization. In other words, if the plan was just dropped on the organization—without the process of having developed it—it would be of little to no value. The process of planning teaches the organization what it is currently, what challenges and opportunities it faces, and how to adapt, incrementally change, and occasionally transform itself. The planning process is quite involved and often includes aspects from all the schools of thought, including: designing a capabilities-possibilities fit for the organization, positioning it in the marketplace, incorporating the vision of the leader, identifying perceptions of customers and competitors, navigating through organizational politics, realizing a shared organizational culture, and continuous learning through it all.

Strategy and Enterprise Architecture

Driving Innovation and Enterprise Architecture

The Wall Street Journal, 24 September 2007 reports that “managing innovation is one of the biggest challenges that companies face.” Why? “They not only need to come up with new ideas, but also need to foster a culture that encourages and rewards innovation.”

Douglas Solomon, the Chief Technology Officer of IDEO (an innovation and design consulting firm) provides some insights on how to make a culture more innovative:

In general, “corporations inherently have antibodies that come out and try and kill any innovation.” Small companies don’t have sufficient resources and big companies “don’t always have the thought processes and the skills to really think outside their current business, nor the permission to really do it.”

Here are four things organizations need to be innovative:

1. Degree of discomfort—“there are still people who say, ‘if it ain’t broke, don’t fix it. And I don’t think these companies are in a really good position to change…you have to have a certain degree of discomfort in your business to be willing to make the changes that are necessary”
2. Design thinking—rather than analytical thinking extrapolating from the past to the future, innovative thinking requires ‘design thinking’, which is rooted in creativity, optimism and is goal-driven, trying to create new possibilities for a new future.
3. Time to innovate—“you have to actually build processes, you have to support people, you have to give them time…to think on their own…you have to provide a reward system for encouraging innovation.”
4. Risk tolerance—“you have to tolerate risk, if you’re going to try to be innovative.” Doug Merrill the VP of engineering and CIO of Google adds that “Every company in the world says ‘don’t ask permission, ask forgiveness.’ Every company in the world says ‘It’s OK to fail.” And for 99% of them, it’s probably not true.”

In User-centric EA, developing a target state and transition plan for an organization requires innovation. If there is no innovation in your target architecture and plans, then you’re just regurgitating the same old stuff to the enterprise and it’s probably of very limited, if any, value. EA must step outside its traditional box and come to the table with innovative ideas and new approaches to the business; that is it’s real value add.

As we see above, being innovative is hard: It requires sometimes going against the grain, standing out amidst nay-sayers and the ‘old guard,’ looking outside the enterprise for best practices and marketplace trends, and being optimistic and open-minded to future possibilities that are not eclipsed by ingrained thinking and turf battles. Finally architecting the future state must be grounded in present realities (including constraints such as resources, politics, and other priorities and requirements), but innovate we must if we are to make a better state tomorrow than the one we have today!

Driving Innovation and Enterprise Architecture

The Situation in Myanmar and Enterprise Architecture

The Wall Street Journal, 28 September 2007 reports that “as Myanmar’s regime cracks down on a growing protest movement, ‘citizen journalists’ are are breaking the news to the world.”

Cellphone cameras, text messaging, blogging, and even satellite phones are enabling democracy movements to subvert oppressive governments from restricting communications into and out of their regimes and sanitizing media coverage of their repressive, cruel rule.

While soldiers fired automatic weapons into a crowd of pro-democracy demonstrators, Burmese citizens were sending photos and text messages to news agencies around the world. And the world responded with warnings and sanctions against the Myanmar government, keeping the death toll to only nine people so far.

“Even in countries like Myanmar, the spread of the Internet and mobile phones has meant the footage will always continue to get through and the story will be told, one way or another.”

If only this technology existed when the Nazis where herding the Jews unto cattle cars and taking them to the myriad of concentration (i.e. extermination) camps—perhaps, the shocking, real-time information and brutal photos would’ve moved the world to action sooner.

In fact, even the last time there was a large scale protest in Myanmar in 1988, the technology was not widely available and the result was a military massacre of more than 3000 civilians!

“Technology has changed everything…now in a split second, you have the story.”

From a User-centric EA perspective, we apply technology solutions to meet information requirements of the end-users in the enterprise. The business of EA is information and technology—those things that are opening up democracy in Myanmar. In EA, the results are improved mission execution and results of operation. That’s in a business or government setting. But how does information flow and technology affect geopolitics?

The answer is greatly, as we can see from the events in Myanmar:

Information technology is not only important to business and consumers, governments and citizens, but it is critical to the world’s progress—IT has geopolitical implications, including:

1. Spreading freedom and human rights
2. Feeding the world’s hungry
3. Healing of the world’s sick
4. Imposing peace and order

“Information is power” and this is enabled and magnified by the application of technology and modern communications. If we use the information technology wisely, we can make the world a better place for everyone!

The Situation in Myanmar and Enterprise Architecture

Yin and Yang and Enterprise Architecture

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

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

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

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

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

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

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

Yin and Yang and Enterprise Architecture

The Hype Cycle and Enterprise Architecture

“A Hype Cycle (term coined by Gartner) is a graphic representation of the maturity, adoption and business application of specific technologies.

Hype cycles characterize the over-enthusiasm or "hype" and subsequent disappointment that typically happens with the introduction of new technologies. Hype cycles also show how and when technologies move beyond the hype, offer practical benefits, and become widely accepted.

The hype cycle comprises 5 steps:

1. "Technology Trigger" breakthrough, product launch or other event that generates significant press and interest.
2. "Peak of Inflated Expectations" frenzy of publicity typically generates over-enthusiasm and unrealistic expectations.
3. "Trough of Disillusionment" Technologies fail to meet expectations and quickly become unfashionable.
4. "Slope of Enlightenment" some businesses continue to experiment and understand the benefits and practical application of the technology.
5. "Plateau of Productivity" the benefits become widely demonstrated and accepted. The technology becomes increasingly stable and evolves in second and third generations.

Hype cycles aim to separate the hype from the reality, and enable executives to decide whether or not a particular technology is ready for adoption.” (adapted from Wikipedia)

The Hype Cycle is a tool that can be used by EA to help evaluate new technologies and whether it’s the “right” time to jump in and invest.

The hype cycle teaches us not to be blind, bleeding edge technology adopters, but rather to allow ample time for the technologies and their applications to mature. Often a swift follower can implement a relatively new technology cheaper, faster, and better than those on the bleeding edge: the kinks have been worked out, the patches applied, and the applicability fleshed out. More important, those technologies that were more hype than substance have been eliminated from the mix.

While early adoption can be a winning strategy (and extremely lucrative) for those gifted to recognize and be able to apply real innovations early on, in most cases, the swift follower is the big winner and the bleeding edge adopter the loser.

The Hype Cycle and Enterprise Architecture