Sustainable Enterprise Architecture

Kirk Hausman

• Publisher: CRC Press
• Year: 2011
• ISBN:
  9781466508996
• Edition: 1
• Topic: Business
• Subtopic: Operations
• Index: Business

Enterprise architecture requires an understanding of all technologies, strategies, and data consumption throughout the enterprise. To this end, one must strive to always broaden knowledge of existing, as well as emerging trends and solutions. As a trade, this role demands an understanding beyond the specificities of technologies and vendor products

Chapter 1

The Impact of Enterprise Architecture

In This Chapter

• An introduction to the concept of enterprise architecture
• An examination of the opportunity costs and ripple effects of decisions made in an enterprise setting
• Considerations for the inclusion of open sources, open standards, and commercial elements in an enterprise network

A house built on unsteady footing will be forever under repair, and the same is true for technology implementations. Information technology has extended into almost every area of business and operational coordination, becoming the glue that holds the modern world together. When an information technology choice is made, the effect of that choice ripples out like the ring of water around a stone dropped into a pond. Poor planning can lead to many problems immediately and for years to come. Decisions made alone, without consideration of the impact each decision may have on other aspects of the overall enterprise, can create turmoil.

Note: The strategies presented herein are not targeted at a particular product or technology. Where examples include such details, they simply reflect actual architecture projects in which the identified solution was implemented.

This text provides an understanding of the mechanisms available for enterprise architecture that will allow planning to be extended from the immediate into a three- to five-year range. These strategies have been used successfully within many different types of organizations, from small office settings through large educational and global commercial enterprises. This text is intended for business and technology professionals, particularly those serving in the capacity of chief information officer (CIO), information technology (IT) director/manager, or some other form of lead architect, but will be understandable to any reader interested in the practice of technology enterprise architecture.

Simple Choice, Complex Impact

It is simple to claim that technology is complex, difficult to understand, and requires an extensive background in many aspects to fully grasp the intricacies of its planning. This claim lies behind the omnipresent need for technologists in almost every business—from small one-office sites to large, globally deployed endeavors—and is brought up regularly to justify salary improvements and yearly technology modernization expenditures.

Counterarguments can be made that each technology choice can be made by a committee or group of information technology professionals and managers, noting the extreme lack of business process integration and project management in many information technology implementations. Although it is true that any choice should be reviewed by a group of skilled individuals, to attempt piecemeal technology decisions is to court failure and heartache. It is imperative that a single office own the business process responsible for overall technology strategy, in order to ensure that all selections fit into a cohesive, interwoven mesh of connectivity.

A Strong Hand

Information technology managers have recently begun to implement formal project management practices in order to avoid the never-ending, constantly changing spectrum of offerings that must be addressed in today’s marketplace. Before project management became a formal part of the enterprise, a single application could take many years in successive attempts, only to be discarded ultimately because the need no longer existed or some other alternative was found in the meantime. The ugly term “feature creep” is a constant enemy to progress in any technology endeavor. When user expectations meet regulatory requirements and operational mandates, clear objectives and scoped guidelines must be in place to allow the steering committee to hold onto the project’s original purpose. It is far too easy to attempt to take a simple calculator application and try to shoehorn in e-mail, calendaring, human resource training, NASA image galleries, and the kitchen sink when programmers and users are set free to do as they please.

A technology architect must possess both business acumen and technological savvy in order to filter through user requirements and sift out “need” from “want,” while also seeing past the technobabble jargon that technologists are wont to use even when dealing with normal mortals who struggle with their VCRs. The architect must identify future technology trends, emerging opportunities, and evolving security requirements. Between the thousands of new viruses created each year and the increasing complexity of regulatory requirements, architects are kept very busy just honing the skills of their trade before they can begin its practice.

Opportunity Costs

Economists know that when a purchase is made, it is made at the expense of other selections that might have been purchased instead. The opportunity cost of a technology selection can be very significant when money is spent to obtain needed skills, implement new solutions, and train users in their operation. Selection of an application platform or code base may later affect the ability of the business to react in an agile manner to changing requirements. A decision on the standard programming style that will be used, such as J2EE or .NET, can affect the options available for authentication platform or provider selections.

Figure 1.1 presents an example of one such common technology project—the selection of a new e-mail platform. This need might arise in response to a consolidation of business units or merger, as a result of new purchasing mandates, or as a part of a technology modernization effort.

Figure 1.1 Effect of e-mail service selection on other related technologies.

The unwary might perceive selecting a new e-mail platform as a simple process, since all platforms use a standard known as the Simple Mail Transport Protocol (SMTP) to transfer messages from sender to recipient. Certainly, however, cost and features are important in the selection, so accountants and users may offer input as well. A committee typically collects user requirements and preferences, identifies purchasing options, and makes a recommendation to upper management, where a simple “go/ no-go” response drives the selection forward.

Ripples in the Pond

Moving beyond the simple issues of cost and features within the e-mail service itself, selecting an e-mail platform will also affect the type of directory service that can be used for log-on authentication, which in turn will affect the choices available for user log-on and identification as well as options for accessible interfaces, encryption, and other extended requirements for connectivity within the enterprise.

Services

The selected platform may need to be interoperable with other e-mail–enabled applications, in which case the code base and authentication systems must be able to integrate with the new selection or applications may need to be rewritten or abandoned. Network fax and voice mail systems may be integrated with the e-mail service to deliver other content into users’ inboxes, while instant messaging and chat functions may provide online awareness and synchronous communication integration with the asynchronous e-mail that is the heart of this selection.

