IT Architecture For Dummies E-Book

Kalani Kirk Hausman

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 452

Veröffentlichungsjahr: 2010

Beschreibung

A solid introduction to the practices, plans, and skills required for developing a smart system architecture Information architecture combines IT skills with business skills in order to align the IT structure of an organization with the mission, goals, and objectives of its business. This friendly introduction to IT architecture walks you through the myriad issues and complex decisions that many organizations face when setting up IT systems to work in sync with business procedures. Veteran IT professional and author Kirk Hausman explains the business value behind IT architecture and provides you with an action plan for implementing IT architecture procedures in an organization. You'll explore the many challenges that organizations face as they attempt to use technology to enhance their business's productivity so that you can gain a solid understanding of the elements that are required to plan and create an architecture that meets specific business goals. * Defines IT architecture as a blend of IT skills and business skills that focuses on business optimization, business architecture, performance management, and organizational structure * Uncovers and examines every topic within IT architecture including network, system, data, services, application, and more * Addresses the challenges that organizations face when attempting to use information technology to enable profitability and business continuity While companies look to technology more than ever to enhance productivity, you should look to IT Architecture For Dummies for guidance in this field.

Leseprobe

IT Architecture For Dummies®

Table of Contents

Introduction

About This Book

Conventions Used in This Book

What You’re Not to Read

Foolish Assumptions

How This Book Is Organized

Part I: Developing the Architecture

Part II: Defining the Role of IT Architecture

Part III: Creating an Enterprise Culture

Part IV: Developing an Extended Network Enterprise

Part V: Obtaining Value beyond the Basic Enterprise

Part VI: Protecting the Enterprise

Part VII: The Part of Tens

Icons Used in This Book

Where to Go from Here

Part I: Developing the Architecture

Chapter 1: Planning for Enterprise Realignment

Defining an Enterprise

Finding the Best Solution

Providing Leadership

In the Traditional Enterprise, Everything May Be Independent

Too many resource silos

Too many platforms

Too many people with root access

In the Modern Enterprise, Everything Is Connected

Defining Success

Using Maturity Models

Preventing Failure

Chapter 2: Exploring Tasks, Roles, and Tools

Examining Common Enterprise Architecture Tasks

Identifying data requirements

Integrating existing resources

Defining technical standards

Justifying changes

Communicating effectively

Knowing the Roles of Enterprise Architecture

Chief architect

Lead architect

Technology architect

Software or application architect

Business architect

Data architect

Using the Right Tool for the Right Job

IT governance

Enterprise architecture frameworks

Project management

Chapter 3: Pondering Platform Pros and Cons

Standardizing Your Platform — or Not

Recognizing the benefits of standardization

Overcoming challenges in standardization

Making the Hard Software Choice: Open Source or Closed Source

Open source

Closed source

Working with Open Standards

Looking Past Specifications to Business Needs

Part II: Defining the Role of IT Architecture

Chapter 4: Reducing Complexity through Standardization and Consolidation

Recognizing Complexity in the Enterprise

Common sources of complexity

Complications of complexity

Planning for Consolidation

Applying the 80/20 rule

Finding value

Planning for technology end of life

Maintaining the help desk

Consolidating skills

Addressing Concerns about Standardization

Reduced functionality

Decreased productivity

Incompatibility with existing applications

Risk of technology monoculture

Preparing for opposition

Consolidating the Data Center

Identifying the benefits

Reducing complexity through virtualization

Implementing desirable redundancy

Planning the centralized facility

Automating the Data Center

Patches and updates

Image-based deployment

Backup solutions

Chapter 5: Planning Enterprise Information Security

Protecting Enterprise Data

Creating a Security Plan

Design a workable program

Use a layered framework

Implement security standards

View security as a program, not as a project

Keep security simple

Developing a Security Policy

Classifying data to be secured

Addressing basic security elements

Getting management approval

Maintaining the policy

Training employees

Using Technology to Support Security Operations

Use collaborative technologies

Remain flexible

Plan for partner relationships

Outsource only when necessary

Chapter 6: Complying with Mandates and Managing Risk

Keeping Your Company Compliant

Legal mandates that affect the organization

Discovery and retention

Additional requirements

Planning to Manage Risk

Identifying threats

Identifying vulnerabilities

Assessing risk

Addressing Risk

Prioritizing threats

Reducing probability

Reducing impact

Choosing appropriate mitigations

Part III: Creating an Enterprise Culture

Chapter 7: Developing Identity and Access Management Strategies

Introducing Identity and Access Management (IAM)

Identifying Users

Something users know: Password

Something users have: Access token

Something users are: Biometric identification

Something users do: Behavioral identification

Authenticating Users

Authentication standards

Directory

Central authentication

Federated authentication

Single sign-on

Cross-realm authentication

Authorizing Access

File and database rights

Service rights

Application rights

Creating an Identity Management Strategy

Reviewing technologies

Assigning aggregate rights

Meeting legal requirements

Keeping it simple

Finding benefits

Implementing an Identity Management Solution

Identification

Authentication

Authorization

Additional functions

Chapter 8: Developing a Network Culture through Collaboration Solutions

Establishing Networks of Trust

Creating a team from a mob

Developing strong lines of communication

Calculating the value of networks with Metcalfe’s Law

Developing Network Culture through Social Media

Using social networking

Employing collective intelligence

Setting social-media policies

Employing Groupware

Considering the benefits of groupware

Selecting a groupware solution

Working with Enterprise Portals

Activating common features of portals

Developing network culture with portals

Integrating business intelligence tools

Chapter 9: Reviewing Communication Methods

Identifying Classes of Communication

Messaging

Chat

Electronic mail (e-mail)

Instant messaging

Text messaging

Community Sites

Blogs

Discussion boards and forums

Wikis

Conferencing

Videoconferencing

Virtual reality

Voice over Internet protocol (VoIP)

Web conferencing

Broadcast Communications

Podcasting

Really Simple Syndication (RSS)

Streaming media

Part IV: Developing an Extended Network Enterprise

