Framework for an integrated architectural approach

Author:Ward Erhart, architecture consultant at Ordina Utopics Corporate Information, werhart@utopics.nl

Special thanks to: Rex Arendsen, Gerton Kuis, Theo Snijder and Eerko Vissering

Abstract

Several kinds of architectures are distinguished in this paper. Attention is also paid to the development of these architectures. Of course, the goals that are pursued by using architectures and the terminology used are also presented. Five different kinds of architectures are identified, each of which is presented, though not formally defined. Further research is required to the parts constituating the recognized architectures and guidelines regarding the design of architectures. What is presented is an (conceptual) framework, not a complete method.

Kinds of architectures

Different kinds of architectures can be distinguished by the goals that are pursued. By clearly distinguishing the different aspects of information systems and relating them to the way of thinking of different management levels meaningful and equal discussions can arise.

Based on this line of thinking, three levels of architectures are distinguished: Business architecture Information architecture Application architecture

In the development of the business architecture the policy makers (the strategic management) have to outline the opportunities and threats that they perceive for the company in the future. To create an information architecture the tactical management needs to state which information(flows) are required to support the business processes optimally. During the development of the application architecture the operational management have to indicate what functionality is required, how the information systems need to interact and where the ownership of the data lies. The information architects, finally, are responsible for the identification and maintenance of relationships between the different architectural levels and the overall structure of the information systems of the company.

The development of architectures

An information architect in the first place needs to aim at company-wide support for the architecture and in the second place needs to guard the quality of the results (conciseness, completeness, consistency, etc.). For this reason a non-mechanistic architectural framework and approach is presented here, designated to a specific business case. Since the approach lacks design principles, a sample business case is included.

The framework presented here has been proven in practice to be valuable in the development of information architectures. The following principles appear to be usefull: Follow clear principles Speaking is silver…. Employ existing designs and systems whenever possible

1

Every (architectural) approach has to include some preferred order of designing a number of models. Currently the challenge lying ahead is to distinguish models and guidelines to accompany the approach without creating a strict methodology. Ways have to be found to make the architectural approach presented here controllable and transferable.

Architecture

Definition and goals

Recently the concept of ‘ICT-architectures’ has gained interest. Most often the purpose is to create a corporate blueprint of the information infrastructure, though no concise definition currently exists. Here, the following definition of (ICT) architecture has been used:

An architecture is a global design (of a part of) the desired information infrastructure based on a shared vision

Important aspects of the definition are: ICT-architectures are the topics of interest; An architecture is a global design of the desired situation regarding the information infrastructure; It is a global design. Details are left out to ensure a desired amount of flexibility; An architecture is an image of the future and should therefore be based on principles that will hold

out in the future; Each architecture is based on a specific perception of the future, which is called a vision; The design consists of a number of interrelated models, which together with the vision, make up

the architecture; The vision is the common starting point for all models included in the design.

The most important goals pursued by using architectures are:

Point of referencean architecture serves as a mean to structure discussion about the development of the information infrastructure. It can serve as a point of reference to all parties involved.

ControlabilityAn architecture helps to reduce the complexity of developing and using an information infrastructure concurently by providing insight in the relations between different parts of the infromation infrastructure. Architectures also are useful to depict the desired situation. This way, the consequences of changes become apparent which makes it possible to control the development of the information infrastructure.

MaintainabilityAn architecture makes it possible to define steps to achieve changes in the information infeastructure in an ordered way. By having insight in the consequences of changes a preferred plan of action can be constructed. This way, the development of the information infrastructure becomes maintainable and manageable.

2

Distinguished architectures Different management levels in an company have a different perception and interest. The most common way of representing these management levels is a pyramid, as in Figuur 1 [Head 1969].

The following management levels are distinguished:

1. Strategic management : formulation of strategic plans and goals of the company;

2. Tactical management : deciding on budgets and allocation of people and means to different departments;

3. Operational management : the planning of operational activities and reporting the results achieved;

4. Transaction processing : processing of (customer)orders;

Different management levels are interested in different aspects of the information infrastrucuture. The operational management, for instance, is dedicated to solve the daily problems, whilst at the strategic level the focus will be on gaining a competitive advange. Based on the different management levels and their interests three different architectures are distinguished in the next section.

Background

