• English
  • Nederlands
HOME
SEARCH
CONTACT
NEWSLETTER
 
 
 
CONTENT
About us
About NAF
Contributions
Call for contribution
The CIO speaks
The Architect answers
The Business decides
Proceedings
Blogs
Master thesis
Events calendar
Links
Login/Register
THEMES
Effect of architecture
SOA
BPM
Methods
Principles
Financial services
Public sector
Health sector
advertisements
Zoek je een baan?
Zoek je hulp?
Zoek je een opleiding?
Zoek je een tool?


Logica
logo_5fsap.jpg 

 
 
ANNOUNCEMENTS
Using ArchiMate with TOGAF (2)
Graham Berrisford and Marc Lankhorst   
Wednesday, 12 August 2009

Part 2: Aligning the entities they use to document architecture

Introduction

We started talking with the idea we should minimise ambiguity in our students’ minds about when and where they should use the ArchiMate box symbols to represent those architecture entities that are named in an architecture method (be it TOGAF or any other method).

    This paper is the fourth in a series, edited from our conversation over several months, in which we explore the possibilities of using the ArchiMate language with an architecture method, and in particular with TOGAF. The series consists of the following papers:

  • [1]: ArchiMate is not just a set of box and line symbols, it has a meta model and philosophy that may or may not match those of any given architecture method. The first paper provides a kind of method maturity model, which you can use to assess the suitability of your architecture method for use with the ArchiMate language.

  • [2]: The second paper applies the model in the first paper to an example architecture method. It shows that TOGAF supports some ArchiMate distinctions more clearly than others. And that the two approaches feature different kinds of “realisation” transformation.

  • [3]: The third paper shows that ArchiMate draws a structure-behaviour dividing line in a different place from the ISEB reference model and from the TOGAF meta model. It also explores how people use the term Function loosely and generically where the terms Service, Process, Interface and Component could be used more precisely.

  • This paper: Using ArchiMate box shapes to draw diagrams is trivial; it does not mean you are using your chosen architecture method in accord with ArchiMate’s meta model and philosophy. This fourth paper provides the kind of careful entity-by-entity analysis that is needed if you want to use ArchiMate to support your chosen architecture method. Again, TOGAF is the chosen example.

In this paper, we investigate the mapping between ArchiMate’s concepts and TOGAF’s implicit and explicit meta models along the following lines. First, we ask whether TOGAF’s meta model aligns with ArchiMate’s. We investigate the generic, meta meta level of both and go deeper into the business architecture, data architecture, applications architecture and technology architecture as prescribed by TOGAF, to see whether we can express the required TOGAF notions in ArchiMate. We conclude with recommendations to the designers of both ArchiMate and TOGAF.

Classification of architectural entities

This section uses a tabular framework to introduce the ArchiMate and TOGAF entities. The tabular framework is only a presentation device. ArchiMate does not subdivide the active structure into logical and physical; that subdivision is an artificial device we have introduced to make comparison with TOGAF easier.

The first table shows the ArchiMate’s architectural entities we are going to discuss.

Passive structure Behaviour Logical active structure Physical active structure
Business
Product      
Contract Business Service   Business Interface
Business Object Business Process / Function Role Actor
Applications
  Application Service   Application Interface
Data Object Application Function   Application Component
Infrastructure
  Infrastructure Service   Infrastructure Interface
Artifact   Node Device | Sys Software
      Communication Path
      Network

The second table shows the TOGAF architectural entities we are going to discuss. Notice the emphasis on defining logical components.

Passive structure Behaviour Logical active structure Physical active structure
Precursors
Driver      
Goal, Objective      
Measure Service Quality    
Business
Contract Service Capability  
Product Process Function Organization Unit
Location Control Role Actor
Data
Data Entity Event Logical Data Component Physical Data Component
Applications
  Information system service Logical Application Component Physical Application Component
Technology
  Platform Service Logical Technology Component Physical Technology Component

Does TOGAF’s meta model align with ArchiMate’s?

Marc: Does the TOGAF meta model align with ArchiMate’s?

Graham: Hmm… You cannot fully understand TOGAF by studying its explicit meta model. As a new arrival in TOGAF 9 (derived from the meta model in SAP’s EAF) it does not yet fully match the implicit meta model in the TOGAF text.

Marc: The Open Group Architecture Forum has to address its own challenges. Some politics are reflected in TOGAF’s internal inconsistencies. Convergence of explicit and implicit meta models is a challenge the Architecture Forum needs to resolve, ideally before convergence with ArchiMate.

However, the explicit TOGAF meta model doesn’t look too far removed from ArchiMate’s meta model. The table below gives us a starting point.

First-cut entity mapping table (needing further research)
Archimate Entities TOGAF Entities
Generic (meta meta) level
Service Interface Service Contract
Behaviour element Function
Process
Structure element Function
Business architecture
Actor Actor
Organisation unit
Role Actor Role
Business Function Function
Capability
Product
Business Object		 Product
Contract Contract
Business Service
Business Interface		 Business Service
Data architecture
Data Object Data Entity
Logical Data Component
Physical Data Component
Application architecture
Application Component Application Component
Logical Application Component
Physical Application Component
Application Service
Application Interface		 Information System Service
Infrastructure or Technology architecture
Node Technology Component
Logical Technology Component
Device
System Software Artifact 		Physical Technology Component
Infrastructure Service
Infrastructure Interface		 Platform Service

Graham: The table is still superficial. There are two challenges here.

  • First, the table compares only meta models. It relies on the new TOGAF meta model definitions. But to the TOGAF practitioner, it is not always clear how ADM artifacts and outputs are constructed using the entities in this new meta model.

  • Second, some of the mappings are questionable. Mappings that look obvious at first glance may disintegrate on closer inspection. We need to do a thorough entity-by-entity comparison, comparing the entities’ definitions, attributes and relationships. And at the same time consider effect of recursive decomposition on the entity definitions.

I have posted some slides that offer a more visual comparison of the meta models at [7]. We should now go on to do a more detailed analysis, comparing entities in the two meta models, in the next sections.

Preliminary remarks

Entity definitions and attributes

Graham: TOGAF offers definitions for all 35 of its entities. TOGAF does list attributes for entities, but most of them are generic attributes and not very descriptive of a particular entity. Two of the entities, Contract and Physical Application, do have really substantial attribute lists it is worth looking up.

Marc: ArchiMate offers definitions for all of its 30 entities. ArchiMate does not list attributes for these entities, but includes a mechanism for assigning your own attributes to them.