Chapter 10: Managing Data Storage

Determining Storage Requirements

Conducting a storage survey

Interviewing personnel

Identifying Important Data Categories

File repositories

File versioning

Databases

Multimedia

E-mail

Logging

Virtual servers

Creating a Storage Policy

Addressing specific storage topics

Distributing the policy

Designing a Storage System

Selecting appropriate storage configurations

Exploring enterprise-level storage strategies

Dealing with expanding storage needs

Protecting Stored Data

Fault tolerance

Backup and recovery

Data removal

Chapter 11: Managing Application Development

Exploring the Software Development Life Cycle

Waterfall

Prototype

Spiral

Rapid Application Development Strategies

Agile programming

Extreme programming

Scrum programming

Designing Application Architecture

Multitiered architecture

Service-oriented architecture

Including Accessibility

Chapter 12: Planning for the Mobile Enterprise

Introducing Mobile Computing

Laptops

Netbooks

Tablets

Cell phones

Bluetooth

Long-range wireless

Exploring Mobile Computing in the Enterprise

Device interaction

Boosters and dead zones

Going Mobile beyond the Enterprise

Navigation

Connectivity and bandwidth

VPN and SSL access

Remote desktops

Power

Planning for SmartPhone Computing

Familiarity

Planning ahead

Device locking

On-device encryption

Kill pills

Laptop LoJack

Defining Mobile Access Policy

Mobile computing policies

Remote access policies

Wireless use policies

Part V: Obtaining Value beyond the Basic Enterprise

Chapter 13: Virtualizing Enterprise Systems

Getting the Scoop on Virtualization Technology

Virtualizing Servers

Hosting virtual machines

Separating hardware and software tech refresh planning

Emerging best practices

Virtualizing Workstations

Using thin and thick clients

Virtual desktops

Remote desktops

Client hosting

Virtualizing Applications

Cloud Computing

Private clouds

Best practices

Chapter 14: Facilitating High-Performance Computing

Supercomputers Rule the World

Desktop computing

Parallel computing

Distributed computing

Everyday High-Performance Computing

Computing clusters

Visualization clusters

Grid computing

Volunteer computing

Compute farms

Desktop High-Performance Computing

Chapter 15: Enabling Green IT

Practicing Green Technology

Extended replacement cycles

Telework and telecommuting

Data center location

Energy tax credits

ENERGY STAR

Considering Alternative Energy

Reducing Consumables

Selecting Green Hardware

Configuring Green Settings

Virtualizing Hardware

Ensuring Green Disposal

Part VI: Protecting the Enterprise

Chapter 16: Planning Technology Updates

Reviewing Hardware Update Strategies

Keeping systems until they fail

Using defined replacement cycles

Riding the cutting edge

Employing trickle-down replacement

Relying on surplus technology

Using technology as a reward

Replacing technology in an ad-hoc manner

Planning for Sub-System Updates

Upgrading components

Updating firmware

Updating device drivers

Planning Software Updates

Understanding the need for testing

Exploring deployment strategies

Planning for software maintenance

Chapter 17: Planning Security Strategies

Identifying Threats to the Enterprise

Malware

Application vulnerabilities

Directed network attacks

Selecting Appropriate Countermeasures

Malware protection

Secure application development

Data loss prevention

Encryption

Firewalls

Intrusion detection and prevention

Network address translation

Network monitoring

Chapter 18: Planning Business Continuity and Disaster Recovery

Defining Business Continuity and Disaster Recovery

Keeping Your Business in Business: Continuity Planning

Participating in a business impact analysis

Participating in risk assessment

Preparing a Recovery Plan

Developing scenarios

Incorporating virtualization strategies

Testing the plan

Updating the plan

Using Alternative Sites

Selecting the right type of site

Managing the alternative site

Communicating During a Disaster

Part VII: The Part of Tens

Chapter 19: Ten Challenges for Redesigning an Existing Enterprise

Dealing with Lack of Executive Support

Handling Opposition to Change

Deciding on a Platform: Open Source versus Closed Source/Commercial Off-the-Shelf

Eliminating Resource Silos

Integrating Legacy Systems

When Change Doesn’t Happen Fast Enough

Maintaining Compliance throughout the Process

Dealing with Separate Revenue Streams

Supporting Personally Owned Equipment

Know Your Limits

Chapter 20: Ten “Low-Hanging Fruit” Opportunities

Eliminate Resource Silos

Standardize the Workstation Environment

Create a Centralized Data Center

Consolidate Resources Already Within the Data Center

Implement Automated Update/Patch Management Solutions

Implement Enterprise-Level Anti-Malware Solutions

Use Risk Assessment Results to Find Easily Fixed Vulnerabilities

Schedule Workstation Replacement

Implement Virtualization

Reduce Cost from Consumables by Implementing Green IT Practices

IT Architecture For Dummies®

by Kalani Kirk Hausman and Susan L. Cook

IT Architecture For Dummies®

Published byWiley Publishing, Inc.111 River StreetHoboken, NJ 07030-5774

www.wiley.com

Copyright © 2011 by Wiley Publishing, Inc., Indianapolis, Indiana

Published by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, [phone], fax [phone]. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax [phone], or online at http://www.wiley.com/go/permissions.

Trademarks: Wiley, the Wiley Publishing logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies Daily, The Fun and Easy Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.

Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read.

For general information on our other products and services, please contact our Customer Care Department within the U.S. at 877-762-2974, outside the U.S. at 317-572-3993, or fax [phone].

For technical support, please visit www.wiley.com/techsupport.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Library of Congress Control Number: 2010937819

ISBN: 978-0-470-55423-4

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

About the Authors

