Enterprise-Wide IT Architecture (EWITA)
The EWITA newsletter
Going out to a list of 273 Architects
Welcome to the latest issue of the Enterprise-Wide IT Architecture Newsletter!
Prior newsletters <here>
Zachman and Metagroup
Blueprint Technologies, Inc.
New publications from the Federal CIO Council
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.
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.
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.
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.
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?
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.
Description of the major phases and deliverables of the EA process.
The core business and technical principles on which all the technical domain architectures are based.
The organizational structure used to govern the process.
Technical and product standards, design principles, and implementation guidelines.
When and how to request an exception to the architecture.
Responses to Frequently Asked Questions (FAQ's) regarding EWTA.
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.
Government Programs, Blueprint Technologies, Inc, "The e-Solution
voice: (703) 790-4748, fax: (703) 734-0987, cell: (703) 362-9058
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
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.
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.