The deployment of architectures is a continuation of information planning [Poel et al. 1989]. Information planning descends from the time when much, if not all, was centrally coordinated. This approach does not support the rate of change of todays world with mergers, shortening the time-to-market, the need for multi-channeling, etc. Nowadays, it is not seen fit to first elaborately analyse the situation, weigh by all different possibilities and then formultate an all-embracing policy.

What is required, is an approach where different areas are distinguished whereto it is possible to delegate the policy-making. In such an approach it is essential to identify the borders and interaction between those different areas instead of coordinating the content of all policies. This perception is the foundation for an architectural approach where the borders of design-areas are distinguished, rather than creating a complete set of designs.

Business architectureA business architecture depicts the relationships between the current information infrastructure, the strengths and weaknesses of the entrerprise as a whole and current developments in ICT. This

Figuur 1: management niveaus

3

‘strategic interaction’ has been identified and described in [Theeuwes 1988] and contains all elements considered to be relevant in the design of business architectures. The way this strategic interaction is used in information planning approaches can therefore be used as a guideline in designing a business architecture.

Information architectureDatasets and their interconnections generally are the least flexible part of the information infrastructure and as such can best be treated as a stable basis [Sanden 1997]. In the Information Engineering approach [Martin 1989] functional decomposition is used to determine independent datasets. Besides these approaches several frameworks exist where different (design)areas are distinguished [Truijens 1990]. All of these approaches are relevant in treating the different areas of concern in designing information architectures.

Application architectureAn application architecture can best be seen as a blueprint for the design of an information system or application. Often all kinds of engineering / design methods are used to create such a blueprint. Most of those are Software Engineering approaches and not suitable to develop an architecture [Rees 1995]. In this paper no approach is presented to develop an application architecture, though it is recognized that at least a set of guidelines is required to be able to have meningfull discussions about such architectures.

IntegrationThe recognized differences in vision and different aspects of interest for each management level are the foundation for recognizing different architectures. This has also been recognized by Tuijens and is used as a starting point for his approach. In that approach the focus shifts from the top (strategic) and middle (tactical) management to the software developers that actually design and implement the information infrastructure. Especially the integrationstep where consensus between both users and developers is pursued is considered valuable [Truijens 1991]. In our opinion, the adjustment of the different architectures is essential for succes in an architectural approach.

Business architecture

The business architecture includes descriptions of the companies products, the desired development of the business processes and the companies strategic choices made. Any trends and relevant developments regarding the line of business, such as structure of the organisation, distribution channels used and growth figures, should be included in the business architecture. Together this results in a number of prerequisites for the way the company should operate in the future.

The business architecture represents the vision of the companies strategic management. The information architect needs to translate this into goals and limitations for the information infrastructure. Aspects that need to be included are the required amount of support for the business processes, the product-model used and the future perspective created by ICT.

Information architecture

The information architecture describes the information exchange required to adequately support the business processes. Every information flow is characterized by: the information source, a brief

Strategic choices, prerequisites,

and trends

Consistent terminology

4

description and the type of data being exchanged. The description should be put in the terminology used by the companies tactical management. All internal or external information sets used within the company should be included in the information architecture.Ideally the information architecture should be implementation independent. No statements regarding the way the information sets or exchanges are implemented should be included. In practice however, many requirements have to be included regarding the nature and security of the information exchange,

such as “on-line real-time processing” or “24 / 7 availability”.

Figuur 2: kinds of architectures

Application architecture

The application architecture contains all functions available to support the processing of transactions and the necessary information flows. At the highest level the operational management should identify the required support for each business process. That way the highest level of the application architecture can be seen as a blueprint for the companies information systems (sometimes, called the systems architecture).

All different kinds of information flows and systems should be recognized in the application architecture. Especially different requirements such as user-friendliness and type of information system desired response times and dependability of information flows should be included.

Implementation independenceSeperate aspect

architectures

5

Software-architectuurApplication architecture

Application services and information (sub)systemsWhite-box model, focus on the construction of systems

Information architecture

InformatiedienstenInformation sets and Information flowsInformation infrastructure as a black-box

Business architectureProducts

Business processesStrategic choicesICT opportunities

Development architecture

Standaads and guidelinesQuality control

Software development tools

Infrastructure architecture

Platforms, middleware, network

Business terminology

Software development terminology

Different kinds of systems, such as a call-center, management information system or accounting system have different requirements. Similar kinds of systems (transaction processing, reporting or front-office systems) should be included in separate aspect (application) architectures.