Kalani Kirk Hausman is employed as an Assistant Commandant at Texas A&M University and specializes in enterprise architecture, security, information assurance, business continuity, and regulatory compliance. His background includes varied topics from digital forensics and WMD response, pandemic response planning, technology audit practices, and IT governance strategies. His experience includes application design, data resource management, network architecture, server and storage virtualization, strategic technology modernization, network and backup centralization, research computing, and large network BCP/DR planning. With a Master’s degree in Information Technology, Kirk has served as a senior research scientist in the fields of cyber terrorism, cybercrime, and cyber security, and he regularly lectures on uses of technology in education, solutions for persons with disabling conditions, and strategic architectural planning to improve enterprise efficiencies. Kirk’s professional certifications include the CISSP, CGEIT, CRISC, CISA, CISM, and CCP together with a wide assortment of technology- and regulatory-specific designations.

Susan L. Cook is a Senior IT Policy and Security Programs Administrator at Texas A&M University, specializing in enterprise risk assessment and compliance. She has a master’s degree in Information Technology, additional graduate work in Security Management, and more than a decade of experience in the field. She has also worked as a compliance auditor in the financial industry and as a licensed private investigator.

Dedication

This book is dedicated to the many talented IT professionals faced with supporting enterprises in which the only constant is change.

Authors’ Acknowledgments

We would like to acknowledge the tremendous help in preparing this book provided by the excellent editorial staff at Wiley, in particular our Project Editor, Blair Pottenger; Development Editors, Kelly Ewing, Jodi Jensen, and Kathy Simpson; Copy Editors, Teresa Artman and Maryann Steinhart; and Tech Editor, Chris Leiter. Special thanks are also due to Katie Mohr, our Acquisitions Editor for the Dummies series, and to our agent and all-around-guide, Carole Jelen of Waterside Productions.

Publisher’s Acknowledgments

We’re proud of this book; please send us your comments at http://dummies.custhelp.com. For other comments, please contact our Customer Care Department within the U.S. at 877-762-2974, outside the U.S. at 317-572-3993, or fax [phone].

Some of the people who helped bring this book to market include the following:

Acquisitions and Editorial

Project Editor: Blair J. Pottenger

Development Editors: Kelly Ewing, Jodi Jensen, Kathy Simpson

Acquisitions Editor: Katie Mohr

Copy Editors: Teresa Artman, Maryann Steinhart

Technical Editor: Chris Leiter

Editorial Manager: Kevin Kirschner

Editorial Assistant: Amanda Graham

Sr. Editorial Assistant: Cherie Case

Cartoons: Rich Tennant (www.the5thwave.com)

Composition Services

Senior Project Coordinator: Kristie Rees

Layout and Graphics: Carl Byers, Erin Zeltner

Proofreaders: Tricia Liebig, Lindsay Littrell

Indexer: BIM Indexing & Proofreading Services

Publishing and Editorial for Technology Dummies

Richard Swadley, Vice President and Executive Group Publisher

Andy Cummings, Vice President and Publisher

Mary Bednarek, Executive Acquisitions Director

Mary C. Corder, Editorial Director

Publishing for Consumer Dummies

Diane Graves Steele, Vice President and Publisher

Composition Services

Debbie Stailey, Director of Composition Services

Introduction

The enterprise begins when you carefully put the first two computers together, and complexity grows with every step thereafter. Haphazard IT building practices can easily lead to an enterprise network that is poorly planned or composed of random, one-off projects undertaken as standalone goals. An e-mail consolidation project can unexpectedly derail concurrent licensing projects intended to vastly reduce expensive software licensing costs by carving the authentication domain into separate silos unable to share resources. A server virtualization project may run into difficulties if not coordinated properly with server consolidation projects to make sure that sufficient bandwidth and host resources are available when systems are transferred from physical to virtual states.

Obviously, these scenarios are simply examples of potential conflicts that may occur when enterprise realignment and cost-saving strategies drive independent projects without coordination and guidance at the strategic level. Many other conflicts are much more subtle and not apparent until well along a new path, such as an incompatibility between communications protocols that support new equipment or a lack of executive support that leaves adoption of enterprise practices in a loose “opt in by choice” state.

After reading this book, you’ll have a better grasp of the interconnected nature of enterprise architecture realignment. We hope the information we provide encourages you to look around your own enterprise and find some low-hanging fruit opportunities for quick savings or other proof of value to help develop executive support for additional changes. Few enterprises lack such opportunities because technology and its uses tend to fall into stable practices users describe as “the way we’ve always done it” rather than changing to adopt the best or most efficient ways.

About This Book

This book is not a checklist for efficiency, although it does present some strategies that may improve cost and operational efficiencies. It is not a step-by-step guide that will lead to a secure and risk-free network, although it provides some examples of projects that may help to reduce risk. Instead, this book introduces you to enterprise architectural planning from the theoretical viewpoint and then drills down to the meat and bones of enterprise technologies and functions.

You should recognize elements of your own environment reflected here and take advantage of my past experience in dealing with challenges faced during realignment, consolidation, and other re-engineering practices within an extended enterprise network. Although the content of this book is suitable for globally distributed enterprises of significant scale, the topics covered are useful for resource and availability planning in networks of any size.

Conventions Used in This Book

This book is, after all, a reference book, and we expect that using conventions will make it easier for you to find exactly what you’re looking for by quickly scanning through chapters. The conventions for this book are as follows:

Italics emphasize important terms the first time they’re defined.

Web site addresses, or Uniform Resource Locators (URLs), are provided for Web sites referenced in this book and appear in a special typeface, such as www.dummies.com.

Because the Web is such a dynamic environment, provided URLs may change at any time.

What You’re Not to Read

In order to make a technical topic more interesting, we include interesting tidbits of information and anecdotes based on our professional experiences. You can find this information in sidebars throughout the book. You don’t have to read the sidebars to understand IT architecture, but if you do, we hope you find them as interesting as we do.

Occasionally, we’re guilty of outright techno-babble, but fortunately we mark those discussions with Technical Stuff icons so that you can skip right over them if that sort of thing makes your eyes glaze over.

Foolish Assumptions

We assume this book is going to be read by CIOs, chief architects, network planners, IT operation managers, and front-line technical implementers. We don’t delve deeply into specific technologies, but instead present considerations for integration of whatever technologies are already in place.