Entity decomposition

Graham: Some (curiously not all) TOGAF entities can be hierarchically composed and decomposed. The obvious examples are function and process. Does ArchiMate allow entities to be composted and decomposed to any number of levels?

Marc: Yes. Any ArchiMate entity can be subdivided into sub-entities of the same type, ad infinitum.

Graham: Decomposition of entity types often undermines relationships that are implied in text definitions of the entities. E.g. consider that:

  • ArchiMate appears to map one function to one role.

  • TOGAF appears to map one business service to one application component.

These mappings cannot hold true between entities at different levels of recursive decomposition. And they are true at one level only if our method makes us force fit one concept to the other.

Architecture precursors

Marc: ArchiMate lacks modelling concepts for goals, objectives and requirements. We initially decided to leave these out of the modelling language, because we observed that people tended to describe these in natural language and not in models. But I expect that concepts for these will be added to a next version of the language, and preliminary ideas on this are already being formed. See also the remark on Reason below.

Graham: An architecture language without business goals is not really an enterprise architecture language. I think it is fair to say TOGAF captures architecture requirements at four levels of elaboration:

  • business/IT goals

  • business/IT objectives (with KPIs)

  • architecture requirements (with measures)

  • logical architecture building blocks (with non-functional qualities)

ArchiMate-only concepts

Graham: I notice ArchiMate includes the entities Meaning, Value, Interaction and Collaboration, which don't resemble TOGAF entities.

Marc: Indeed. The first two, Meaning and Value, are used to capture semantics. Meaning refers to the knowledge or expertise contained in (the representation of) a business object. You might call that “business semantics”. It can be used as a ‘hook’ for inclusion of more semantics-based modelling and reasoning, which is certainly a consideration for future extensions of the language. Value is that which makes some party appreciate a service or product, possibly in relation to providing it, but more typically to acquiring it. It helps in linking ArchiMate to techniques for modelling value networks and business models.

Next to Meaning and Value, there is a third ‘semantic’ concept hidden in the meta structure, which is not available to language users: Reason. This is intended as a generic, meta level basis for requirements modelling concepts, which can be defined as specialisations of Reason. As said, at the time we found that people tended to use natural language and not models for describing requirements, but in hindsight, we should perhaps have made these concepts available from the start.

Interaction and Collaboration are a pair of concepts to model cooperative structures. A Collaboration groups Roles that work together, and an Interaction is used to model what they do together. With these, you can model cooperation in a more symmetrical fashion than with services (which are of course inherently bound to a provider-consumer view of the world). This is for example useful in high-level models of the context of an organisation.

Generic schema (meta meta model)

Graham: TOGAF does not have a meta meta model, but we can draw some loose correspondences between ArchiMate’s higher-level meta entities and TOGAF’s entities.

Service and Interface

ArchiMate’s Service TOGAF’s Service
Service
A unit of essential functionality that a system exposes to its environment, which provides a certain value (monetary or otherwise), which thus provides the motivation for the service’s existence.		 An element of behaviour that provides specific functionality in response to requests from actors or other services.
A service delivers or supports business capabilities, has an explicitly defined interface, and is explicitly governed.
Services are defined for business, information systems, and platforms.
TOGAF’s Contract
An agreement between a service consumer and a service provider that establishes functional and non-functional parameters for interaction.
ArchiMate’s Interface  
Abstract location where a Service can be accessed by its users.  

Marc: It looks like a TOGAF Business Service somehow combines ArchiMate’s Business Service and Business Interface. Perhaps a TOGAF Contract is more related to Service than Interface.

Graham: The separations of and relationships between Service, Interface and Contract are unclear. There is potential confusion between levels of granularity, and between process and system. A TOGAF Service appears to be a fine-grained elementary service (the result of a single process invocation). But a TOGAF Contract’s attributes could describe an elementary service and/or a service level agreement for whole system or subsystem.

Marc: You could certainly put all of the Contract attributes in a SLA for whole system, but to check conformance to that SLA, you would also need to record some of these same attributes for each single invokable elementary service.

An ArchiMate service may be offered through various interfaces, and vice versa, the same interface may offer different services. An ArchiMate Interface is basically an "access point" for a service. At the business layer, this includes e.g. the telephone, post, email, web, etc.. All can be used for accessing services (and/or products) from the enterprise. At the application level, we might have on the one hand user interfaces of software systems, and on the other hand machine-to-machine interfaces (e.g. web service stuff). At the infrastructure level, you'll have lower-level software or hardware interfaces.

Graham: It seems to me both ArchiMate and TOGAF ought to separate as many as six concepts in this area:

1. Data flow: A transient data store passed from a "sender" component to one or more "receiver" components, which contains some data. E.g. a serial file, a message, a text document.

2. Data flow content (cf. an ArchiMate object): A data structure definable separately from the data flow that contains it. Definable as a regular expression, perhaps using an XML schema. E.g. a data entity or aggregate of data entities.

3. Interface (in the ISEB sense): An aggregate of services assignable to one or more "server" components for use by one more "client" components.

4. Channel (cf. an ArchiMate Communication Path): Used to transmit a data flow (1) or make a client-server connection (3). E.g. telephone, HCI, internet, private network.

5. Protocol: One or more layers of protocols needed to send a data flow (1) or invoke services (3) via a channel (4).

6: Location: an end point for a Data Flow or Channel.

Behaviour and structure

ArchiMate’s Behaviour Element TOGAF’s Function
Unit of internal behaviour that can be composed of other Behaviour Elements and realise Services. Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization. Also referred to as ‘‘business function’’.
TOGAF’s Business Process
A process represents flow of control between or within functions and/or services (depends on the granularity of definition).
ArchiMate’s Structure Element TOGAF’s Function
Basic unit of active structure that can perform the Behaviour Elements assigned to it and provide interfaces to the Services these Behaviour Elements realise. (As above)
ArchiMate’s Object  
Basic element on which behaviour is performed.  

Marc: ArchiMate uses a meta meta entity "Behaviour Element” to abstract from the various meanings people give to “Function”. Similarly "Structure Element” abstracts from meanings associated with “Component“.

Graham: It would of course be a circular argument to justify a structure-behaviour distinction by reference to meta meta entities we have created to match the distinction we draw. If our aim is reduce practitioners' confusion between the different kinds of function that they are thinking of and working with, then talking about even more abstract super types doesn't feel like a promising path! The fundamental system modelling distinction I miss in ArchiMate is the process/component (or procedure/subsystem) distinction.