For each aspect architecture a specific development method can be used that is found suitable for its specific characteristics. This way the transaction processing systems all will meet the same criteria regarding response-times, throughput capacity, security and robustness. Also, in each aspect architecture different systems can be distinguished to provide for the differences in desired services. For instance, data storage and access can be arranged differently in different aspect architectures.

Infrastructure architecture

The infrastructure exists of readily available technical components such as middleware, databases or directory services. The infrastructure architecture contains the kinds of components that are required, such as afirewall or a relational database and how these are interrelated. However, no specific instances of the architectural components , such as a specific kind of database system, are identified. By identifying the specific technical components that are to be employed by the company the infrastrucure is specified.

Development architecture

The development architecture specifies the development process related to a specific aspect architecture. Many different aspects of software development processes have been identified in computer science literature, but three main categories can be identified1:

Managing the software development processThis includes the way the software development process is managed and includes the way development processes are controlled with respect to criteria as cost and quality. These activities contribute to the desired results in an indirect way.

Development methodThis involves the way the software is actually designed and created.

Support of the software development processThis includes all tools used in managing the software development process and developing the software and other related products such as documentation.

Development architectures are designed using software development methodologies. A methodology can be seen as a framework or reference architecture for software development processes. Such a framework needs to be instantiated for each specific software development process. Many methodologies are tightly coupled with some technology such as client/server or object technology. Other methodologies are aimed at certain aspects of the software development process. As a consequence a development architecture will comprise several methodologies. It is no trivial question to make a selection of the many available methodologies and combining those selected methodologies into one software development process.

Especially in companies where many software development projects are invoked a software development architecture will be valuable. In that case it will often pay off to limit the number of different software development methodologies employed. By defining a limited number of company

1 These main categories are taken from the “five ways” of Wijers and sol. The “ways” excluded here are the way of thinking that in our opinion is included in the underlying vision and the way of denotation that is seen as a part of the resulting products.

Three aspects

6

specific development methodologies each aimed at a specific aspect architecture the total number of methodologies and tools being used company wide can be reduced. This way both the cost of educating staff, tool licenses and software maintenance can be reduced.

7

Developing architecturesAt every management level different goals are pursued, which in the approach presented here is reflected in the objectives of the related architectures. The different management goals related to the application of software are: Strategic management: ICT has to contribute to the company mission; Tactical management: optimal utilization of the available budget; Operational management: Improving the information infrastructure by solving problems.

An architecture in the first place outlines the goals the information infrastructure should meet. This raises questions of what information systems should be constructed and how the software development process should be arranged.

Several approaches as advocated by several Dutch authors are outlined here and three skills that are found to be valuable in practice are brought forward. After that some results from a sample case, the internet bank, are presented. The sample case is not fully elaborated, but merely gives an impression of the shape and content of the different architectures.

Background

A number of years ago, van Rees became well-known in Dutch literature because of his article ‘the Method doesn’t do the work’2. The underlying thought of the article can be found in the author’s approach to architectures. He advocates of clearly establishing a difference between information-architects and system constructors [Wisse 1995]. He also urges the necessity of an architecture to be more than a high-level design [Rees 1998]. Aspects such as culture and the distribution of power in the company are always relevant. This line of thought can also be found in the architectural approach presented in this paper.

Such an approach is drawn at daggers with strictly methodical approaches, such as those of Panfox [Sanden 1997] or SDM [Oosterhaven 1985]. An advantage of strictly described approaches is that they are well documented, which makes it possible for different people to apply them in the same way. Another advantage is that the required skills and knowledge for successfully designing architectures can be identified. This makes it possible to educate information architects and compare the qualities of different architectural designs.

2 Dutch: ‘De Methode Doet het Niet’.

8

Skills of an architectIn practice some general skills can be identified that are valuable for an information architect. These skills are independent of the models created and the architecture on hand, since they contribute to the acceptation of the result by the management.

Use sound principles

Sound principles are required to design an architecture that is easy to understand, elegant, consistent and complete. Many sound engineering principles have been recognized throughout the history of computer science. Well-known principles are separation of functionality and implementation (using well-defined interfaces), data-hiding, loose coupling and identifying the ownership of data and systems. Other useful principles are a Single-Point-of-Definition for all data and using functional decomposition to recognize different applications.

If the underlying principles are put on paper the architecture becomes easier to understand and the quality of an architecture can be made explicit. The selection of the set of principles to apply in a specific situation is crucial, since it is impossible to employ all principles to a specific architecture. The judgement of which principles are ‘right’ or ‘the best’ is highly subjective. Therefore, some kind of guideline or standard is needed to objectively judge the quality of a given architecture.