We also assume that you’re not looking for someone to tell you exactly what hardware and software to buy. We won’t tell you that open-source is the best solution for every problem, any more than we’ll suggest that a particular vendor’s commercial off-the-shelf line of products is best. In general, the best choices for technology are based on those already in place and familiar to users and support staff alike.

Finally, we assume that you need help identifying areas of focus and strategies for sustaining your enterprise year to year in the face of constant technological evolution. We trust this will spark many ideas you can leverage toward management of your extended enterprise. By starting at the theoretical level and progressing through the book into ever-more-direct technology approaches and strategies, you can develop a better framework for evaluation of your own enterprise setting.

How This Book Is Organized

We divide this book into several parts based on topic. The following sections describe what you can expect to find in each part.

Part I: Developing the Architecture

Part I establishes the fundamental concepts of what defines an enterprise and then examines the value provided by this definition.

Part II: Defining the Role of IT Architecture

Part II addresses the identification of challenges and advantages in enterprise reconfiguration. It further examines the need to prove value to the organization as a result of change.

Part III: Creating an Enterprise Culture

Part III discusses the fundamental aspects of identity management, developing an enterprise culture, and specific collaborative options that can be used to reinforce this cultural evolution.

Part IV: Developing an Extended Network Enterprise

Part IV covers elements of a distributed network and its resources, identifying areas of planning that must play a part in enterprise reorganization and long-term operational strategies.

Part V: Obtaining Value beyond the Basic Enterprise

Part V examines technical considerations and projects that may or may not apply to some enterprises, although many of the strategies listed can be applied at any level.

Part VI: Protecting the Enterprise

Part VI defines strategies for protecting resources and services within the enterprise network environment.

Part VII: The Part of Tens

Part VII offers lists of ten useful items in enterprise architectural planning, together with references to areas of the book focusing on each.

Icons Used in This Book

The familiar For Dummies icons offer visual clues about the material contained within this book. Look for the following icons throughout the chapters:

Whenever you see a Tip icon, take note and pay particular attention. Tips address special-case items or strategies that come up often.

The Remember icon points out key concepts that will be helpful in understanding later topics in this book. And here’s your first thing to remember: There is an online cheat sheet for this book that you can find at www.dummies.com.

Warning icons draw your attention to potential pitfalls and particularly difficult challenges. Pay attention to these factors in your enterprise because they have a habit of coming back to bite you.

Although this book attempts to avoid advocating specific technologies or alternatives in favor of a more generally useful examination of architectural strategies appropriate to any enterprise, technical details are indicated with a Technical Stuff icon. These items may prove of greater use to implementers than to pure strategists, but you will likely wear many hats over the course of enterprise realignment. It can’t hurt to review a few technical details!

Where to Go from Here

The goal of this book is to get you thinking about your own enterprise and the opportunities it presents to the users, partners, and clients who access its resources. You don’t have to read this book cover-to-cover, although you can, if you want. Either way, we hope that you walk away with dozens of ideas for improvements in your own setting, whether your server room is a converted broom closet or you support hundreds of thousands of users scattered around the globe.

Please note that some special symbols used in this eBook may not display properly on all eReader devices. If you have trouble determining any symbol, please call Wiley Product Technical Support at 800-762-2974. Outside of the United States, please call 317-572-3993. You can also contact Wiley Product Technical Support at www.wiley.com/techsupport.

Part I

Developing the Architecture

In this part . . .

This part offers a high-level overview of enterprise architecture. If you’re not intimately acquainted with the topic of enterprise architecture, you may find this part particularly helpful. In addition to covering basic concepts, we include guidelines for determining success and preventing failure, establishing proper IT governance and management practices, and using enterprise architecture frameworks.

Chapter 1

Planning for Enterprise Realignment

In This Chapter

Defining the enterprise

Defining success

Preventing failure

Information technology (IT) is everywhere in the business world, and you’d be hard pressed to find a business larger than a sole proprietorship that does not utilize some type of IT. When an IT decision is made, its effect can be felt throughout the organization. Poor decisions, such as those made without consideration of the impact on other elements of the enterprise, can create both immediate and long-term problems.

In this book you focus on enterprise architecture strategies and mechanisms that support both immediate and long-term (three to five years) planning. These strategies are used successfully in all types of enterprises, including small to mid-sized offices, educational institutions, and global commercial enterprises.

Defining an Enterprise

The enterprise is a fluid term encompassing all technologies and tech-related policies that relate to services provided to clients, partners, and customers during operation of the organization. The more the enterprise interconnects elements, the more it becomes like a living organism — growing to meet emerging opportunities; consuming resources for sustenance; and generating piles of outdated, outmoded, or outright broken equipment that must be disposed of carefully. The enterprise requires planning to control its growth into useful areas, guidance to maintain its security and integrity during operation, and leadership to face the myriad personal preferences users will bring to their expectations of service value and function.

The strategies you explore in this book enable the enterprise to be stable but agile, which allows for both continuity of operations and the integration of new technologies.

Finding the Best Solution

There’s no perfect solution, no one-size-fits all strategy for enterprise architecture. As long as the technology meets the requirements, performs efficiently, supports business processes, is cost-effective, and can be supported and maintained, it’s an acceptable solution, perhaps even a good one. There is no “best” technology, only the best technology for your enterprise.

Technology supports business, not the other way around. Technology should support business processes and align with strategic goals of your organization. Your technology choice should not limit your organization’s functionality or future goals.

The strategies you look at in later chapters will help you make the right decisions for your organization, minimize cost, foster long-term planning capabilities, and create a stable and agile enterprise.

Providing Leadership

To be an effective enterprise architect, you must provide leadership for the decision-making process; understand the impact generated by each technology selection; and facilitate communication of strategies, policies, and controls to implementation staff and clients.

An enterprise architect must possess both business alignment and broad technological skills in order to filter through user requirements and separate user preferences (“wants”) from requirements (“needs,”) while also seeing past the technobabble jargon that tech savvy clients and IT staff members often use when dealing with normal mortals.

