You are on page 1of 16

White Paper - Information Architecture

Alfredo Eloy, The Information Store April 1996

BUSINESS IMPROVEMENT MODEL Improving the business process is a continuous activity that can be modeled in five distinct stages: recognize, justify, plan, pilot and deploy [1]. Recognizing either the need or opportunity for improving the business process is traditionally the starting point. Justification is the stage that weighs the business benefits against the impact of projected changes. Planning is the definition of all activities required to make the changes and identified benefits become a reality. Pilot is the stage in the business process improvement where critical pieces of the plan are tested to lower the risk and exposures of the introduction of changes. Deploy is the stage where changes are carefully and systematically implemented according to the strategies delineated in the planning stage and the experiences gained during the pilot stage. It is in this stage that the business benefits, brought about by changes to the process, are maximally realized. This white paper defines and characterizes information architecture, a part of the Planning stage of business improvement. Planning involves a series of complex activities treated, from company to company, with different degrees of formalism. It commonly includes: Vision and mission statement that delineate, at the highest level, what is the purpose the business, and what is the overall business environment. Strategies and architecture that define the alternatives for how the business will meet its purpose and goals. THE GOAL OF ARCHITECTURE: TO DEFINE FUNCTION AND FORM The objective of an architecture is to describe the function and the form of an environment. Once a business goal is defined, for example to build some new facility, the architect must understand the requirements. Is it a home, an office, a multistory building, a factory, a research laboratory, or a hotel? Once we have defined the facility - say a hotel - several other details are needed to complete the specifications of the planned facility: number of rooms - a decision based on a forecast of the expected business demands class of hotel - a decision on the target clientele airport accessibility - a decision on how close to the airport should the hotel be. If the reasons and features of the facility are clearly understood, the architect proposes options for the form (or style) of the facility. There are at least ten's of designs that fulfill simultaneously the

The Information Store

Information Architecture - Page 1

12/16/96

client's needs, financial guidelines and have the appeal required to run the particular (hotel) business: Single floor, American colonial style Two-floor, individual town homes, cottage style Multistory, central atrium, Spanish colonial many others However, these ten's of options may be constrained by financial, regulatory codes or other factors, such as: Multistory may be limited to six floors because of town codes or proximity to airport. High rise complex is a must if price of land is high and lot sizes are small. Other factors may also impact the choice of style. The clients marketing image or the geographical location chosen, mandates the hotel to be Spanish colonial styled. Perhaps the hotel planned location is not far from a ski resort and that suggests that a Swiss chalet style maybe the best option. This first "high level" architecture specifications are very close to the business demands and the immediate surroundings of the hotel. Once this "high level" phase is completed - say a two-floor motel, Swiss chalet style, near a ski resort - it is necessary for the architect to develop a series of blue-prints detailing many the views for the hotel. External appearance, for example, may dictate (or be dictated by) the nearby available materials, such as wood or stone. Likewise, insulation requirements or codes, may force the choice of particular materials for inside and outside of the hotel. THE PRICE OF LACK OF ARCHITECTURE This process of detailing the hotel continues till the point when the architectural specifications can be translated into engineering design specifications. During the engineering design phase, hundreds of minor and major compromises are done, to balance the business requirements, the financial and time criteria, and the basic construction codes. Finally, during the construction phase, unexpected requirements or unstudied details, cause additional modifications that are, hopefully, all minor in nature. The price of an incorrect architecture (or the lacking of an architecture) is typically felt in the following phases of the project. There are many well known examples of the consequences of inappropriate architectural statements. A couple of recent events highlights the consequences of illdefined architectures: Persistent problems with the luggage transport system at the new Denver airport, have caused years of delay in the start-up of operations and cost tax payers, millions of dollars in financial losses. Microsoft has acknowledged that an incorrectly designed billing and collection system, caused them to collect revenues from clients considerably late. Figure 1, is a newspaper clip from the Houston Chronicle, Saturday, Oct. 5, 1996, describing the problem as: The billing system didnt scale well with the increase in membership. There wasnt one single problem - it was architecture, it was infrastructure
Information Architecture - Page 2 12/16/96