I think we can say all of these are “behaviour executors”:

  • Subsystems
  • Components
  • Roles
  • Actors

Marc: In ArchiMate’s meta meta model, they are subtypes of the Structure Element.

Graham: I’m never entirely comfortable about such abstract supertypes. You might say Role and Actor are the most generic concepts, so then a component type is a role and a component instance is an actor. Or you might say Component type and instance are the most generic concepts. So then a role is a component type and an actor is a component instance.

To avoid heading down a path in which every concept is a subtype of another, we have to select only those supertypes which are most fundamental to the process of analysis and design; the ones we need to teach people about. I think the orthogonal relationship between process and component is fundamental to the process of analysis and design.

[See [3] for more discussion.]

Business architecture

Actors and Roles

ArchiMate’s Actor TOGAF’s Actor
Organizational entity capable of performing behaviour. A person, organization, or system that has a role that initiates or interacts with activities; for example, a sales representative who travels to visit customers. Actors may be internal or external to an organization.
OR TOGAF’s Organisation unit
A self-contained unit of resources with line management responsibility, goals, objectives, and measures. Organizations may include external par ties and business partner organizations.
ArchiMate’s Role TOGAF’s Role
A named specific behaviour of a business actor participating in a particular context. The usual or expected function of an actor, or the part somebody or something plays in a particular action or event. An actor may have a number of roles.

Marc: A Business Process can be assigned to a Role; similarly, a Role can be assigned to an Actor. A job title (Clerk) is a Role. A person (Smith) is an Actor who plays the Role. Several people can be appointed to the same job title.

Graham: The distinction is less clear in TOGAF. A TOGAF Actor has an attribute recording the number of FTEs that operate as that actor, which makes Actor sound like Role.

In any case, the Actor-Role distinction is unclear when there is only one actor for a role. E.g. is the BACS clearing system an actor, a role or both?

And in practice people commonly draw diagrams using the Actor symbol in place of Role, because they prefer the stick man symbol!

Marc: Actor being “external to an organisation” is odd, since the organisational entities are of course within the consideration of the enterprise architecture.

Graham: Just one more place where decomposition of entities destroys the meaning of an entity’s definition! Traditionally actors are “external entities” outside the boundary of the system we model. TOGAF treats the enterprise as a system. Therefore, the actors are outside that the boundary. But the definition doesn’t account for the fact that systems are nested. Obviously, applications are systems within the enterprise boundary. So some actors appear in the enterprise, but outside the applications.

Functions, Processes and Business Services

ArchiMate’s Function TOGAF’s Function (aka Business Function)
Unit of internal behaviour that groups behaviour according to e.g. required skills, knowledge, resources, etc., and can be performed by a single role. Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization. Also referred to as ‘‘business function’’.
TOGAF’s Capability
A business-focused outcome that is delivered by the completion of one or more work packages. Using a capability-based planning, change activities can be sequenced and grouped in order to provide continuous and incremental business value.
TOGAF’s Process
A process represents flow of control between or within functions and/or services (depends on the granularity of definition).
ArchiMate’s Organisation Service TOGAF’s Business Service
Externally visible functionality, meaningful to the environment and realized by business behaviour (process, function, interaction). Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.

Graham: Notice a TOGAF Service is governed by an organisation unit. The meta model maps services also to functions. We discussed functions at great length in our previous paper. I think term Business Function means much the same in ArchiMate and TOGAF. But ArchiMate use the term Function outside of that, embracing what the TOGAF meta model calls Process.

Marc: Function is indeed one of the most troublesome concepts. And how does it relate to a TOGAF Capability?

Graham: The TOGAF meta model does not relate Function to Capability. Yet they are well-nigh indistinguishable. A Capability “is a” Function, a high-level business function. TOGAF 9’s new chapter on Capability-Based Planning is not well integrated with other chapters in which capability means other things: e.g. A capability architecture is a project-level solution architecture.

I have posted some slides “What is a Function” at [7]. They relate Function to Capability to Organisation Unit to Service in the ways I infer from TOGAF.

Products and Contracts

ArchiMate’s Product TOGAF’s Product
a coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers. Output generated by the business. The business product of the execution of a process.
AND/OR ArchiMate’s Business Object
a unit of information that has relevance from a business perspective.
ArchiMate’s Contract TOGAF’s Contract
specification of an agreement that specifies the rights and obligations associated with a product. An agreement between a service consumer and a service provider that establishes functional and non-functional parameters for interaction.

Graham: One Contract is for a product; the other is for a Service. 

Marc: True, but an ArchiMate product consisting of a single service would do the same thing.

Graham: I am unclear in this area. I don’t understand what our two standards mean to say about the multiplicity of association relationships between Service, Interface, and Contract, and about how they relate to all the other entities they might be attached to.

Marc: ArchiMate is not very strict about multiplicity, to grant architects some leeway in its use.

Graham: I suggested earlier that we might do better to separate as many as six concepts in the area of “Interfaces”.

Data architecture

ArchiMate’s Data Object TOGAF’s Data Entity
A coherent, self-contained piece of information, e.g. customer record An encapsulation of data that is recognized by a business domain expert as a thing. Logical data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations.
TOGAF’s Logical Data Component
A boundary zone that encapsulates related data entities to form a logical location to be held; for example, external procurement information.
TOGAF’s Physical Data Component
A boundary zone that encapsulates related data entities to form a physical location to be held. For example, a purchase order business object, comprising purchase order header and item business object nodes.

Marc: ArchiMate uses data objects to model not only entities, but larger data sets and what TOGAF calls Logical Data Components.

Graham: Data sets and data components seem different to me. A TOGAF data entity covers persistent data (in a data store) and transient data (in a data flow). It defines data content rather than a data container.

I think a TOGAF data component (despite the purchase order example given) is best understood to be data container rather than data content. A data component represents a locatable container of persistent data – to which one or more applications can make a connection. A data component might contain a small data set, perhaps only one entity. The important thing is not the size, but that it exists and is accessible in a location.

Marc: For example, if we are interested in modelling Application Services that provide access to the data, using an Application Component (and perhaps an Application Function) might be called for.

Graham: Yes if there is an Application Component that encapsulates the data store in the baseline architecture, or you want to define one in the target architecture.

I note also that neither ArchiMate nor TOGAF give due prominence to event, data flow or message. But I’d rather leave “event” out for now. I argue that events (in behaviour models) are as important as entities (in structural models), and we always need to model from both perspectives. But once I start on that topic - it will turn into paper 5.