Speech is silver…

The design of an architecture is not a goal in itself, but a means to communicate effectively with the management. The goal is to design an information infrastructure in line with the vision (future expectations) of the management. Broad support within the management is required to ensure the architecture reflects the company vision. In order to gain the required support an architect should be able to present the models and underlying priciples of an architecture to the management. However, in practice, speech appears to be silver and silence is gold.

Employ the existing situation

At every management level several models can be used to construct an architecture. Every information architect should therefore be familiar with different kinds of models and general design principles. In general it pays off to use existing models and design principles. This should be preferred over always using the same set of models and guidelines. Moreover, employing existing models and guidelines is perceived as a critical success factor in gaining support for the architecture.

9

ConclusionsAn architectural approach has been presented that includes three levels of architectures. A business architecture

This architecture is constructed in cooperation with the strategic management of the company and states the direction in which the line of business will develop and what opportunities ICT can provide.

The information infrastructure This architecture outlines the information infrastructure required to realize the strategic goals and to support the business processes.

The application architecture This architecture is the design of the constituating parts (information systems) and their interrelationships that together make up the information infrastructure.

The approach presented is based on the image of an architect who passionately combines the wishes and demands with practical guidelines and design-principles. The companies mission, ambitions and it’s culture should be reflected in the resulting architectures.

As a result the main focus of the approach is aimed at gaining support for the architectures whilst the definition of required models and definition of standards is seen as less important. In practice also no specific model has proven itself to be indispensable. On the other hand, the lack of strict guidelines makes the approach look more like craftsmanship than an engineering discipline.

Research recommendationsFurther research is required to determine different sets of models that can be used in the design of the recognized architectures. Also standards and guidelines have to be developed to make it possible to objectively discuss the quality of architectures.

Another research direction consists of the knowledge, skills and expertise that can be expected of an information architect. And how can information architects be educated and trained?

10

Case: the Internet BankHet motto van de Internet Bank is: meer gemak voor de klant. Als operationele doelstelling wordt daarbij gehanteerd om 24 uur per dag, overal bereikbaar te zijn. Als lokkertje biedt de Internet bank aan iedere klant een credit card en een doorlopende reisverzekering.

De Internet Bank heeft geen kantoren, maar is bereikbaar via internet en telefoon. De primaire doelgroep is de hardwerkende (jonge) professional, die geen tijd of zin heeft in papieren rompslomp.

De dienstverlening van de Internet Bank bestaat, naast eenvoudige bankzaken, uit de mogelijkheid tot beleggen en het afsluiten van verzekeringen. Daarnaast zijn er een aantal aanvullende diensten die de klant kan kopen, zoals SMS-waarschuwing op aandelenkoersen e.d. De bank verkrijgt haar inkomsten uit aan- en verkoopkosten van de beleggingsopdrachten en verkoopprovisie op de verzekeringsproducten.

Zowel het uitvoeren van beleggingen als de verzekeringen worden uitbesteedt, op voorwaarde dat het product onder het label van de Internet Bank geleverd kan worden en de afhandeling geheel elektronisch kan verlopen.

Business architectuurIn de business architectuur wordt uitgegaan van de bedrijfsprocessen. Voor de Internet Bank worden onderkend:1. Klanten interesseren en informatie verstrekken over de dienstverlening van de Internet Bank.2. Het openen van een rekening bij de Internet Bank inclusief het verstrekken van de credit card en

afsluiten van de reisverzekering.3. De acties die een klant kan uitvoeren en het maandelijks vertrekken van een overzicht. Deze acties

bestaan uit: - kopen van een verzekeringsproduct of aanvullende dienst;- geldhandelingen (betalen met de credit card of geld overmaken);- het (ver)kopen van aandelen;- het melden van schade;- het (de)blokkeren van een rekening;

4. Het beëindigen van een rekening.

Dit als volgt in beeld te brengen:

Figuur 3: Bedrijfsprocessen Internet Bank

De Internet Bank is een startend bedrijf. Het is gericht op groei van de klantenkring, zonder dat de omvang van haar organisatie evenredig meegroeit. Er wordt naar gestreefd om de groei van het aantal

11

administreren

(logboek)

Verstrekken credit card

en polis

Informatie verstrekken rekening