The Information Store

Figure 1 Creating or improving an information systems environment follows the same general process described above for traditional architectural-engineering projects. This was documented by several authors, particularly well by John Zachman [2] in his well-known framework. Information architecture starts with the understanding of the functions required followed by the form (or style) most appropriate to satisfy the user needs. In the study of function and form, it is useful to consider the several tiers of an architecture. They allow the information architect: To translate the requirements of the user into software engineering specifications. To manage the impact of the changes demanded by business. To manage the impact created by the deployment of new information technology.

The Information Store

Information Architecture - Page 3

12/16/96

INFORMATION ARCHITECTURE Information Architecture is the use of the architectural concepts, as described above, applied to the management of information and the associated information systems. Information architecture efforts should precede software engineering efforts for the same basic reasons that general architectural concepts are formulated before engineering and construction work starts. Information architecture must define major components of an information system and the interfaces between the components. It should show how the parts make up a functioning whole, in order to meet the intended business purpose. A well-defined information architecture can be: The means to provide consistent information across all business areas. The foundation for integrating and organizing information as a company asset. The fundamental tool for managing the complexity and changing nature of information technology. Although the benefits gained from architecture maybe only expressed qualitatively, they are aimed at increasing the profitability of the organization. In the simple and routine situations, for example when modifying the data entry screens of a computer program, the need for formal architectural statements is seldom necessary. When larger systems modifications or business policy changes occur, some degree of formalism is mandatory for updating the architectural specifications. However, substantial information architecture efforts must always be considered, when there is a need for the following: To support management strategies and actions, that are intended to improve the overall financial results of the company. To enable the introduction by management of incremental changes, that are aimed at improving the current business work flow. To enable the introduction by management of major or dramatic changes, that are aimed at reinventing the company. An example of dramatic change, is E&P management decision to become primarily a petroleum trading company, dropping most or all G&G activities and associated skills. E&P Management may also consider the opposite dramatic alternative; it decides the company should become a large operator. It needs, therefore, to acquire the appropriate skills, and to define the organization and processes that support the strategic move to become a large operator. In both situations, there will be extensive changes in the business process and all the associated systems. In these situations, the architecture acts as insurance helping management test or simulate the projected change. How much is insurance is necessary? The answer can only be given by studying the risk (probability) and exposures associated with the projected business move. However, large and complex projects, involving many interrelated activities, should always have some insurance coverage as architectural specifications.

The Information Store

Information Architecture - Page 4

12/16/96

INFORMATION ARCHITECTURE BACKGROUND Information architecture has been traditionally the realm of the Information Systems (I/S) organizations. It has served two purposes: first, it has allowed I/S to communicate within the company at different levels; second, it has facilitated transmitting requirements to providers of specifications, products and services. In mid 1980s, I/S had to deal with the massive introduction of personal computers and workstations. At the time, information architecture concepts, become accepted as the vehicle to bring order to the chaos created by the rapid changes in information technology. The pressure to deploy infrastructure in an organized fashion, lead to the understanding of the need to view and study information architecture in tiers (or levels). The efforts at IBM, with the Zachman framework [2], at Digital Equipment, with Technical-Architecture-2 (or TA2 ) [3], and at Apple, with the Vital Architecture [4], were all instrumental in providing considerable clarity to the information architecture topic. Those efforts introduced and identified the several tiers of an information architecture. The breakdown in tiers was recommended because of the following main reasons: The tiers allowed I/S to correctly understand and position the several, and seemingly disparate, methodologies aimed at defining architectures. The tiers permitted I/S to engage individuals with the correct skills to study and define the content of each tier. Those with a predominant bend or background on the business can be assigned to work in the tiers that are business oriented. Those with more of an information technology bend can be assigned to define the technology oriented tiers. Architectures in each tier are affected differently by internal (company) or external factors. The detailed analysis, by I/S, of the factors that influence a specific tier, allows for managing the impact of each factor, and permits the development of action plans that are based on different planning horizons. INFORMATION ARCHITECTURE TIERS Four main tiers are recognized when one develops an information architecture: business, systems, technical and product (Figure 2). The tiers should be not be viewed as neatly separated or compartmentalized parts of an organization; they are all inter-linked and dependent on each other. They are a convenient breakdown aimed at facilitating the management of all information related resources.

