Getting the Most from Your Enterprise Architure by Mark Boster, Simon Liu and Rob Thomas

I need Help, between work, and this newsletter, I do not have sufficient time to generate new content each time. So if you have a favorite web site or a white paper languishing on your C: Drive, send it to me. Get published! Each of us has something to contribute to this community, a simple process, a procedure, or a white paper that you have used effectively can be of additional use to others. You can get some pretty good exposure for your organization by publishing in this newsletter. Send contributions to

David McAfee

dmcafee@ewita.com

Enterprise Architectures

There appear to be two major types of orientations for Enterprise Architecture (EA), the first is process oriented (i.e. Zachman), and the other is more vision oriented (i.e MetaGroup) with many subsets of these two combining various parts of either of the other two.

I do not mean to put down or demean any other type of Enterprise Architecture, but these two seem to be the major basis for most of the major work going on today.

Zachman

The Zachman Framework for Enterprise Architecture, authored by John Zachman, draws upon the discipline of classical architecture/construction and engineering/manufacturing to establish a common vocabulary and set of perspectives-a framework-for defining and describing today's complex enterprise systems. It is a logical structure for classifying and organizing those elements of an enterprise that are significant to both the management of the enterprise and the development of its information systems.

From my perception, the Zachman view is from the IT "trenches", based on the Zachman Framework, it prescribes defining the architecture in many different cells within that framework using many different charting techniques to achieve the most visual representation. For a complete, in-depth representation of an Architecture, the Zachman process cannot be faulted for completeness. It does take extensive time to complete the framework, although John Zachman indicates that by completing only certain cells with in the framework can produce a useable product. Large organizations with a significant personnel budget generally are the adopters of this architecture, for example the Federal Government.

MetaGroup

The Metagroup Enterprise Architecture Strategies (EAS) process was designed to be developed in a short period of time with useful results up front.

Enterprise Architecture Strategies provides an invaluable, ongoing resource that enables organizations to create an adaptive architecture that "engineers out" everything that inhibits change, while "engineering in" a high tolerance for the unanticipated. Offering a set of architectural best practices to guide IT organizations in the process of designing a flexible technical infrastructure, EAS helps clients assess effectiveness, enhance adaptability, and lower total cost of ownership.

The EAS process can be summarized by the following chart

Source: State of California/Employment Development Department/Business Driven Architecture

These architectures are generally developed by large states and organizations with a more limited staff.

Architecture Components

It is my point of view that components of MetaGroup process architectures can be "modularized" and used to develop new architectures for smaller entities. After all aren't the Technology Trends, Business Requirements (WEB and more customer service), some of the Architectural Requirements, Principles, Best Practices, and Design Principles the same in the State of Connecticut, the Employment Development Department of the State of California, the State of Ohio and Texas Department of Human Services. It would certainly seem like it if you read their individual Enterprise architectures in detail.

So What?

Should each architecture be independent or shareable, with canned components? Why should each effort to extract the Technical Trends (for instance) result in any different assumptions since we are all experiencing the using and extending the same technology? Aren't Best Practices industry wide, not limited to a single organization?

Any thoughts on this idea?

<Toc>

------------------------------------------------------

Site Spotlight

State of Connecticut Enterprise Architecture

This site is another example of the MetaGroup's Enterprise Wide Technical Architecture located at http://www.doit.state.ct.us/policy/domain/index.htm.

From the Site:

The Department of Information Technology has implemented an Enterprise Architecture process as part of its mission to develop and support a statewide IT environment for State agencies using standardized IT components and services. The process was used to create an Enterprise-Wide Technical Architecture (EWTA) for the State of Connecticut.

The Enterprise Architecture Process
Description of the major phases and deliverables of the EA process.

Conceptual Architecture Principles
The core business and technical principles on which all the technical domain architectures are based.

Organizational Overview
The organizational structure used to govern the process.

Domain Architecture Documents
Technical and product standards, design principles, and implementation guidelines.

The Exception Process
When and how to request an exception to the architecture.