openenklant actiesafhandelen

Vervaardigenoverzichten

rekening sluiten

klanten geheel te kunnen bijhouden door de inzet van elektronische hulpmiddelen. Ofwel, de Internet Bank streeft ernaar om haar bedrijfsprocessen zoveel mogelijk te automatiseren. Op dit moment is dat op sommige punten nog niet mogelijk. Zo is bij het openen van een rekening of het opnemen van een krediet wettelijk nog een handtekening nodig. Zodra hiervoor een digitale handtekening in aanmerking komt, wordt dit geprefereerd.

Eens per maand ontvangt elke klant een papieren afschrift van de handelingen. Dit bevat dezelfde gegevens die op elk moment on-line en actueel te raadplegen zijn en dient enkel ter controle.

Gewenste mate van ondersteuning van de bedrijfsprocessenAlgemeen: zeer hoge efficiency gewenst.Met name automatisering van: verstrekken productinformatie, producten kopen, wijzigen wachtwoord.In mindere mate: rekening openen (handtekening controleren), rekening sluiten.

Ambitieniveau van de verschillende organisatieonderdelenGrote klantengroei wordt verwacht, op basis van marktonderzoek.De hoogste omzet komt naar verwachting van geldzaken (consumptief krediet, handel in aandelen).Minder omzet wordt verwacht van verzekeringen.

Toekomstperspectief dat ICT biedtVerregaande automatisering, vooral leidend zijn en blijven bij het gebruik van nieuwe mogelijkheden. De ‘fun’-factor is belangrijk voor de primaire doelgroep bij de keuze voor de Internet Bank.

En in de toekomst wellicht: Betere authenticatie. Controleren handtekening automatisch (OCR). Misschien digitale

handtekening in plaats van papieren versie voor het openen van een rekening of het deblokkeren van een rekening.

Via internet chatten met medewerkers als aanvulling op telefoongesprek en e-mail. Een virtueel kantoor bieden op internet door video-conferencing als aanvulling op

telefoongesprekken.

Verschil huidige en gewenste situatieMomenteel bestaat de Internet bank nog niet. Er hoeft dan ook geen rekening gehouden te worden met bestaande bedrijfsprocessen. Wel moet rekening gehouden worden met de leveranciers, hier een ‘echte’ bank die voor ons de verbinding vormt met de andere banken voor betalingen en het beleggen regelt, en een verzekeringsmaatschappij.

Afspraken met leveranciersMet de leveranciers moeten goede afspraken worden gemaakt. Zo kunnen er onderling eisen worden gesteld aan de betrouwbaarheid en snelheid van gegevens opvraag. Daarnaast kan het gewenst zijn dat de Internet Bank inzicht heeft in de voortgang van de afhandeling van, bijvoorbeeld, een verzekering als een klant aanklopt. Dit mede omdat men een transparant doorgeefluik wil zijn: de klant weet niet wie de verzekeringen werkelijk verzorgd.

Informatie-architectuurDe volgende distributiekanalen worden gehanteerd door de Internet Bank:

12

Internet Telefoon

E-mail Post

13

Er wordt onderscheid gemaakt naar interne en externe informatiebronnen. Intern worden de volgende gegevens beheerd:Klantgegevens: Naam en adresgegevens (waaronder telefoonnummer en e-mail, wachtwoord)Productafnamegegevens: Afgenomen producten en diensten (rekeningnummer(s), polisnummer(s), credit card nummer) Een logboek van alle transacties

De volgende externe informatiebronnen zijn onderscheiden: BKR, voor toetsing van de kredietwaardigheid van nieuwe klanten Bankgegevens, over (actueel saldo, geldhandelingen, aandelenportefeuille) Verzekeringsgegevens (polisinformatie en schadegegevens)

De volgende globale informatiediensten zijn te onderscheiden: Opsturen van een informatiepakket en openen van een rekening Administratieve handelingen (adreswijziging, wachtwoord wijzigen, (de)blokkeren) Geldhandelingen uitvoeren (ver)kopen van aandelen Verzekeringshandelingen (schade melden, afhandeling schade volgen) Overzicht verstrekken (ad-hoc, als dienst of het maandelijkse overzicht) Beëindigen van een rekening

De aard van de informatiediensten is verschillend, de volgende dienen interactief te zijn (worden direct afgehandeld): Het blokkeren van een rekening; Uitvoeren van geldhandelingen; Informeren naar de voortgang van schade-afhandeling; Het verstrekken van on-line overzichtenDe overige informatiediensten kunnen in batch worden uitgevoerd.