Marc: ArchiMate does have the Business Event concept and the Flow relation. But if we really want to use the power of events, we will also have to look at business rules for processing events. And business rules are neither addressed by ArchiMate nor by TOGAF. Paper 6?

Graham: My interest in entity-event modelling (from 1985 to 1995) was all about how to model business rules. Another time…

Applications architecture

ArchiMate’s Application Component TOGAF’s Application Component
A modular, deployable, and replaceable part of a system that encapsulates its contents and exposes its functionality through a set of interfaces. An encapsulation of application functionality aligned to implementation structure.
TOGAF’s Logical Application Component
An encapsulation of application functionality that is independent of a particular implementation. For example, the classification of all purchase request processing applications implemented in an enterprise.
TOGAF’s Physical Application Component
An application, application module, application service, or other deployable component of functionality. For example, a configured and deployed instance of a Commercial Off-The-Shelf (COTS) Enterprise Resource Planning (ERP) supply chain management application.
ArchiMate’s Application Service TOGAF’s Information System Service
Externally visible unit of functionality of an application component, exposed through well-defined interfaces, and meaningful to the environment. The automated elements of a business service. An information system service may deliver or support part or all of one or more business services.

Graham: ArchiMate speaks of Application Components, Application Services, Application Interfaces and Application Functions.

TOGAF authors discuss related (not identical) architectural entities: Applications (in a portfolio thereof), Application Components (logical and physical), Application Services (aka Information Systems Services) and Application Functionality (ugly plural of Functions). Analysis suggests TOGAF uses Application Function to mean a process (or use case) rather than a component.

Am I allowed to disagree with the TOGAF meta model? I am tempted to do so in several places, and must do it here. It cannot be true in general that the physical application components defined in phases E and F are deployable instances of applications. They are at best application types, rather than instances. And even then, TOGAF tells us the “physical elements in an enterprise architecture may still be considerably abstracted from solution architecture, design, or implementation views”.

Turning to another question: It is all too easy keep a class entertained for 30 minutes discussing the question: What is an application? Do you regard System Software as a kind of Application? 

Marc: No, it is the software infrastructure on which applications run. Typical examples would be operating systems, DMBS’s, messaging middleware, etc.

Graham: Which is Lotus Notes? Internet Explorer?

Marc: There is a trend for applications to become infrastructure over time. I would probably model both as system software.

Graham: OK, though infrastructure architects call all the software they deploy Applications. They also regard non-functional requirements as functional.

Marc: I know. I am not really partial to the term “non-functional”, since it somehow sounds less important - which it isn’t to architects of course.

Technology architecture

ArchiMate’s Node TOGAF’s Technology Component
A computational resource upon which artifacts may be deployed for execution An encapsulation of technology infrastructure that represents a class of technology product or specific technology product.
TOGAF’s Logical Technology Component
An encapsulation of technology infrastructure that is independent of a particular product. A class of technology product
ArchiMate’s Device TOGAF’s Physical Technology Component
Physical computational resource upon which artifacts may be deployed for execution A specific technology infrastructure product or technology infrastructure product instance. For example, a particular product version of a Commercial Off-The-Shelf (COTS) solution, or a specific brand and version of server.
System Software
A software environment for specific types of components and objects that are deployed on it in the form of artifacts
ArchiMate’s Artifact
physical piece of information that is used or produced in a software development process, or by deployment and operation of a system (an executable, passive file, database table, etc.).
ArchiMate’s Infrastructure Service TOGAF’s Platform Service
Externally visible functionality of a node, exposed through well-defined interfaces, and meaningful to the environment. A technical capability required to provide enabling infrastructure that supports the delivery of applications.

Graham: ArchiMate’s Node (similar to the UML Node) is a super type of Device or System Software). But a TOGAF Logical Technology Component is an idealised component of the infrastructure hardware or software, meaning it is logical rather than physical. 

Marc: So why wouldn’t a Logical Technology Component match a Node, which is more abstract than Device and System Software?

Graham: Because it is more abstract in a different way. An ArchiMate node is abstraction by generalisation from two physical specialisations; so it is still physical. A TOGAF logical technology component is an abstraction by idealisation from physical technology components (the relationship could be one logical to one physical).

Marc: A subtle difference, but valid. 

Graham: Whoever manages to align the ArchiMate and TOGAF meta models will have to detect and address such subtle differences.

From Node to Device

Graham: Again, my concern is to minimise ambiguity in my and students’ minds about when and where they should use the ArchiMate box symbols. I’d like to press you about the distinctions between Node, Device, System Software and Application. I gather Node is a platform for applications and data

Marc:  A Node is an abstraction of Device and System Software. It is “a computational resource upon which artifacts may be deployed for execution.”

Graham: There are several kinds of “abstraction” and they are entangled with each other. You’re saying Node is a generalisation of hardware or software platform. So I can use it in place of either specialisation, where I want to avoid being that specific. Are you relaxed about mixing levels of generalisation (Node and Device) in the same diagram?

Marc: I don’t mind mixing both levels. I often draw Nodes composed of one or more Devices on which System Software is deployed. I could always use Node, but I tend use Device where the server hardware is named. A Device is a physical computational resource.

Graham: Ah! You may use Node in place of Device, not because you want the reader to be unconscious of whether it is a hardware or software, but rather because you want to be less vendor-specific. You’re saying here the Node is an idealisation of Device.

Marc: I meant that using a vendor or product name is very specific and ‘physical’, since you denote the actual ‘thing’ instead of a more generic computational resource. It would be reasonable, when refining a model by adding physical product names, to use Devices instead of Nodes.

Graham: So when I (as designer) come to annotate your Node box with an IBM product number, I should change the box to physical Device. And when I decide to virtualise that Device, I should change the box symbol to System Software.

(Perhaps virtualisation will eventually remove the need for us the model hardware in an EA method at all.)

From Network to Device

Marc: The Network box symbol is used to model the network connections, routers, bridges and switches in the physical communication infrastructure.

Graham: I think of those as Nodes or Devices.

Marc: I don’t use those boxes because network equipment isn’t ‘computational’ in the strict sense. You cannot deploy a piece of software on a switch.

Graham: Surely routers, bridge and switches have network software deployed on them? 

