extensible architecture framework (xaf)

Jan L.G. Dietz (ed.)

extensibleArchitectureFramework

(xAF)version 1.1 (formal edition)

OUTLINE

The NAF-program GAFBusiness-ICT problemsDesigningSystems and modelsArchitecture and architecture frameworksThe extensible Architecture Framework (xAF)xAF0: the root xAFConcluding notes

xAF-1.1 fe 4

n The objective of the program is to develop a generic architectureframework (GAF) that is theoretically solid and practically useful.The GAF is generic in the next senses:• The concepts in the framework constitute a complete set, i.e. they

are necessary and sufficient for carrying out projects successfully.• The framework is widely applicable, i.e. within the whole area of

enterprise engineering (business definition, business processes, ICT-applications, organization etc.).

• The definition of each concept leaves space for customization withinany (sub)field. The GAF should not be a rigid standard.

n The plan is to present at the LAC 2004 the final version of the GAFand to have it accepted as the NAF-standard for dealing witharchitectures and architecture frameworks.

Objectives of the NAF-program GAF

xAF-1.1 fe 5

n Although architecture enjoys an enormous and ever increasingattention, it is not always correctly understood and applied. Next,there exists a cluttered and large number of presumed distinctarchitectures, frameworks and architects. These observations havegiven rise to the next motivation for the NAF-program:• The GAF could encourage the correct usage of architecture as well as

improve the quality of architecture frameworks.• The GAF could be a unifying frame of reference for all kinds of

educational curricula and courses, at all levels (MBO, HBO, UNI).• The GAF could be the basis for a sensible distinction of professions in

the field (definition), and for degrees of professionalism (certification).

Motivations for the NAF-program GAF

xAF-1.1 fe 6

The xAF working group

n Frank Baldinger (ING)n Jeroen van Beele (Wehkamp)n Frits Broekema (CGEY)n Wiel Bruls (IBM)n André van Dalen (Siemens)n Jan Dietz (TUD) - chairmann Henk Gingnagel (Pink Roccade)n Hans Goedvolk (CGEY)n Guus van der Harst (MinJus)n Bart-Jan Hommes (TUD)n Jan Hoogervorst (KLM)n Michel Jansen (ABN/Amro)n Olaf Kruidhof (CGEY)n Martin op ‘t Land (CGEY)n Henk Lof (Hooge Huys)

n Paul Mallens (MinLNV)n Wouter Mellink (KLM)n Karin Middeljans (RWS)n Erik Proper (RUN)n Roelof Rabbers (KPN)n Louis Stevens (Ordina)n Leon van der Torre (CWI)n Wim Verbeek (Aquila)n Rob Vreke (IBM)

OUTLINE


xAF-1.1 fe 8

Mastering complexity

n Architecture is a notion that could be (and is anyway hoped to be!)helpful in mastering the complexity of Business-ICT problems.

n Mastering complexity is performed in our mind. It requires:• Unorthodox and creative thinking, yielding powerful and innovative

concepts.• Providing rigorous and precise definitions of these concepts.

n Rigorous and precise reasoning is supported by logic andmathematics. Lateral thinking may be helpful in finding innovativeideas. (De Bono, Einstein, Ockam).

n The importance of the notion of architecture for solving Business &ICT problems is comparable to the importance of the notion ofenergy in solving mechanical problems.

xAF-1.1 fe 9

n The benefits of designing objects ‘under architecture’ are, amongother things, improved performance in the next aspects:• Integration; objects can more easily be coupled or merged.

Conversely, they can more easily be split. This holds both for objectsof the same kind and for objects of different kinds.

• Adaptability; changes to the object can more readily be made.• Agility (this holds in particular for organizations); the ability of objects

to respond swiftly to new demands is improved.• Understanding; designs can more readily be understood by and

communicated among the stakeholders.• Utilization; people will be more willing to use an object since its

function is more readily recognized.• Engineering; engineers will more likely use design and engineering

patterns then before, which reduces development costs and time.

Why architecture?

OUTLINE


xAF-1.1 fe 11

n The designing of a system (an organization, a clock, a car, or an ICT-application) essentially consists of two things:• Determining the requirements. The result is a balanced compromise

between all stakeholders’ requirements.• Devising the specifications. These specifications should satisfy the

resulting requirements and should be feasible. By feasible is meant thatthe specifications are sufficient for building the system, using theavailable technology.

What is designing?

xAF-1.1 fe 12

n Requirements can usefully be divided into two kinds:• General requirements; these hold for a class of systems. They

consist of policies, guidelines, standards, preconditions etc.• Special requirements; these hold for a particular system (an

instance of some class). They consist of what is usuallyunderstood by requirements.

Kinds of requirements (1)

xAF-1.1 fe 13

general special

functional

constructional

• accounting shouldbe in conformitywith European law

• the max speed ofcars should be atleast 80 km/hr

• this accountingsystem shouldhandle $ and €

• the max speed ofthis car should be180 km/hr

• ICT-applicationsshould becomponent based