The Information Store

Information Architecture - Page 5

12/16/96

The Information Architecture Tiers The Information Architecture Tiers


Planning Horizons, Dependencies... Planning Horizons, Dependencies...
Traditional Traditional Planning Horizons Planning Horizons Business Architecture Business Architecture 55- -77Years Years Systems Architecture Systems Architecture 33- -55Years Years Technical Architecture Technical Architecture Business Dependent, Business Dependent, Technology Independent Technology Independent

11- -33Years Years

11Year Year

Product Architecture Product Architecture

Business Independent, Business Independent, Technology Dependent Technology Dependent

Figure 2 Business Architecture - At the highest level, this tier is used to identify the major requirements for information systems, such as the need for common data models or common business objects or views. It is fundamentally business dependent but (should be in as much as possible) information technology independent. It needs to be assessed and updated periodically to reflect the corresponding business changes and the deployment of the latest business technologies (such as horizontal drilling or 3-D and 4-D Seismic). In order to identify the information systems requirements, the business architecture makes use of the overall business value-chain (from Exploration to Production) and of business decomposition into basic units of work (or activity). For example, build a geological model is a basic unit of work that is part of both the business processes identify and evaluate opportunity and explore acreage. It will appear once in the business decomposition charts but will be repeated, in several parts of the E&P value-chain (Figure 3).

The Information Store

Information Architecture - Page 6

12/16/96

Deals with the E&P Process Decomposition... Deals with the E&P Process Decomposition...
Identify & Evaluate Opportunity
Collect Data Re-Build Geological Model YES
Define & Agree Work Program Define Opportunity Optimize Value of Opportunity Define & Agree Work Program Drill Exploration/ Appraisal Well(s)

Business Architecture: Business Architecture:

Collect Data

Explore Acreage

Build Geological Model

Assess & Optimize Value of Prospect(s)

Analyze Competition

Target Prospect(s)

No

Proceed ?

From Business Process to Activity !! From Business Process to Activity !!


Figure 3 The Business Architecture portion defines why we need to automate a certain part of a business function or process. In summary, it describes in detail the E&P value-chain, business activities, and includes a high level view of data and information requirements. Systems Architecture - The Systems Architecture tier uses the rules and requirements from the business architecture and defines what needs to be automated. System, as referred to here, is the set of related applications, databases, files, job streams and procedures that support a business process such as in-fill drilling or acreage delineation. This tier deals directly with the processes and data that require automation. It also provides the style and methods to be used in building, organizing and controlling a business system. It relies on existing widely adopted policies, standards (such as the Epicentre data model) and protocols. It also relies on the standards and protocols defined for the Technical Architecture tier, specifically for inter-process communication. However, it is fundamentally business oriented or dependent, not technology driven (Figure 4). The Systems Architecture is not a detailed plan for systems implementation. The systems planning activity is program and project oriented, while the Systems Architecture is oriented toward the formulation of systems strategies.

The Information Store

Information Architecture - Page 7

12/16/96

E&P: Linking Business and Systems Architecture E&P: Linking Business and Systems Architecture
E
1 2

Information Architecture Information Architecture

D
4 3

Systems Architecture for Data and Information Management

E&P Business value-chain Inputs Inputs Insights Insights Tools Tools

Data Warehouse System Data Warehouse System


(Databases, Applications & Procedures) (Databases, Applications & Procedures) Continuous Improvement Environment: Continuous Improvement Environment:
Flexibility Flexibility Integration Integration Client-orientation Client-orientation Business Value Business Value