Marc: Yes, but from the user’s perspective, they are ‘closed’ boxes - not generic computational resources that can be assigned all kinds of duties. However, the distinction is fuzzy. The border between Network and Device can be difficult to draw. I might model Firewalls as Devices (or Nodes), since they are relatively computational. But enterprise architects rarely model at the level of routers and switches. Mostly, they just show that a Node connects to a network (often a cloud).

Artifacts

Graham: TOGAF does not expect enterprise architecture to get down to the level of deployable artifacts. Again, TOGAF tells us the “physical elements in an enterprise architecture may still be considerably abstracted from solution architecture, design, or implementation views”. It expects solution architects to get down to that level in phase G, after the TOGAF-level enterprise architecture has been completed.

Concluding remarks

Our analysis here is not complete, and we aren’t planning to complete it. We think that is either somebody else’s job, or deserving of a commercial contract! However, we do invite the TOGAF and ArchiMate working groups of The Open Group to take up this analysis and use it as input to improving the alignment and consistency of both methods. We trust we have shed some light on the sometimes subtle and abstract ideas behind these approaches and we hope that users of both TOGAF and ArchiMate can profit from this analysis.

References

[1] Graham Berrisford & Marc Lankhorst, “Using ArchiMate with an Architecture Method”, Via Nova Architectura, June 2009. http://www.via-nova-architectura.org/magazine/magazine/using-archimate-with-an-architecture-method.html

[2] Graham Berrisford & Marc Lankhorst, “Using ArchiMate with TOGAF – Part 1: Answers to nine general questions about methods”, Via Nova Architectura, June 2009. http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-togaf.html

[3] Graham Berrisford & Marc Lankhorst, “Structural and behavioural views – and the ambiguity of “Function”, Via Nova Architectura, July 2009. http://www.via-nova-architectura.org/artikelen/tijdschrift/structural-and-behavioural-views-and-the-ambiguity-of-function.html

[4] The Open Group, ArchiMate® 1.0 Specification. Van Haren Publishing, 2009. http://www.opengroup.org/archimate, http://www.opengroup.org/bookstore/catalog/c091.htm,

[5] The Open Group, TOGAFTM Version 9. Van Haren Publishing, 2009. http://www.opengroup.org/togaf

[6] Marc Lankhorst, Hans van Drunen, “Enterprise Architecture Development and Modelling – Combining TOGAF and ArchiMate”, Via Nova Architectura, 21 March 2007. http://www.via-nova-architectura.org/magazine/magazine/enterprise-architecture-development-and-mode.html

[7] Graham Berrisford, Papers accessible at http://avancier.co.uk, in particular:

“What is a Function?”

“Architecture Meta Models”

Papers on “Abstraction” in the “Library”.

[8] British Computer Society, Reference model for ISEB certificates in enterprise and solution architecture (v11.3), BCS, 2009.
http://www.bcs.org/upload/pdf/reference-model-enterprise-solution-architecture.pdf

Copyright

    This paper is edited from conversations between Marc Lankhorst (group leader Service Architectures at Novay and a founder and teacher of ArchiMate® [4]) and Graham Berrisford (a TOGAFTM 9 [5] instructor for Architecting-the-Enterprise and author of the papers in [7]).

Creative Commons Attribution-No Derivative Works Licence 2.0

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this document, not derivative works based upon it.

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit the authors Graham Berrisford of Avancier Limited and Marc Lankhorst of Novay before the start and include this footnote at the end.

For more information about the licence, see http://creativecommons.org

ArchiMate® and TOGAFTM are registered trademarks of The Open Group.

[PDF]






Comments (2)
RSS comments
Written by maikel on 12-09-2009 15:59
 
 
How can I model business capabilities with archimate

  
Written by This e-mail address is being protected from spam bots, you need JavaScript enabled to view it on 29-09-2009 12:53
 
 
I would model capabilities with Business Functions in ArchiMate.

  

Only registered users can write comments.
Please login or register.
 
[ Back ]
Related Items
Methods & techniques
Wednesday, 01 July 2009
This theme contains content items that are related to architecture methods and techniques.

meer
The Framework is the Meta-Architecture of an Enterprise Architecture
Adrian
Saturday, 06 March 2010

The core of any EA development is the framework, i.e. its meta-architecture. The framework is the glue between components and artifacts. Without a good framework, there is no navigation between artifacts and their components.

meer
De PSA bevat geen Solution Architecture!
Joost Luijpers
Tuesday, 01 December 2009

Bij veel organisaties bestaat het beeld dat de Project Start Architectuur (PSA) bedoeld is om de Solution Architecture van het project weer te geven en daarmee de scope te bepalen. Als gevolg daarvan is het een dik document en duurt het enkele maanden om het op te stellen. Dit artikel laat zien dat deze invulling van de PSA fundamenteel onwenselijk is. De PSA bevat geen Solution Architecture!

meer
Why do need an EA framework
Adrian Grigoriu
Thursday, 22 October 2009
Without a framework, we can deliver predictable and repeatable outcomes. An EA framework represents the architecture of the EA, that is the meta-architecture of the Enterprise, i.e. an EA structure with hooks where components fit back in, like the chassis where the car parts mount on.
meer
Bedrijfsmodelleren vanuit producten en diensten
Frits Cost
Wednesday, 08 July 2009

Bedrijfsprocessen in kaart brengen blijft een vak apart. Er zijn inmiddels schitterende modelleertools waarmee procesmodellen met één druk op de knop kunnen worden omgezet in werkende applicaties die die processen kunnen ondersteunen of op basis van bedrijfsregels zelfs volledig kunnen uitvoeren, maar in het woud van mogelijke tools en methodieken is het vaak moeilijk kiezen. Bovendien zijn beschikbare proces referentiemodellen die er voor verschillende branches en toepassingsgebieden zijn vaak lastig vertaalbaar naar de eigen praktijk.

meer
Using ArchiMate with TOGAF
Graham Berrisford and Marc Lankhorst
Wednesday, 24 June 2009

This paper is the second in a series in which we intend to shed light on the possibilities of using the ArchiMate language with an architecture method and inform you on the pitfalls you may face. This paper follows up “Using ArchiMate with an Architecture Method”, which outlined some of the fundamental ideas behind ArchiMate and set out nine questions to ask of a method to be used in conjunction with it.

This second paper returns to answer the nine questions we defined in the first paper (to help you integrate the use of ArchiMate with your chosen architecture method) using TOGAF as an example architecture method.

meer
Using ArchiMate with an Architecture Method
Graham Berrisford and Marc Lankhorst
Wednesday, 10 June 2009