Some e-mail services may provide options for proxy relay systems in remote offices that are not always connected to the business network; others may provide a feature-rich Web-based client that allows users to access e-mail through the Internet. Push-type mobile e-mail technologies such as Research In Motion’s Blackberry and Microsoft’s Smart Phone allow users to avoid the need to log-on to access e-mail—each item is sent directly to the user’s device when received. Selection of a particular platform may affect how users access e-mail on local and remote workstations, mobile computing devices, and newer technologies such as data-enabled telephones.

Business

As e-mail becomes one of many types of communication that users require, organizations are beginning to blend together asynchronous and synchronous means into a common one-stop location—often referred to as a portal. Here, users may receive targeted news, engage in threaded discussions, share documents, manage schedules, read e-mail, chat with other team members through instant messaging, and review operational readiness using business intelligence solutions such as dashboards and automated scorecards.

Whether or not an e-mail selection needs to fit within such an enterprise communication suite, it will also affect data storage, backup solutions, records retention practices, and media management controls based on all applicable regulatory and operational mandates. Defenses must also be integrated to protect against e-mail–borne threats, particularly as more users access their mail through small portable devices whose limited resources cannot support fully featured antivirus defenses. Selection of an e-mail platform affects options available for defenses to filter out spam (unwanted electronic “junk mail”), viruses, and other undesirable content.

Business continuity and disaster recovery planning must also be integrated with the selection. Large-scale disasters such as the terrorist attacks of September 11, 2001, hurricanes such as Rita and Katrina, and fears of contagious pandemics have shown the value of the business continuity of operations that can be provided by adequate planning and effective electronic communications, where the selected platform may be the only means of coordinating a geographically dispersed staff.

Beyond

Thus a simple e-mail service selection will have far-reaching effects by determining all protocols and standards that may be used to access, protect, and consume its functionality. It will affect internal users, operational planning, and external issues such as partner agreements or contract-worker access. Because the e-mail service is only one component of many, each of these other choices will, in turn, affect many other elements of the extended technology enterprise.

Unless the architect is fully cognizant of all such issues, including both business requirements as well as the technologies involved, a mis-step may limit options later or even require a total overhaul of the system down the road. A manager or information technology professional who is not skilled in enterprise architecture can easily cost a business significant opportunities, even if the selection at first seems best based solely on user requirements and cost analysis.

Where the Only Constant Is Change

In this text, we will examine the strategies that allow an enterprise to be agile enough to take advantage of new opportunities, while at the same time being stable enough to allow recovery and continuity in the face of disaster, regulatory mandate, or significant shift of business focus. Before walking that path, it is important to be forewarned: Change is often opposed. This opposition pervades the entire spectrum of information technology solutions—which may seem odd in an environment where the only constant is change.

Lilliput and Blefuscu

In Jonathan Swift’s Gulliver’s Travels, the primary character encounters the tiny inhabitants of an island called Lilliput. Lemuel Gulliver discovers that the people of Lilliput are embroiled in a bitter war with their neighbors on the island of Blefuscu. The war is being fought over a difference in the way that eggs must be eaten (Lilliput legislates that eggs must be eaten only from the smaller, pointed end, while Blefuscu claims that eggs must be eaten only from the larger, rounded end). The big-end/little-end difference separates these people so strongly that a long and bitter war has been fought over the issue.

Because both solutions allow an egg to be eaten, the choice of starting at one end or the other seems a poor cause for conflict. This is nothing compared to the passionate manner in which technologists are divided, with arguments over who “gets root” (has an administrative level of system access) or which method of log-on authentication to use escalating to heated brawls or thousands of pages of research “proving” the One True Way.

It is said of the popular dish pad Thai (Thai noodles) that there are as many recipes as there are chefs who prepare it. This is also true for technology, as every technologist will have his or her own One True Way and every enterprise will have its own set of needs and preferences. Before we begin our study of the strategies that may be used, it is important to understand that entrenched information technology professionals will have their own best option.

An architect must have the strength of vision necessary to stand firm and persuade these individuals that some choices must be made from a larger perspective in order to reap the greatest benefits for the organization overall. A few of the arguments that may be encountered include the following.

• Root. In information technology circles, position and status are often conveyed to the administrator who has ultimate access rights. By having a root administrative account, these individuals proudly proclaim that they are trusted enough or responsible enough to have this access—and they often fight fervently to get or keep this type of account and to avoid anyone else having a higher level of administrative access.
• Silos. Consolidation of information is a driving force in many efforts to reduce administrative requirements, hardware costs, licensing fees, and data exposure. This is counter to the traditional structure, in which individual business units maintained their own technologies, data, backups, and administrative controls in independent silos with total autonomy. Regulatory mandates and cost controls are driving consolidation efforts, posing a threat to the legacy of autonomy and control.
• Big iron. Traditionally, large enterprises relied on large, dedicated systems. These “big iron” mainframes still have a place in the enterprise, but they are being challenged by technologies that rely on decentralized nodes or grids of interconnected lower-capacity systems to generate the same level of operational capability. Although Beowulf-style superclusters made from off-the-shelf personal computing hardware have provided greater computi...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Dedication
• Table of Contents
• Preface
• Acknowledgments
• About the Author
• Chapter 1 The Impact of Enterprise Architecture
• Chapter 2 Enterprise Planning
• Chapter 3 Enterprise Architecture Challenges
• Chapter 4 Finding Value
• Chapter 5 Managing Identity
• Chapter 6 Sharing Information
• Chapter 7 Storing Information
• Chapter 8 Making Connections
• Chapter 9 Anytime/Anywhere Computing
• Chapter 10 Virtualization
• Chapter 11 Enterprise Sustenance
• Chapter 12 Enterprise Security
• Chapter 13 Recovering from Disaster
• Chapter 14 Future Computing
• Index