E&P Business decomposition

Epicentre Data Model

Figure 4 Technical Architecture - This tier describes concepts and techniques used to create a commonbase technology. It provides the framework required to build effective business systems. Included in this framework are the distributed computing styles, development approaches, standards, and the information distribution and access techniques. Topics such as client-server, data stores, data warehouses, and object-oriented technology are themes of this tier. One of the key objectives of this tier is to be business independent but technology dependent1, reflecting major technology advances such as, how to take advantage of internets and intranets. The key goals of the technical architecture are: To provide systems that adapt easily to changes in business requirements. In the absence of the Technical Architecture thinking, the tendency is to avoid or postpone making changes, simply because of the problems of doing so. To have systems interact better with each other and enhance services levels to all information end-users.
1

Technology dependence should not be construed as dependence on particular vendors or products. Rather, it refers to the dependence on major technology concepts or abstractions that are either in vogue or are emerging. Open systems, client-server, and data warehousing are examples of concepts that are implemented, via products, tools and services, in the Product architecture tier.

The Information Store

Information Architecture - Page 8

12/16/96

The Technical Architecture interacts with the Product Architecture tier - also known as Infrastructure Architecture since it needs to consider the most current base of information technology products or infrastructure (hardware, systems software, networking). As the technological opportunities expand and characteristics (such as cost/performance ratios) change, new areas for efficiency are identified in the Technical Architecture. The Product Architecture - This tier describes how the products, tools and services that are currently installed or planned are mapped against the design and functionality, as they are defined in the Technical Architecture. It deals with product (hardware, system software, systems utilities, data base management systems, and networking software) selection strategy, installation strategy and overall service levels. This tier should be technology dependent but, as much as possible, independent of the business work flow changes.

The Information Architecture Tiers The Information Architecture Tiers


Tiers Deal With... Tiers Deal With...

Business Business Architecture Architecture

Asset A Asset C Asset Z

Asset B

Business processes Business processes Organization, hierarchies Organization, hierarchies

Systems Systems Architecture Architecture

Process1 Process2 ProcessN


Database x

Process3 Process4

Data & Application Data & Application Interoperability, Data Model, Interoperability, Data Model, Application Portfolio Application Portfolio

Technical Technical Architecture Architecture


Client A Client A

Server X Server X

Server Y Server Y

Client B Client B

Client C Client C

Client D Client D

Rapid, Effective and Rapid, Effective and Efficient Deployment Efficient Deployment of Technology of Technology

Product Product Architecture Architecture

Windows NT Windows NT

Sun Solaris Sun Solaris

Create, Run Infrastructure Create, Run Infrastructure Improve Service Levels Improve Service Levels
Terrasciences Terrasciences

Landmark Landmark

Charisma Charisma

Zycor Zycor

Figure 5 Figure 5 summarizes the key aspects of the four tiers of an information architecture. INFORMATION ARCHITECTURE - THE NEW PLANNING HORIZON

The Information Store

Information Architecture - Page 9

12/16/96

When the information architecture ideas were first formulated (mid 80s), it was generally accepted that strategic information technology plans for each tier, should be prepared and revised periodically as shown in Table 1: Table 1 Architecture Tier Business Systems Technical Product Planning Horizon Circa 1985 5-7 Years 3-5 Years 2-3 Years 12-18 months Planning Horizon Circa 1996 (NEW) 3-4 Years 2-3 Years 12-18 months Weeks to months