EWTA FAQ's
Responses to Frequently Asked Questions (FAQ's) regarding EWTA.

Zipped versions (self-extracting) of the Domain Documents along with the Principles and the Introduction are available in Word (13MB) and PDF (17MB) versions

<Toc>

------------------------------------------------------

Vendor Spotlight

Blueprint Technologies, Inc.

Here is a white paper (The Economic Value of Software Architecture) from Blueprint Technologies, a small business specializing in architecture, software development best practices, component development outsourcing, training and education, and mentoring. Blueprint Technologies has over 30 senior software architects on staff (employees) that can bring to any client the depth and breath of experience that comes from working on great number of system development programs. The topic of the attached white paper is the economic value of software architecture. I hope this helps and the readership finds it interesting.

Linda Christoforo, Government Programs, Blueprint Technologies, Inc, "The e-Solution Architect"
voice: (703) 790-4748, fax: (703) 734-0987, cell: (703) 362-9058
www.blueprinttech.com
lchristoforo@blueprinttech.com

From the Blueprint Site:

Blueprint offers customers best of breed practices in software architecture enabling them to build evolvable, maintainable and scalable systems. Below you will find recent examples of Blueprint expertise in areas of design, process and implementation. You must register before viewing or downloading a White Paper<Other white papers here>.

Blueprint's Six Step Software Development Approach

The Benefits of Iterative Development and Object Technology

Requirements Architecture: A Use-Case Driven Approach

Understanding Object-Oriented Analysis & Design

Applying Design Patterns in UML

Integrating Legacy Applications Using XML

Real World Design Patterns for Building Distributed Architecture

The Benefits of Object-Oriented Analysis & Design

ARNIC and Blueprint Technologies

Affecting Organizational Change

Change-Case Template

<Toc>

------------------------------------------------------

Recommended Reading

New publications from the Federal CIO Council

The CIO Council's role includes developing recommendations for information technology management policies, procedures, and standards; identifying opportunities to share information resources; and assessing and addressing the needs of the Federal Government's IT workforce.

Getting the Most from Your Enterprise Architecture by Mark Boster, Simon Liu and Rob Thomas

This document is meant as a sales document, emphasizing the need for an the process to develop a Enterprise Architecture.

Originally published by IEEE (8 pages). Dana Bredemeyer is quoted extensively.

Discusses value of EA, activities to develop the EA, customer expectations, skills of the architect, and product list.

A Practical Guide to Federal Enterprise Architecture, CIO Council, A FAWG Publication, Version 0.9, 2 February, 2001

This document and others on the site should be required reading for IT technologists that deal with the Federal Government. Zachman Orientation. Good set of pertinent websites.

From the preface

An enterprise architecture (EA) establishes the Agency-wide roadmap to achieve an Agency’s mission through optimal performance of its core business processes within an efficient information technology (IT) environment. Simply stated, enterprise architectures are “blueprints” for systematically and completely defining an organization’s current (baseline) or desired (target) environment. Enterprise architectures are essential for evolving information systems and developing new systems that optimize their mission value. This is accomplished in logical or business terms (e.g., mission, business functions, information flows, and systems environments) and technical terms (e.g., software, hardware, communications), and includes a sequencing plan for transitioning from the baseline environment to the target environment.

If defined, maintained, and implemented effectively, these institutional blueprints assist in optimizing the interdependencies and interrelationships among an organization’s business operations and the underlying IT that support operations. The experience of the Office of Management and Budget (OMB) and General Accounting Office (GAO) has shown that without a complete and enforced EA, federal agencies run the risk of buying and building systems that are duplicative, incompatible, and unnecessarily costly to maintain and interface.

For EAs to be useful and provide business value, their development, maintenance, and implementation should be managed effectively. This step-by-step process guide is intended to assist agencies in defining, maintaining, and implementing EAs by providing a disciplined and rigorous approach to EA life cycle management. It describes major EA program management areas, beginning with suggested organizational structure and management controls, a process for development of a baseline and target architecture, and development of a sequencing plan. The guide also describes EA maintenance and implementation, as well as oversight and control. Collectively, these management areas provide a recommended model for effective EA management.

<Toc>