• in cars, minimal25% of the materialshould be synthetic

• this system mustbe programmed inC++

• the body of thiscar should be fullysynthetic

Kinds of requirements (2)

xAF-1.1 fe 14

In the design of a target system (TS) that supportsa using system (US), the next steps are taken:

1. Determining the requirements for the TS, such that the TS will offerthe desired support to the US.

2. Devising the specifications of the TS from these requirements.

(resulting)requirements specifications

devisingspecifications

determiningrequirements

generalrequirements

specialrequirements iteration

The design process (1)

OUTLINE


xAF-1.1 fe 16

The teleological system concept

n Is about the function and behavior of a systemn Reflects the purpose of a systemn Is the dominant system concept in both the natural and the social

sciencesn Is perfectly adequate for using and controlling systemsn Has the black-box model as the corresponding kind of model

xAF-1.1 fe 17

the driver's perspective

function :(mathematical) relationshipbetween input and output

behavior :the manifestation of thefunction in the course of time

car

lightingsystem

powersystem

steeringsystem

brakesystem

functional decomposition

The black-box model

xAF-1.1 fe 18

The ontological system concept

n Is about the construction and operation of a systemn Is indifferent to the purpose of a systemn Is the dominant system concept in the engineering sciencesn Is perfectly adequate for building and changing systemsn Has the white-box model as the corresponding kind of model

xAF-1.1 fe 19

n Anything that has the next properties is called a (homogeneous)system:

• Composition: a set of elements of a category C.• Environment: a set of elements of C.• Production: the elements in the composition produce things (products or

services) that are delivered to the elements in the environment.• Structure: a set of interaction bonds among the elements in the

composition and between these and the elements in the environment.

The ontological system definition

xAF-1.1 fe 20

Depiction of a homogeneous system

xAF-1.1 fe 21

the mechanic's perspective

construction :(active) elements and theirinteraction relationships

operation :the manifestation of theconstruction in the course of time

car

chassis wheels motor lamps

constructional composition

The white-box model

xAF-1.1 fe 22

A vase or two faces? [Rubin]

xAF-1.1 fe 23

Heterogeneous systems

n A system is homogeneous if its elements belong to one category (e.g.physical or biological or social). The elements are called atomic withrespect to the category.

n Homogeneous systems can be integrated in a heterogeneous system.This is possible if the (atomic) elements of the distinct homogeneoussystems are somehow inseparably connected. For example: a humanbeing is inseparably a social, an intellectual, and a physical individual(element).

OUTLINE


xAF-1.1 fe 25

n In general, the design freedom of designers is undesirable large. Theidea of architecture is to take advantage of this. Therefore,architecture is defined as normative restriction of design freedom.

n This idea of consciously applying normative restriction of designfreedom is the really new thing. It makes architecture a prescriptivenotion; any descriptive interpretation is cogently rejected.

n This notion of architecture is in contrast with the one that is used inthe construction of buildings (“bouwkunde”). There, architecture ishardly distinguished from design.

n Practically, architecture is a consistent and coherent set of designprinciples that embody general requirements. Applying a designprinciple satisfies one or more general requirements.

What is architecture?

xAF-1.1 fe 26

n As a support for devising architectures, it is convenient to have astructured checklist of issues that must be paid attention to or thatmust be taken into account. Such a structured checklist is called anarchitecture framework.

n Formally, an architecture framework (AF for short) can be definedas a tuple <O,D,A> where:• O is a set of object types.• D is a set of design domains.• A is a set of areas of concern.

n O, D and A may be interpreted as three dimensions. There is noguarantee, however, that they are orthogonal.

What is an Architecture Framework? (1)

xAF-1.1 fe 27

n An object type determines a class of objects for which an AF ismeant. Examples: churches, computer networks, organizations.

n Domains are distinctions that are inherent to the object type(s) dueto the (possibly unwittingly) applied paradigm. Ideally, domains areindependent of each other. Examples: function and construction.

n The general requirements, put in by the stakeholders, are grouped indistinct areas of concern. Examples: security and maintainability.

n An architecture can now be defined more formally as follows:• An architecture is a set P of design principles, conforming with some AF.• P concerns one object type o ∈ O.• Every p ∈ P is a restriction of design freedom in one domain d ∈ D.• Every p ∈ P originates from one or more areas a ∈ A.

What is an Architecture Framework? (2)

OUTLINE


xAF-1.1 fe 29

The extensible Architecture Framework

n The formal definition of an AF suggests that it must be feasible todefine an AF as an extension of one or more existing AF’s, whilebeing also extensible itself. This would offer the desirable option to(sensibly) compare and evaluate existing frameworks.

n To realize this idea of an extensible Architecture Framework (xAF),two things are needed:• A generic architecture framework that serves as the universal root xAF

of all other xAF’s. It is called xAF0.• Extension rules for defining xAF’s as extensions of the xAF0.

n The extension rules through which a new xAF can be defined onthe basis of one or more other xAF’s are: specialization andintegration. These rules guarantee compliance of a newarchitecture with its direct parent(s) and thus with the xAF0.