It was also generally accepted that the two middle tiers (Systems and Technical) were fundamentally buffer tiers. They were used to manage the changes coming from above2 (business-driven changes) or from below (technology-driven changes) that tended to cause the larger disruptions on work flows. However changes and developments are happening in all tiers requiring the establishment of more realistic planning horizons as shown also in Table 1, under NEW planning horizon. A succinct discussion of the major changes and developments affecting each tier follows: The pace or rate of change in the Business tier continues to accelerate. This is a phenomenon affecting most industries. In E&P the changes are the consequence of the rapid introduction of two main developments. First, the steady deployment of new business technologies, for example, advanced multi-lateral wells, intelligent completions, extended reach wells, and 4D seismic. Second, E&P management is pursuing more effective organizational structures including, multidisciplinary asset teams, outsourcing, strategic partnerships, and extended enterprises. Business reengineering (BR) efforts in early 90s, were instituted by management primarily to recover financial competitiveness. Today BR has become a way of life, with E&P management requiring from their companies constant rejuvenation to facilitate and accelerate the pace of business decision-making. This rejuvenation is driving many in the E&P management ranks to deploy changes much more rapidly; today, it is common for major business changes to become mature in 3 or 4 years. Key developments have affected the Systems tier. The major development impacting this tier is the E&P industry evolution towards common specifications, standards and protocols. The origin of this development lies on some of the E&P management strategies described above. Once E&P management decided that sharing and strategic partnerships were desirable business practices, it was necessary to create, via shared efforts such as consortia, industry-wide accepted common specifications. The creation of POSC, POSC/CAESAR, PPDM, URGENT, SAVE, ETAP and dozens of other joint projects in all sectors of the industry, are the consequence of management strategy affecting the Systems tier. No longer is it possible for I/S organizations to disregard the data and applications needed to support the extended E&P enterprise. Today, a typical life-cycle of
2

The idea of above and below refer to the relative position of each tier as shown in Figures 2 and 5.

The Information Store

Information Architecture - Page 10

12/16/96

2-3 years is required to develop and maintain the specifications required by the activities of the joint projects listed above. Key developments have affected the Technical tier. There are two major developments impacting this tier. The first key development started in the late 80s, and its goal was to breakdown the traditional data processing environment into sub-environments dealing with the data capture and data access functions. This development, which gave rise to the data warehouse phenomenon, is beginning to reach the E&P industry. However, like so many other developments, this new data processing environment needs to be architected to include specific E&P data and database requirements, such as project databases. The second key development is the secondary3 impact of the Internet phenomenon. Most or all I/S organizations are being asked to deploy a combination of internets and intranets to take advantage of the free, world-wide, common infrastructure provided by the Internet Wide World Web (WWW). The combined impact of the two developments, suggest that I/S must now assess every 12 to 18 months the technical architecture tier. The pace or rate of change in the Product tier continues to accelerate. The changes and developments are numerous and include: The rapid and continuous decrease in hardware and software costs, now allow many more users to come on line. The almost absolute dominance of personal computer workstations as clients and servers, has created a new orientation in the deployment of systems. Client-server architecture, the predominant software engineering architecture, is forcing the redevelopment of the mission-critical applications. Relational database software (Rdbms), the mature and prevalent database technology, is forcing the re-development of the mission-critical applications. Object-oriented software technology, the next key database technology, will cause another cycle of re-development of the mission-critical applications. The selection of the WWW browsers as the choice user-interface software, will cause another cycle of re-development of the mission-critical applications. The broad adoption of WWW protocols and language (JAVA), will cause a major re-design of the mission-critical systems. The evidence of how quickly technology is being introduced today, is provided by the deployment of the so-called WWW browsers and search-engines. For example, the most recent versions of the Netscape and Explorer web browsers have been introduced in intervals of 8 to 12 weeks. Test (Beta) versions of next major release of those products, commonly overlap with the delivery of the previous version. Most software vendors are also scrambling to re-design their applications in weeks or months to take advantage of the facilities provided by the WWW and the JAVA language. INFORMATION ARCHITECTURE FRAMEWORK
3

What it is regarded today has the primary impact of Internet and related technologies, is discussed in the changes in the Product architecture tier.

The Information Store

Information Architecture - Page 11

12/16/96