The ArchiMate language for enterprise architecture has recently been adopted by The Open Group as a technical standard. This may result in a steep rise in its popularity. However, ArchiMate is only a language and does not prescribe a way of working. Hence, it will be used in combination with some other method to guide the process of architecting. Some assume it will be easy to use ArchiMate when following the process of their preferred architecture method. Indeed, it will be easy to use the ArchiMate box symbols in drawing artifacts/diagrams. Perhaps many will do this, thinking they have thus used the ArchiMate language with their method.

meer
Een pragmatische aanpak voor enterprise-architectuur
Danny Greefhorst, Sander Rodenhuis, Toine Schijvenaars, Erwin Oord, Jan Willem van Veen
Monday, 11 May 2009
Een enterprise-architectuur in twee weken

Architectuur is een belangrijk instrument bij het veranderen van organisaties. Organisaties zijn in veel gevallen nog wel op zoek naar hoe ze dit instrument precies moeten hanteren. Deze zoektocht leidt er veelal toe dat architectuur overmatig wordt toegepast en onvoldoende aansluit op de doelstellingen. Dit artikel beschrijft een pragmatische visie en een bijbehorende aanpak voor enterprise-architectuur. Deze aanpak levert in twee weken al veel toegevoegde waarde.

meer
Architects: Execute and evaluate your methods!
Erik Proper
Tuesday, 21 April 2009

Since architecture is a relative new field, much debate goes on about the methods and techniques to be used within the field. Since one of the key competencies of an architects is to be able think conceptually, it is only natural for architects to engage in lengthy discussions about their tools, techniques, approaches and methods. A recent example of such a discussion can be found on the Via Nova Architectura website, where a rather opinionative posting on TOGAF 9 resulted in an involved discussion with 38 elaborate responses.

meer
Methodologica
Hans Bot
Friday, 17 April 2009

De komst van de alweer negende versie van het architectuurraamwerk van de Open Group – TOGAF – heeft een verhit debat in de architectencommunity veroorzaakt. Daan Rijsenbrij stelde in zijn column in de Automatiseringgids dat TOGAF een regelrechte bedreiging voor de creativiteit van architecten vormt en pleitte voor een bijsluiter met die strekking. Op Via Nova Architectura leverde dit niet minder dan 38 reacties op – de één nog gepeperder dan de andere. Is de Open Group doorgeschoten in haar ambitie om een wereldstandaard voor architectuur neer te zetten, of hebben ze alleen misgeschoten?

meer
Boekbespreking: Bedrijfsarchitectuur - werken aan een samenhangende bedrijfsinrichting
Tuesday, 14 April 2009
In het boek "bedrijfsarchitectuur" geven de auteurs een goed overzicht van het architectuur vakgebied in de volle breedte. Het is bewonderenswaardig hoeveel informatie de auteurs in dit boek bijeen hebben kunnen brengen. Het is wel wat jammer dat het boek voor een deel weer eigen terminologie introduceert.
meer
TOGAF: het universele wondermiddel?
Daan Rijsenbrij
Monday, 30 March 2009

In 1982 schreef Jaap van Rees het roemruchte artikel ‘de methode doet het niet’. Sinds die tijd is er een ware vloedgolf aan methodenboeken op de markt verschenen. Veel methoden zijn trouwens activiteitgeoriënteerd, dus uitermate geschikt om op basis van uurtje-factuurtje op mechanische wijze body shopping uit te voeren. Het is dan ook niet voor niets dat veel methodes door softwarehuizen zijn bedacht dan wel worden gepropageerd.
‘De methode doet het niet’ geldt des te sterker voor projecten die een hoge mate van creativiteit en situatieafhankelijkheid vergen. ....

meer
ArchiMate 1.0
Henk Jonkers, Marc M. Lankhorst, Maria-Eugenia Iacob, Erik Proper
Tuesday, 17 March 2009

De internationale standaard voor het modelleren van enterprise-architecturen

De Open Group werkt al jaren aan standaarden. Eerst waren dat standaarden op het gebied van protocollen en operating systems. Sinds het einde van de jaren negentig richt men zich ook op standaarden voor het werk van architecten. The Open Group Architecture Framework (TOGAF), waarvan onlangs versie 9 is verschenen, is uitgegroeid tot een van de meest toonaangevende methoden voor enterprise-architectuur. In dit artikel kijken we naar ArchiMate, de nieuwe Open Group-standaard voor architectuurmodellering.
meer
Dragon1 - een EA methode conform het bewegingsmodel
Mark Paauwe
Friday, 06 February 2009
Dragon1 is een beweging die enterprise architectuur uitdraagt als ontwerp- en realisatiediscipline voor duurzame, toekomstvaste en integrale bedrijfs/IT-oplossingen. In deze blog zet ik kort uiteen wat de essentie is van Dragon1. Dit zodat iedereen zelf een beeld kan vormen over wat Dragon1 is in het licht van andere bewegingen, methoden en aanpakken. En ook de mogelijkheid heeft om er kennis van te nemen.

Bij de opzet van Dragon1 we gekozen voor het bewegingsmodel. Naast een methode in boeken, cursussen, sjablonen, voorbeelden en checklisten, is er bij Dragon1 ook een Dragon1 Usergroup, een Dragon1 Architecture Foundation en een XR. e-magazine.

Met al deze zaken wordt ervoor gezorgd dat steeds meer mensen kennis kunnen nemen op een laagdrempelige en zeer toegankelijke wijze van het gedachtengoed dat Dragon1 heet. Iedereen die wil bijdragen aan Dragon1 kan dat via de Usergroup. Dat gebeurt nu nog kleinschalig elke maand in Wageningen.
meer
TOGAF voor IT-architectuur of Dragon1 voor Enterprise Architectuur?
Mark Paauwe
Thursday, 05 February 2009
Architectuur leer je niet uit een boekje, maar van een meester en na jarenlange uitoefening. Daarom: Niet TOGAF is verplichte kost voor de architect, maar de oratie van Daan Rijsenbrij. TOGAF is een goed (reactief) analyse/managementinstrument, voor IT-architectuur, of beter gezegd: IT-structuur en IT-constructie. Dragon1 is volgens de Dragon1-gebruikers meer een (proactief) ontwerp/strategisch instrument voor bedrijfstransformaties en IT-innovatie onder enterprise architectuur. Maar methoden blijven methoden. Je hebt goeroes nodig die aan de hand van een methodische aanpak laten zien hoe je mooie dingen maakt. 
meer
Een volgende stap in de ontwikkeling van architectuur
Monday, 02 February 2009