As an architect, you must identify future technology trends, up-and-coming opportunities, and evolving security requirements to ensure that the current-state enterprise is properly prepared to meet emerging solutions and technologies. If not planned carefully and tested thoroughly, integrating new items like the immensely popular Apple iPad can be catastrophic on enterprise networks.

You must have the strength of vision necessary to stand firm and persuade concerned individuals and key stakeholders that some choices have got to be made from a larger perspective in order to reap the greatest benefits for the organization overall. You must be able to speak comfortably with chief officers and end-users, but also have sufficient technical credentials and understanding to be taken seriously by front-line technical staff members.

The worst thing you can do is present strategies to technical implementers and display a lack of real-world implementation experience, without sufficient updated and personal technical ability to be taken seriously. When lost, respect and support from the IT geeks may be impossible to recover, and the best possible strategies ignored or circumvented as a result. To perform effectively, you are obliged to continually extend your own IT skills through study and training. A purely nontechnical managerial staff member should never attempt to dictate technical policies or strategies because they lack understanding of the complex web of interconnection that forms the modern enterprise network.

The technical lead who fails to keep his skills current rapidly becomes a nontechnical lead due to the rapid evolution of both technologies in use and the manner in which they’re consumed by clients and knowledge workers. As an example, consider an IT architect whose skills were developed prior to the evolution of service-oriented architectural design, cloud computing, virtualization of storage and hardware, VDI implementation, Green IT initiatives, privacy and encryption regulatory mandates, and a myriad of other emergent options. This architect won’t be able to effectively recognize the potential value these technologies can add to the organization’s operations — or understand the limitations, cost, and impact of integrating them into the existing enterprise.

We discuss many of the IT leadership roles that may be present in an enterprise architectural project, together with a review of common IT governance and architectural frameworks, in Chapter 2.

In the Traditional Enterprise, Everything May Be Independent

Many organizations still have traditional networks that are structured the same way they were 10 or 20 years ago — often due to a lack of technical knowledge update within the senior technical staff members, leading to a simple repetition of the same outdated functionality simply on updated hardware. Even if your organization isn’t that old, chances are that unless modern enterprise architecture principles were involved in its initial design, you will still run into some of these old-school issues:

Too many resource silos

Too many platforms

Too many people with root access

Too many resource silos

In a traditional enterprise, it isn’t unusual for each business unit to maintain control over its own information systems, including servers, workstations, data, and even networking hardware. Along with information systems, each unit also has its own technical personnel, makes its own purchases, and is responsible for backing up its own data. In essence, each business unit is its own autonomous network. This autonomy creates difficulties when anyone tries to access resources in another silo or share data between business units. It also leads to excessive duplication of resources and efforts, as each unit may have its own database server, file server, or e-mail server. As an example, I (Kirk) have seen multiple million-dollar-plus document imaging systems implemented by different business units using incompatible technologies, only because there was no enterprise-level coordination of an IT project portfolio. As enterprise architect, one of your tasks will be to consolidate these resource silos into a single, centralized data center.

Because local silos of information resources create inefficiencies and barriers to architectural design, we address the elimination of silos in many chapters throughout the book. Deal with this pervasive problem early in enterprise planning.

Too many platforms

In information technology, a platform refers to a hardware or software framework. Examples of platforms include operating systems, hardware, programming environments, database management systems, and desktop or server configurations. In the old-school enterprise, you may find that many different platforms are in use. Administrators all have favorite technologies, and without a directive for standardization, administrators will push management to purchase these favored technologies. You may have to deal with a wide variety of operating systems, both server and workstation; multiple database solutions; or each programming team using a different programming language.

Another task will be to standardize platforms, which requires your vision and understanding of the organization’s business requirements in order to keep the realignment process going even through the conflicts that will surely arise.

Chapter 3 includes an examination of technology standardization and its attendant benefits. Standardization is also key to adoption of new technologies enterprise-wide and to disaster recovery procedures, where complexity and customization can extend the recovery window significantly.

Too many people with root access

Often, too many administrators have high levels of administrative access. This type of access is referred to as root, superuser, enterprise admin, supervisor, or admin, depending on the operating system or application in use. These accounts may even be used as the administrator’s normal logon account, in defiance of security best practices. Unfortunately, root accounts are sometimes considered a status symbol and an indicator of the organization’s trust. You may even find that nontechnical staff possesses this access. Managers may insist on root access simply because they’re managers or because they want to keep an eye on their administrators, even though they don’t have the skills or knowledge to actually do so. Yet another of your tasks will be to remove root access from people who don’t truly need it.

In the Modern Enterprise, Everything Is Connected

You can’t decide on one particular technology without considering how it will affect all other technologies used in your enterprise now and in the future. For example, the selection of a new e-mail platform may seem simple, but it affects more than just how users get their e-mail. It also concerns the following:

Directory services and authentication

Network fax or voice mail solutions

Instant messaging solutions

Existing and future e-mail integrated applications

Backup and recovery

Data storage

Security solutions

Selecting a particular application or programming language can affect your enterprise’s future agility and impact business operational procedures. You have to base your technology selection on more than just user requirements and cost analysis; it must align with your organization’s strategic business plan. Unless you have full understanding of both technical and business requirements, you risk limiting your organization’s options. This understanding is necessary for success.

We discuss common collaborative technologies in Chapter 8. However, these technologies are not alone. A central set of standards should drive selection of platforms, standards for interoperability and communication, identify and access management, and all other functions within the enterprise to ensure that you can effectively integrate all existing functionality as well as newly emergent options into the enterprise fabric.

Defining Success

To be successful, enterprise architecture must provide value to the organization. Change for the sake of change alone is counterproductive.

Although some criteria for success may be specific to your organization, enterprise architecture may generally be considered successful if it does the following:

Reduces support and operational costs

Defines technical standards

Reduces risk

Improves continuity of operations

Reduces undesirable redundancy while retaining fault tolerance

Facilitates business processes

Allows for a clear upgrade path to future technologies