xAF-1.1 fe 30

The specialization rule

n An xAFj, defined as <Oj,Dj,Aj> is a specialization of an xAFi, definedas <Oi,Di,Ai> if and only if:• Every object type o ∈ Oj is an exclusive subtype of some o’ ∈ Oi.

• Dj is a superset of Di.• Aj is a superset of Ai.• xAFj is a valid xAF.

n Note. The notion of superset as used above is the inverse of thecommon notion of subset (symbol ⊆), not the strict or proper one(symbol ⊂). So, the compared sets may be identical.

n Example: an xAF for organizations as specialization of an xAF forsystems in general.

xAF-1.1 fe 31

The integration rule

n An xAFn, defined as <OO,DD,AA> is an integration of a set of xAF’s,defined as {<O1,D1,A1>,<O2,D2,A2>, ... ,<Ok,Dk,Ak>}, if and only if:•• OO is the integral union of O1, O2, ... , Ok.•• DD is the integral union of D1, D2, ... , Dk.•• AA is the integral union of A1, A2, ... , Ak.• xAFn is a valid xAF.

n Note. By integral union is meant that the elements of the united setare rigorously related to each other, not just ‘talked together’.Otherwise one should call it only an aggregation.

n Example: devising an enterprise AF as the integration of severalcomponent AF’s, like an organization AF, an information system AFand an ICT-infrastructure AF.

xAF-1.1 fe 32

The xAF lattice

n Extending the xAF0 yields a top-down directed lattice of xAF’s. Thefigure below shows an example lattice:• A straight line represents specialization; e.g. xAFj is a specialization of

xAFi.• A bundle of dotted lines represents integration; e.g. xAFn is the

integration of xAF1, xAF2 and xAF3.

xAFn

xAF1 xAF2 xAF3

xAF0

xAFi

xAFj

OUTLINE


xAF-1.1 fe 34

xAF0 - the object type

n The object type in the xAF0 is the generic homogeneous system.Formally, a homogeneous system can be defined as a tuple<A,C,E,P,S> where:• A is the class of atomic elements of the system category.• C ⊂ A, called the composition.• E ⊂ A, called the environment. E and C are disjoint.• P is a set of products. Products are things that can be produced by the

elements in C and transferred to elements in E.• S, called the structure, is a set of influencing bonds among the

elements in C and E. By virtue of these bonds, the elements are able toact upon each other. In doing so, they evoke the creation and transferof products.

n C, E and S are collectively called the construction of a system.

n The collective activity of the elements of C and E is called theoperation of a system.

xAF-1.1 fe 35

xAF0 - the function domain

n Two domains are identified in the xAF0: the function domain andthe construction domain. In the function domain one is concernedwith both the function and the behavior of a target system (TS),thus the provision of services, including performance issues. Ablack-box model of the TS is used.

n On the basis of a white-box model of the using system (US), oneacquires the special requirements for the design of the TS. Theycome in addition to the general requirements, as reflected alreadyin the applied architecture. Requirements are expressed in terms ofthe US.

n Often a distinction is made between functional requirements andconstructional requirements. Functional requirements are about thefunctionality of the TS, i.e. the distinct services it must provide.Constructional requirements are about quality (e.g. performance)characteristics with which the services are provided.

xAF-1.1 fe 36

xAF0 - the construction domain

n In the construction domain one is concerned with both theconstruction and the operation of the TS, in particular how theelements in C collaborate to deliver services to the elements in E.A white-box model of the TS is used.

n The pertaining knowledge is expressed in specifications. Theyspecify the internal construction and operation of the TS, i.e. thecreation of products and the interactions between the elements inC for providing the corresponding (internal) services, as well as theexternal construction and operation, i.e. the interactions betweenE and C for the provision of services.

n Often a distinction is made between functional specifications andconstructional specifications. Functional specifications are aboutthe external construction and operation of the TS. Constructionalspecifications regard the internal construction and operation.

xAF-1.1 fe 37

xAF0 - the areas of concern

n The set A of areas of concern in the xAF0 is empty. This only meansthat there are no universal areas of concern.

xAF-1.1 fe 38

n The general requirements are embodied in a set of design principles, thus in anarchitecture. These principles apply to the devising of the specifications.

specialrequirements specifications

devisingspecifications

determiningspecial

requirements

black-box model of the TS

white-box model of the US

white-box model of the TS

generalrequirements architecture

iteration

The design process (2)

OUTLINE


xAF-1.1 fe 40

Concluding notes

n The presented framework xAF has a well-defined scientificfoundation (although not completely presented here). Architecturescreated within an xAF can be verified and validated.

n xAF0 is a candidate generic AF for dealing with enterprises and ICT-systems. Current frameworks should be definable as extensions ofthe xAF0. This is at the same time a quality criterion.

n Important next steps to take are:• Assessment of the practicality of the xAF by validating current

frameworks in it.• Design of a (formal) language for specifying architectures.• Development of an xAF/MS.

extensible architecture framework (xaf)

Documents