TOGAF in vogelvlucht

Er zijn de afgelopen tien jaar veel architectuurmethoden, technieken en raamwerken verschenen. Veel van deze methoden en technieken zijn afkomstig van adviesorganisaties en niet publiek beschikbaar. Er is echter een duidelijke trend naar open standaarden en TOGAF en ArchiMate zijn daarvan goede voorbeelden. In dit artikel wordt een overzicht gegeven van TOGAF, waarbij met name wordt ingegaan op TOGAF 9. Aanleiding is de publicatie ervan op 2 februari 2009 op de Open Group conferentie in San Diego.
meer
Book review: An Enterprise Architecture Development Framework from Adrian Grigoriu
Denis Hageman
Sunday, 31 August 2008
In the introduction of the book the author promises “to answer some of the common sense business questions related to Enterprise Architecture”. Reading the book, I got very soon the impression that he in fact, wanted to answer every potential question. Some aspects are discussed on the level to guide the Architect, others to teach the Business Manager.
meer
Why an Enterprise Architecture framework?
Adrian Grigoriu
Wednesday, 05 March 2008
The EA framework is the meta-architecture of the Enterprise or the Architecture of the Enterprise Architecture. This item explores what an EA framwork is and what is should consist of.
meer
Modelleren van organisaties - nieuwe methoden en technieken leiden tot beter inzicht
Rob Aaldijk, Erik Vermeulen
Monday, 26 November 2007
In dit artikel pogen de auteurs de balans op te maken van een aantal ontwikkelingen op het terrein van bedrijfsmodellering. Met het positioneren van een aantal veelbesproken technieken voor visuele modellering wordt gepoogd meer helderheid te scheppen in het enorme aanbod op dit gebied. Tot slot wordt er gekeken naar voor de nabije toekomst te verwachten of gewenste uitbreidingen op bestaande praktijken.
meer
Framework for evaluating architecture modeling methods
Jeroen Cloo
Wednesday, 07 November 2007
In this research project, ing. J.M. Cloo developed a framework for evaluating architecture modeling methods for their suitability for modeling services and applied it to three of the most frequently used methods within Capgemini by Business architects: DEMO (Dietz, 1999) and Business modeling Method for Information planning (BMI). The framework consists of criteria for modeling methods and a classification of these criteria.
meer
Methods as Action Knowledge: Exploring the Concept of Method Rationale in Method Construction, ...
Pär J Ågerfalk, Brian Fitzgerald
Monday, 13 June 2005
Systems development methods are used to express and communicate knowledge about systems and software development processes; i.e. methods encapsulate knowledge. Since methods encapsulate knowledge, they also encapsulate rationale. Rationale can in this context be understood as the reasons and arguments for particular method prescriptions. In this paper we show how the combination of two different aspects of method rationale can be used to shed some light on the communication and apprehension of methods in systems development. This is done by way of clarifying how method rationale is present at three different levels of method existence. By mapping existing research on methods onto this model, we conclude the paper by pointing at some research areas that deserve attention and where method rationale could be used as an important analytic tool.
meer
A Metamodelling-based Approach for Method Fragment Comparison
Massimo Cossentino, Salvatore Gaglio, Brian Henderson-Sellers, Valeria Seidita
Monday, 05 June 2006
Several different approaches to Situational Method Engineering exist. They differ in terms of the primary element of the paradigm: the method fragment definition. Here, we introduce four method fragment definitions from the literature and compare their metamodels according to structural and functional criteria. The structural comparison showed a general alignment of some concepts that are sometimes referred with different names while the study of the compositional aspects results in evidence of substantial differences.
meer
Een aanzet tot een methode om architectuurdocumentatie te evalueren
Robin van ‘t Wout
Monday, 27 August 2007
Het doel van dit onderzoek was om een methode te ontwikkelen voor de evaluatie van digitale architectuur. Er zijn verschillende gebieden onderkend die allemaal te evalueren zijn. Twee belangrijke stromingen zijn de productgeoriënteerde aanpak en de procesgeoriënteerde aanpak. De keuze is gemaakt om het product van architectuurontwikkeling te evalueren, de architectuurdocumentatie. De Architectuur Documentatie EvaluatieMethode is een raamwerk die verschillende scans bevat die uitgevoerd kunnen worden.
meer
Adaptiviteit in Architectuur - Aanzet tot een evaluatiemethode en resultaten van een evaluatie
Guido Chorus
Friday, 22 June 2007
Tijdens de evaluatie van de gemeente Amsterdam door middel van de voorbereidende scan werd vrijsnel duidelijk dat er verschillende belangrijk geachte elementen niet aanwezig zijn. Zo is de rationaliseringsketen niet expliciet gemaakt waardoor er geen fundering is voor alle gekozen oplossingen in de architectuurdocumentatie. Tevens zijn er geen stakeholders en concerns opgenomen waardoor de validiteit van de architectuurprincipes niet gegarandeerd is. De gemeente Amsterdam dient de rationaliseringsketen dan ook expliciet op te nemen in de volgende versie. Aangezien de architectuurdocumentatie belangrijke elementen mist zou de holistische scan niet mogen worden uitgevoerd.Dit is omwille van het onderzoek toch gedaan. ...
meer
Architectuurdocumentatie Evaluatie - Aanzet tot een methode om architectuurdocumentatie te evalueren
David Campbell, Guido Chorus, Yves Janse, Chris Nellen, Paul van Vlaanderen, Robin van ’t Wout
Friday, 15 June 2007
Dit document is het resultaat van een onderzoek binnen het vakgebied van de Digitale Architectuur, zoals dit gedoceerd wordt aan de Radboud Universiteit te Nijmegen. Het onderzoek is door zes studenten uitgevoerd onder begeleiding van prof. dr. Daan Rijsenbrij en prof. dr. Erik Proper. Dit document beschrijft de eerste fase van het onderzoek; de ontwikkeling van een architectuurevaluatiemethode. In de tweede fase wordt dit onderzoek voortgezet op individuele basis. Een aantal onderdelen van de methode worden dan verder uitgediept. Ook wordt de in dit document voorgestelde methode getest door een bestaande architectuur te evalueren. Deze fase is niet beschreven in dit document.
meer
Successful Modelling of the Enterprise
Christopher Magee
Thursday, 19 May 2005
This report is a result of research conducted for the Radboud University of Nijmegen and Sogeti Nederland B.V. Our main research question was to determine how an architect can create a usable description of an enterprise. This research question was defined because architects require insight into the enterprise which enables them to develop a usable architecture. At the time this research initiated it was yet unknown how usable descriptions could be created.
meer
A UML Profile for Modeling Framework-based Web Information Systems
Vítor Estêvão Silva Souza, Ricardo de Almeida Falbo, Giancarlo Guizzardi
Friday, 22 June 2007
The rapid evolution of the area of Web Engineering has motivated the proposal of several methods and frameworks for the development of Web Information Systems (WISs). In particular, it is becoming more and more common to use containerbased architectures and frameworks when it comes to their development. Following this idea, we have proposed a method for designing frameworkbased WISs, called FrameWeb. and, in this paper, we present FrameWeb's UML profile for modeling framework components in design models.
meer
Ten Years Plus with EKD: Reflections from Using an Enterprise Modeling Method in Practice
Janis Stirna, Anne Persson
Friday, 22 June 2007
This paper presents experiences and reflections from using the EKD Enterprise Modeling method since the beginning of the 1990’ies. A large number of application cases have been carried out. The paper focuses on the EKD modeling language, the EKD modeling process and supporting tools.
meer
An Ontological Framework of Method Engineering: An Overall Structure
Mauri Leppänen
Friday, 22 June 2007
A large number of strategies, approaches, meta models, techniques and procedures have been suggested to support method engineering (ME). Most of these artifacts, here called the ME artifacts, have been constructed, in an inductive manner, synthesizing ME practice and existing ISD methods without any theory-driven conceptual foundation. Also those ME artifacts which have some conceptual groundwork have been anchored on foundations that only partly cover ME. This paper presents an ontological framework, called OntoFrame, which can be used as a coherent conceptual foundation for the construction, analysis and comparison of ME artifacts. Due to its largeness, we describe here its modular structure composed of multiple ontologies. For each ontology, we highlight its purpose, sub-domains and theoretical foundations. We also mention the approaches and process by which OntoFrame has been constructed.
meer
Representation of Method Fragments: A Domain Engineering Approach
Iris Reinhartz-Berger, Anat Aharoni
Friday, 22 June 2007
The discipline of situational method engineering (SME) promotes the idea of retrieving, adapting, and tailoring fragments, rather than complete methodologies, to specific situations. In order to succeed in creating good methodologies that best suit given situations, fragment representation and cataloguing are very important activities. We introduce a visual SME approach,whose roots are in domain engineering. This approach relies on the Application-based DOmain Modeling (ADOM) approach, which provides a framework for representing both applications and domains and validating them each against the other. Furthermore, the proposed ADOM-based approach aims at supporting all the SME-related activities, while in this paper we focus only on its fragment representation and cataloguing parts. The main advantages of the approach are its expressiveness, its support for specifying, constraining, and...
meer
Towards a life cycle of method engineering
Naveen Prakash, S.B. Goyal
Friday, 22 June 2007
We propose a three stage method development life cycle. The requirements engineering phase consists of elicitation and representation of method intentions, the design phase produces the architechture of the method and the construction phase consists of organizing method features in a coherent whole. We concentrate in this paper on the Design and Construction phases of the life cycle. We explaion our notion of method architecture and organization and illustrate them. Finally we show the relevance of method architecture and organization in SME. The design and consturction engineering phases of our life cycle are illustrated for a small SME example.
meer
A Framework for Project Architecture in the Context of Enterprise Architecture
Ralph Foorthuis, Sjaak Brinkkemper
Friday, 11 May 2007
Little scientific research has as yet been done on projects conforming to Enterprise Architecture. To lay foundations for such research, this paper presents a theoretical framework for defining the Project Architecture (PA) in the context of working with Enterprise Architecture. One part of the PA is the Project Start Architecture (PSA), which bounds the project to the Enterprise Architecture (EA) and/or Domain Architecture (DA). We start with explicating the context of a PSA in terms of its relation to the EA and DA. Subsequently, we define the PA in terms of three dimensions. The first dimension con-tains four aspect areas. The second dimension features four abstraction levels. The third dimension contains two project content categories: the PSA (containing prescriptions inherited from the EA and/or DA) and the PED (the Project Exclusive Design, containing the fundamental analysis and design artifacts that have been created specifically for the project). A real-life case is used to help illu-strate and validate the theoretical framework. Additionally, a mapping with RUP artifacts is made to further clarify the framework of the PA with examples of well-known analysis and design artifact types.
meer
A Proposed Framework for Knowledge Discovery in Enterprise Architecture
M. El Kourdi, H. Shah, A. Atkins
Friday, 11 May 2007