Om de hiervoor genoemde informatie-diensten te kunnen ondersteunen, met gegevens uit de informatiebronnen dienen de informatiestromen bij elk bedrijfsproces in kaart gebracht te worden.

Per informatiestroom wordt vervolgens geanalyseerd welke gegevens uitgewisseld worden en wat de aard van de gegevens-uitwisseling is (on-line of batch).

Applicatie-architectuurAan de hand van de gegevensverzamelingen en informatiediensten uit de informatie-architectuur worden de volgende applicaties onderscheiden: Een applicatie met alle klantgegevens; Een applicatie met alle productafnamegegevens;

Figuur 3: Informatiestromen bij het openen van een rekening

14

Een applicatie voor het bundelen van productgegevens en andere uitvoer voor batch uitvoer; Een uitvoer orgaan (printstraat) die gegevens afdrukt en gereed maakt voor verzending naar de

klant; Een applicatie voor het bundelen van uitgaande gegevens voor bank en/of verzekeraar; Een applicatie voor het opvangen van gebundelde gegevens van bank en/of verzekeraar; Een applicatie voor het real-time doorgeven van opdrachten aan de bank; Een applicatie voor het real-time bekijken van schade-afhandeling gegevens bij de verzekeraar; Een applicatie voor het real-time creëren van overzichten op basis van verzoeken van de klant; Een call-center applicatie; Een applicatie die binnenkomende gegevens doorstuurt naar de juiste applicaties en weet wat er

met gegevens moet gebeuren

Deze applicaties kunnen als volgt in beeld gebracht worden:

Van elke applicatie wordt een globale beschrijving gemaakt met de functionaliteit, gegevens die door de applicatie worden beheerd en services die worden geboden. Zo kan een projectenplan worden opgesteld met de volgorde waarin applicaties worden ontwikkeld en de gevolgen daarvan op de bedrijfsvoering.

Op basis van die beschrijvingen kan ook een verdiepingsslag worden ingegaan om van elke applicatie een globaal ontwerp te maken.

Figuur 3: Applicatie-architectuur Internet Bank

15

LiteratureHead, Robert, Datamation, edition 13, nr 5, May 1967, pages 22-28

Martin, J., Information engineering: a trilogy, Englewood Cliffs, NJ: Prentice-Hall, 1989.

McLean, E.R., Sodan, J.V., Strategic planning for MIS, Wiley, New York, 1977.King, W.R., Strategic planning for management information systems, from: MIS-Quarterly, 2 (1978), nr. 1, pages 27-37.Bushoff, R., Oosterhaven, J.A., Information Strategy Planning, from: Informatie, edition 29, 1987, nr. 3, pages 228-238.Oosterhaven, J.A., Informatiestrategieplanning binnen grote organisaties, from: Uitdaging aan de informatica, Proceedings Informatica Symposium NGI-SION 1985, Amsterdam, 1985, pages 34-38.

Poel, Paul A.M.M. van de, (Philips International B.V. Eindhoven), Waes, Ria M.C. van (Vrije Universiteit Amsterdam, faculteit Economie en Econometrie, Afdeling InformatieSystemen), from: Information System Concepts: An In-depth Analysis, Falkenberg, E.D., Lindgreen, P. (Editors), Elsevier Science Publishers B.V. (North-Holland), Copyright IFIP, 1989.

Rees, ir. J.R. van, en Wisse, P., Informatie-architect en systeem-aannemer: andere rol, andere methode, Informatie, edition 37, nr. 4, April 1995, pages 236-246.

Rees, ir. J.R. van, De regels voor goed vakmanschap, NGGO Lecture, April 23th 1998, www.euronet.nl/~jvr/art1.html

Sanden, drs. W. van der, en Sturm, ir. B., Informatie-architectuur, de infrastructurele aanpak, Panfox, 1997.

Theeuwes, prof. dr. J.A.M., Informatieplanning, 2nd edition, Kluwer, Deventer 1988.

Truijens, J. et al., Informatie-infrastructuur : een instrument voor het management, Kluwer Bedrijfswetenschappen, Deventer, 1990.

Wisse, P., Kritiek op de Pure Methode, uit: Stol, H. et al., Organisatieverandering en informatie-architectuur, Samsom BedrijfsInformatie, 1995.

16