The establishment of a general framework for defining information architecture was commissioned in mid-80s by a consortium of companies representing many industries. In 1986, Partnership for Research In Information Systems Management (PRISM), a multiclient research service of Index Systems and Hammer and Co., published the framework [5]. Several petroleum companies and E&P service suppliers were members of the consortium that is no longer active. The companies were represented in the consortium activities by staff from their central or corporate IT departments. The framework specified by PRISM remains valid and continues to be extremely useful due to its completeness and simplicity and it can be used to define any of the architecture tiers previously discussed. The framework has two basic dimensions: domains and components. Architecture Domains & Sub-domains - Architectural specifications are always created for a specific domain of study. Examples of architectural domains are: a building, a business, a computer system, an information technology application, a database, or a division of corporation. These domains can be part of a larger domain of study and are then, by definition, sub-domains. For example, when dealing with the data domain, for an information architecture, one may choose to break it down into four sub-domains: data access, data capture, metadata-dictionary, and end-user services. Architecture Components - What all architectures statements have in common are four basic components: inventory, principles, models and standards. Principles embody the philosophy of the business and its objectives. They are the most important component and drive all other aspects. Inventories are the least important and they reflect the existing architecture. Models are pictures of the desired state, with emphasis on what goes where and how it is all connected. Standards are the specific rules or guidelines for implementing principles and models. Below are more complete explanations of each component. Inventory - Is the component that represents the architecture currently in place in a company. The process of taking inventory identifies the elements that are in place now. Inventories are an initial effort to get "things going" and can be useful: To identify hidden assets, gaps and redundancies To manage business costs To find who is using what and why To classify by value, using a commonly adopted framework (such as the investment lifecycle model [6]), the business assets. An example of a list of elements of information needed to inventory the IT infrastructure domain, is shown below - (Example in brackets). Domain Sub-domain Item Description Number Cost Average Configuration
The Information Store

(IT Infrastructure) (Hardware) (PC) (Dell - Model xyz) (District 1: 10 units, District 2: 5 units) ($3,000)
12/16/96

Information Architecture - Page 12

Life-Cycle Value Remarks Business Need Principles

(Leverage item) (Items leased) (Who and why)

Principles are the most stable component of an architecture. In an atmosphere of change and uncertainty, they represent continuity and relative stability. When developed correctly, they serve as the starting point for the most difficult evaluations and decisions. Indeed, in many situations, principles are the only rational basis for coming to a decision. Principles are the most important element of the architecture and when crafting them several points should be kept in mind: Principles should be few in number; they are not a shopping or laundry list that covers every business detailed situation. It is generally accepted that three to five principles, is the reasonable number of principles to be crafted for each domain. Principles are statement of belief; not facts, not truisms, not natural laws. Principles, therefore, can be periodically overridden to permit a non-envisioned event to take place. The routine by-pass of an agreed principle, however, generally implies that principle is no longer valid; it needs to be assessed, discussed and rewritten to reflect the new reality. Principles should be defensible; the benefits from each principle must be clearly identifiable and understood by everybody in an organization. A high level of confidence in the value of a principle, is the best assurance that compliance to it will happen. Principles should be specific and clear enough to create new behavior within organizations. They should be carefully crafted by teams and broadly communicated to all to avoid multiple interpretations of the "spirit and letter" of the principle. Principles must not conflict with each other; careful crafting and review of each principle are necessary. Principles are typically stated in the present tense. Principles must be stated and endorsed by senior management; their business implications must be integrated in the general business planning strategies and tactics. The basic sources for principles are: vision and mission statements, values and attitudes, scenarios, trends and market conditions. The study of principles should include the following elements of information - (Example in brackets): Domain Sub-domain Principle Statement Benefits - Pros Concerns - Cons Implications (Data) (Data Administration) (Each occurrence of shared E&P data has a defined and unique master source) (Promotes timeliness and quality of data) (Implies existence of a common data model) (Requires a robust communications network for support)

The Information Store

Information Architecture - Page 13

12/16/96