The aim of this research is to develop an information agent framework for knowledge discovery in enterprise architecture (EA). This framework is based on specific purpose ontology and knowledge discovery techniques. Such framework would facilitate strategic decision making for EA stakeholders by enabling them to analyze and monitor the portfolio of processes, data, applications, and organizational units in terms of their correlation and impact in the overall organization. This framework is very useful for affording key stakeholders with the appropriate view that is reliant on an accurate and concise picture of systems, applications, technologies and other infrastructure elements in the business and how these integrate to serve the enterprise. The paper discusses the concepts and components of this framework. Potential benefits of this framework over existing approaches are also discussed.

meer
Enterprise Architecture Development and Modelling
Marc Lankhorst, Hans van Drunen
Wednesday, 21 March 2007
In this article, we explore the possibilities of combining ArchiMate, a modelling language for enterprise architecture (EA), with TOGAF, The Open Group Architecture Framework, a design method for EA.
meer
Een generiek en uitbreidbaar raamwerk voor (IT)-architectuur: xAF deel 1
Frank Baldinger, Jan Dietz, Martin Op 't Land
Sunday, 03 September 2006
In een serie van artikelen wordt een generiek uitbreidbaar (IT-) Architectuurraamwerk beschreven. In dit eerste artikel wordt gedetailleerd ingegaan op de essentie van het ontwerpproces.
meer
Een generiek en uitbreidbaar raamwerk voor (IT)-Architectuur: xAF deel 2
Frank Baldinger, Jan Dietz, Martin Op 't Land
Wednesday, 04 October 2006
In een serie van artikelen wordt een generiek uitbreidbaar (IT-)Architectuurraamwerk beschreven. In dit tweede artikel wordt het Metamodel xAF beschreven en zal nader worden ingegaan op de Architectuur-principes.
meer