These indicators are all fairly straightforward, but another sign of successful enterprise architecture is that the organization sees it as valuable. Because enterprise architecture can have a significant effect on your organization’s current and future capabilities and opportunities, your organization needs to be aware of the value provided by the architecture so that costs remain justifiable in the overall business plan.

Using Maturity Models

Maturity models measure how your organization is progressing through an improvement process, and they’re used extensively in process improvement, project management, and software development. The models consist of a number of levels, and as your organization matures and improves, it moves up in level. For example, the lowest level of maturity may be None, but when your organization begins to establish processes, even informally, it rises to the next level, which may be Informal or Initial. This process continues until the final level is reached, which is usually Continuously Improving, Audited, Measured, or something similar to indicate that the process is reviewed. Carnegie Mellon’s Capability Maturity Model Integration (CMMI) is an example of such a model.

You can also use maturity models for enterprise architecture. Following are some of the more well-recognized enterprise architecture maturity models:

Carnegie Mellon - Capability Maturity Model Integration (CMMI) (www.sei.cmu.edu/cmmi)

National Association of State Chief Information Officers (NASCIO) - Enterprise Architecture Maturity Model v1.3 (www.nascio.org/publications/documents/NASCIO-EAMM.pdf)

United States Department of Commerce - Enterprise Architecture Capability Maturity Model (ACMM) v1.2 (ocio.os.doc.gov/ITPolicyandPrograms/Enterprise_Architecture/PROD01_004935)

United States General Accounting Office - Enterprise Architecture Maturity Management Framework (EAMMF) v1.1 (www.gao.gov/new.items/d03584g.pdf)

Maturity models are undoubtedly useful, but you may find that no published maturity models are a perfect fit for your organization. If that’s the case, tailor the maturity model to your organization.

Preventing Failure

Unfortunately, not every enterprise architecture project is successful, but how do you know if you’re on the path to failure? Some of the indicators to watch for include

Allotting too much time to respond to problems and too little to planning and actually architecting. If you’re constantly putting out fires, you can’t make progress.

Poor leadership skills. To be an effective enterprise architect, you must be a leader. It isn’t enough to have the technical knowledge; you must be able to take charge when necessary, foster open communication, and think strategically.

Neglecting to include business staff. Remember that information technology supports business processes, and you must include business staff in enterprise architecture decisions in order to ensure that technology is aligned with business goals.

Lack of executive support. For any enterprise architecture project to succeed, it must have the support of executive staff. Executives have got to understand the value of enterprise architecture so that they can provide proper support. When your executives back the project, corporate culture dictates that the changes to come are not optional.

If you notice any of these problems, it may be time to take a step back and re-evaluate your methods.

Chapter 2

Exploring Tasks, Roles, and Tools

In This Chapter

Discovering common tasks

Identifying enterprise architecture roles

Investigating enterprise architecture frameworks

In transforming the theoretical concept of the enterprise into concrete components, the enterprise architect brings together a wide assortment of business guidelines, rules, and framework elements. You may work alone or as the head of a team, depending on the enterprise’s size and complexity.

In this chapter, I identify common enterprise architecture tasks and the operational roles responsible for them. I also explain the rich set of tools for the enterprise architect: information technology governance, enterprise architecture frameworks, and project management techniques.

Examining Common Enterprise Architecture Tasks

As an enterprise architect, you perform many tasks when you design and implement an enterprise architecture plan, and those tasks vary widely in scope and focus. For example, finding ways to align technology and business needs is a high-level strategic task, whereas determining which anti-malware product to use is more of a focused operational task. The exact tasks depend on the organization and the scope of the plan, but the following sections list some general tasks that the architect should do.

As you read through the following sections, make notes regarding the relevancy of each task to your business environment. That’ll help you identify what you need to do when you implement your own enterprise architecture plan.

Identifying data requirements

An organization’s business processes are built around its data, and changes to the way data is handled (for example, how it’s input, stored, moved, archived, and eliminated) can improve (or harm) those processes. To ensure that changes result in improvement, you must incorporate the organization’s data requirements into the plan. Start by identifying the following three items:

Classifications of data used by the organization. This determines the appropriate security measures.

Location of the data, such as on desktop computers, on servers, or in databases. This identifies redundancy.

Users of the data, including employees, customers, partners, or the general public. This aids in defining security controls and mechanisms for availability and access management.

Integrating existing resources

Technology resources, including everything from servers to applications and the people who manage them, are used to support business processes. You must identify the resources currently in use in order to see whether they’re being used effectively and whether they’ll be integrated into the new architectures. Even resources that are not the “best” choice may need to be integrated into the new architecture for legal, regulatory, or contractual reasons, or because they’re impractical to replace in a short time frame.

You also have to identify embedded systems, such as security systems, telecommunications systems, network infrastructure components, and highly specialized systems like medical or manufacturing equipment that you may integrate into your new architecture. These systems have special security needs that are often overlooked, such as hard-coded device authentication mechanisms or fixed communications protocols used for device-to-device coordination of large SCADA environments.

Defining technical standards

It’s the enterprise architect’s responsibility to define the organization’s technical standards, which are the rules and guidelines that the organization uses when making decisions regarding information technology and related acquisitions, procedures, configuration specifications, and policy.

Here are some examples of technical standards:

Workstation and server configurations, including fair use and storage limitation policies.

Approved software, from operating systems to business productivity suites, including malware defense policies.

Network hardware components, such as routers and switches, together with remote access and mobile access policies.

Application development methodologies, including policies for documentation and code review.

Networking and communication protocols, in addition to VPN and RADIUS policies.

These standards are also used when your organization creates or modifies information security and computer-use policies.

Justifying changes

Enterprise architects make changes that have the potential to affect every employee in an organization. So you must ensure that changes aren’t made simply for the sake of making changes. Changes have to provide value to the organization in some fashion, such as direct cost savings, reduction in administrative overhead, or improvements to business processes. (Chapter 4 shows you how to find value in architecture, particularly standardization and consolidation initiatives.)

Communicating effectively