Models Models are iconic or analytical representations of the real world. Information architecture models tend to be graphic representations of the real world. Models tend to encompass multiple architectural principles and normally they are associated and represent an architectural domain or at least a few related sub-domains of study. When defining an architecture, models play different roles: Descriptive role: here models are an adjunct to the Inventory and are used to identify processes, entities, interactions and iterations. Flesh-out role: here models are an adjunct to the crafting of principles and they help highlight where principles are needed. Mapping role: here models are used to help validate solutions against the architecture. Examples of this use of models are the before and after charts developed for the Infill Drilling process. These charts, created for the POSC Industrial Pilot Project [7], are included at the end of this white paper. Simulation role: here models are used to simulate usage and systems behavior, to help size and cost systems and measure performance. Standards Standards are the specific rules or guidelines for implementing principles and models. Standards flow naturally from principles (and the related models) as the concrete guidelines to particular development efforts. They are the most detailed aspect of the architecture, and the primary activity in which names are named. Standards make the architecture real and provide specific guidelines for decision-making. Standards can be classified from several perspectives [8]: Usage or acceptance classification: Industry standards, are those developed and accepted by a recognized industry group. Proprietary or local standards, are those developed and applicable to only to one or a set of technology vendors. De Facto standards, are generally proprietary standards that become standards by virtue of their use and abundant proliferation. Scope-of-implementation classification: Horizontal (that is cross-industry orientation, process oriented) Vertical standard (that is single industry, function oriented) Needs-based-perspective classification: Architectural, those that are anticipatory and lead to benefits for a whole industry; typically aimed at improving products or reducing costs. Technology-driven, are those where the technology precedes the standard. Vendor standards are examples of this type.

The Information Store

Information Architecture - Page 14

12/16/96

Arbitrary, are those where basic technology is not a deciding factor and any number of standards can be adopted.

SUMMARY AND CONCLUSIONS Strategy and architecture are part of the planning stage of a model adopted to improve the business process. They are used to translate the purpose and goal of the business into blueprints describing how the goals are to be achieved. Information architecture must translate the business need for data, information and knowledge into specific action plans. These plans are the blueprints describing the style and function of the systems to be implemented. Comprehensive information architecture efforts must always be undertaken, when dramatic business changes are involved. The price for not architecting systems can be high. Detailed architecture statements are the best insurance policy or protection against technology complexity and constant changes of business and organization. Detailed architectures statements, when are properly maintained, can be used to model what if business situations. The four tiers of an information architecture (business, systems, technical and product) provide I/S the means to discuss and plan the resources required to develop comprehensive architectures. Time horizons for information systems planning are shortening due to frequent demands for business changes and constant technology advances. A framework to manage the information architecture tiers must be installed to provide I/S with the means to respond to business-driven or technology-driven changes. The PRISM framework provides the means (domains and components) to study and describe each tier of an information architecture. Of the components of an architecture, principles and models are the conceptual backbone, with principles setting the tone for the overall architecture. Standards translate the architectural concepts into reality. They make the architecture real.

The Information Store

Information Architecture - Page 15

12/16/96

REFERENCES [1] O. Teoh, K. Makgill, Migration Considerations, POSC paper, August 1993. [2] John A. Zachman, A Framework for Information Systems Architecture, IBM Systems Journal 26, No. 3, 276-292 (1987). [3] Henry Theberge et al, Information Systems Technical Strategy and Architecture, Digital Information Systems document, Digital Equipment Corporation, February 1989. [4] Lani Spund et al, VITAL Architecture Guides, Apple Computer, 1993. [5] Partnership for Research In Information Systems Management (PRISM), Dispersion and Interconnection: Approaches to Distributed Systems Architecture, Final Report, June 1986. [6] S. Chaiken (Index Group), K. Jacobs (IBM), Ted Lumley (Mobil E&P), Technical Computing Investment Management Model , 1990. [7] L. Gahagan et all, Industry Pilot Project (IPP) Phase Ia Completion Report, 1994. [8] R. Saporita, Presentation, ANSIs 1993 Annual Public Conference, 1993.

The Information Store

Information Architecture - Page 16

12/16/96

You might also like