Designing and implementing an enterprise architecture plan involves so many tasks that you may need more than one architect to complete them. Communication is essential to all phases of enterprise architecture planning. You must explain the benefits of the plan to the stakeholders (interested and/or affected parties) in both technical and nontechnical terms. In addition, the enterprise architect has to develop plans that define how changes will be communicated to the users, how directions will be communicated to the implementers, and how feedback will be gathered from everyone.

Knowing the Roles of Enterprise Architecture

The larger the enterprise, the more difficult it can be for a single person to manage all the tasks that must be performed when structuring an IT architecture. It isn’t uncommon for multiple architects, each with a particular area of expertise, to work together under a chief architect. The following sections identify some of the types of architects that are commonly found in medium to large organizations.

Chief architect

The chief architect identifies opportunities for improvement in technology and ensures that technology aligns with business requirements. Depending on the structure of the organization, a likely candidate for the chief architect is the CIO (Chief Information Officer). The CIO should have the background to move effortlessly between business and technology and be able to communicate equally well with executives and technical staff while aligning technology selections with business requirements.

In addition to the general tasks discussed in the “Exploring Common Enterprise Architecture Tasks” section, earlier in this chapter, the chief architect is responsible for the following specific tasks:

Identifying and analyzing risk factors, such as the potential of exposing protected data or creating security vulnerabilities during transition from one solution to another

Acting as the final arbitrator in solution negotiation for conflicts that arise from changes

Providing leadership

Essentially, the chief architect is the individual ultimately responsible for planning, directing, and monitoring the process of enterprise architecture and its associated business processes and technologies.

Significant problems can arise in the project if the chief architect’s technological knowledge is lacking or is out of date. Lack of personal technical skills may cause the architect to make uninformed decisions or rely too heavily on advice from others who may have their own personal agendas. Similarly, a lack of soft skills may impair effectively aligning technologies with business needs or prevent conveying the value of technical changes to nontechnical stakeholders.

Several operational roles support the chief architect. They require specialized knowledge and skills that the chief architect may not possess or have time to use.

Lead architect

Typically found only in larger enterprises, a lead architect provides assistance and support to the chief architect. Acting as the chief architect’s executive officer, the lead architect may attend meetings and resolve issues in the chief architect’s place, which requires close communication with the chief architect.

The lead architect’s other duties may include

Leading implementation teams

Establishing operational standards

Coordinating change management

Technology architect

A technology architect is useful when the enterprise involves multiple technology solutions, and members of this role must have extensive knowledge of the enterprise’s infrastructure and technology requirements. Technology solutions must meet the organization’s operational requirements. As a result, the technology architect is concerned with elements such as the following:

Network components, including routers, switches, and firewalls

Enterprise software solutions, including e-mail, messaging, and content management

Computing platforms and operating systems

Integration of dissimilar technological components into a single functioning architecture, such as servers with different operating systems or a mixture of open source and commercial enterprise applications (see Chapter 3)

Software or application architect

A software or application architect is responsible for higher-level aspects of application design and development, ensuring that they’re aligned with the chief architect’s plans and the organization’s business processes. The duties of the application architect include, but aren’t limited to, the following:

Determining the software development process to use

Creating application deployment strategies

Integrating applications

Providing data resource management and coordination between software development and resources managed by the data architect role

Specifying requirements for reusable components

The technology architect and the application architect must work very closely together to achieve proper integration of applications and infrastructure.

Business architect

A business architect may be necessary for organizations with complex line-of-business applications (critical applications that are crucial to the operation of the business, such as inventory control); e-commerce solutions; or executive information systems such as business intelligence software, dashboards, and decision support systems. This architect’s primary duty is to analyze business processes and strategies and determine the related technology requirements. Here are some examples:

Identifying the need for a customer relationship management (CRM) solution and determining its appropriate use

Deciding whether to extend the organization’s intranet to business partners, thereby creating an extranet

Identifying the need for a network fax solution to replace standalone fax machines

Data architect

A data architect is a highly specialized role that may be necessary in organizations that have large amounts of data, utilize business intelligence or data warehousing solutions, or receive data from multiple sources. The data architect performs data management functions such as these:

Analyzing the organization’s data requirements and designing appropriate data repositories (as in data modeling)

Creating and maintaining data dictionaries

Defining and designing the flow of data internally (between applications) and externally (to and from a customer or partner)

Planning data migrations

Providing guidance to database administrators

Outsourcing and offshoring

Your organization may find that it doesn’t have personnel with the necessary skills or knowledge to fulfill the supporting architect roles or to implement the plans. When this challenge occurs, the organization can choose to either outsource roles in which skills are lacking or train its employees to fulfill those roles.

In general, you should outsource only if there is a benefit beyond cost-saving, as the initial cost of outsourcing is often lower but the long-term costs are greater. Additional benefits to outsourcing may include the following:

Allowing your organization’s IT staff to be trained while contractors handle migration to or implementation of a particular technology

Adding legitimacy to compliance or security audits by having them conducted by an uninvolved entity

Avoiding internal bias and preference during technology testing

Saving time and cost training employees in skills that won’t be used except during the migration

Outsourcing firms may in turn outsource some of their functions, requiring all contracts involving sensitive data to have provisions restricting secondary outsourcing.

Even if benefits exist, be cautious if you’re considering outsourcing enterprise architecture functions to an offshore company (a practice called offshoring) for the following reasons:

Some laws and regulations restrict where sensitive data can be moved or stored, particularly to foreign countries. This limitation may prohibit offshoring any functions that deal with protected data.

Your organization’s internal operational mandates or contractual obligations may also place restrictions on the capability to offshore some functions.

Prosecuting legal action across geopolitical boundaries can pose a problem for businesses whose data becomes exposed in foreign countries.

The data, application, and business architects work closely together to ensure that data and application requirements are complementary and support business processes.

Using the Right Tool for the Right Job

“The right tool for the right job” is a well-known principle in construction that has spread to information technology. This adage also applies to enterprise architecture, and the right tools for that job are these:

IT governance

Enterprise architecture frameworks

Project management

These three tools are distinct elements, and you should keep them as separate as possible. While you may have some overlap in personnel, ideally the same individual or team is not in charge of all three because the skills and knowledge needed for each of these elements vary widely.

IT governance

You can’t make technology-related decisions in a vacuum; you must coordinate and communicate with other business roles. You have to skillfully and consistently manage technology so that all IT decisions align with strategic and operational business requirements. This management is referred to as information technology governance, and it helps to ensure the following:

Communication among the following organizational roles, with regard to information technology:

• Strategic (chief officers, vice presidents, directors)

• Operational (managers, team leaders, partner representatives)

• Infrastructure (technology implementers, training staff)

Technological decisions in alignment with business requirements

Mitigation of IT risks

Proper management of technological resources

IT performance measurement

IT governance has many models, each with its own strengths, weaknesses, and specific areas of focus. The following sections introduce a few of the best-known models.

Technology doesn’t determine business mandates; business mandates determine technology. IT governance helps make sure that technology and business align.

COBIT

Control Objectives for Information and related Technology (COBIT) is a highly detailed governance model developed by the Information Systems Audit and Control Association (ISACA) and managed by the IT Governance Institute (ITGI). COBIT defines control objectives (high-level requirements) for 34 processes to assist with managing and controlling information in order to support business objectives. It also provides guidance on using metrics to determine a maturity model for your organization’s IT processes.

ITIL

Developed by the Office of Government Commerce (United Kingdom), Information Technology Infrastructure Library (ITIL) is a framework of best practices covering IT services and operations management. This model requires strong management support and commitment, and it may take three to five years to implement fully. Proponents of ITIL are currently working to adapt its use for “black box” cloud computing service environments. For more information, visit www.itil-officialsite.com.

ISO/IEC 38500:2008

ISO/IEC 38500:2008 is a standard for IT governance, published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) in 2008. This high-level standard provides guidance to management on the role of the governing body and the use of information technology in your organization. It’s applicable to public, private, and not-for-profit corporations, as well as government entities, regardless of size. The ISO Web site offers more information on this standard:

www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=51639

Enterprise architecture frameworks

Formal architecture supplies guidance, verification, and structure for long-term enterprise viability. In support of this goal, formal frameworks have developed criteria that you can use to establish value from proposed changes to the enterprise. Many frameworks exist, but the following sections describe some of the more well-known ones.

Not every framework is a one-size-fits-all model. Some organizations may find it beneficial to mix and match elements from multiple frameworks to suit a specific environment.

A number of more complex frameworks, such as those in the following sections, may require training to implement effectively; your organization may want to consider bringing in a trained or certified consultant for assistance with the appropriate framework. A number of enterprise architecture certifications are available, including both framework-specific certifications (Zachman and TOGAF), which are managed by the developing organizations, and vendor-specific certifications, such as Microsoft Certified Architect and Sun Certified Enterprise Architect. In addition, some educational institutions, such as The Ohio State University and California State University, offer certification and training as part of their continuing education or engineering programs.

Zachman Framework

The Zachman Framework is a high-level model developed by the Zachman Institute. It contains no methodology or processes; instead, it focuses on views, definitions, relationships, and objects, both physical (such as equipment or facilities) and conceptual (such as a business unit or an enterprise). It asks the simple questions of who, what, how, when, where, and why as they apply to concepts such as scope, business processes, requirements, solutions development, and deployment. The Zachman Framework is an excellent starting point for mapping out architecture processes and for identifying gaps. More information on the Zachman Framework is at www.zachmaninternational.com.

TOGAF

The Open Group Architecture Framework (TOGAF) was developed by the Open Group, a platform-neutral, vendor-neutral consortium whose members include vendors, colleges and universities, and technology companies. TOGAF consists of a methodology as well as a modeling system and is compatible with other enterprise architecture frameworks. Its architecture development method begins with analysis and ends with an implemented enterprise architecture. For more information on the TOGAF framework, go to www.opengroup.org/togaf.

FEAF

The Federal Enterprise Architecture Framework (FEAF) is designed for federal agencies. FEAF includes comprehensive modeling and methodology components that are designed to work in highly complex environments. Its modeling components focus on business; IT system components, technologies, and standards; data; and performance. Its methodology includes analysis, definition, funding, and project management. The FEAF may not be useful to private sector companies unless they do business with the federal government.

The Chief Information Officers Council Web site at www.cio.gov/library_category2.cfm/structure/Enterprise%20Architecture/category/Enterprise%20Architecture has more information about FEAF, including guidelines and tools.

Gartner Enterprise Architecture Framework

Gartner Research, a well-known IT research and consulting organization, developed the Gartner Enterprise Architecture Framework to work with both commercial and open source environments. The framework provides a model for examination of business, information, and technology requirements and concerns in the overlapping context of both enterprise architecture and business. While it may not have as many reference guides as some other frameworks, it’s supported by a large body of ongoing research. More information about this framework is at www.gartner.com.

Gartner provides research and advising as a commercial, fee-based service. In my experience, it has proven to be an excellent resource for medium to large enterprises.

Project management

Project management involves breaking projects into planned stages, each with its own specific activities and requirements, identifying roles, and budgeting costs. General project management elements include

Initiation

Planning

Implementation

Monitoring

Completion

General project management approaches may, in some cases, have greater benefit than a formal project management methodology that’s highly focused on a specific area such as quality control or constraints.

Project management methodology

The chief architect (and the lead architect, if that role exists) needs experience with some type of formal project management methodology or at least needs to be comfortable with project management concepts. The size of the enterprise and the level of complexity of the project determines the level of management used. For example, small changes may not need a comprehensive risk analysis or approval by the change advisory board.

Some organizations, particularly larger ones, have a Project Management Office (PMO). The PMO primarily provides guidelines, standards, and documentation on the organization’s project management processes, and metrics for measuring project success. The PMO may work as consultants with unit-level project managers, providing guidance and training, or may directly manage projects throughout the organization.