• English
  • Nederlands
HOME
ZOEK
CONTACT
NIEUWSBRIEF
 
 
 
INHOUD
Over ons
Over NAF
Bijdragen
Artikeloproep
De CIO spreekt
De Architect antwoordt
De Business bepaalt
Proceedings
Blogs
Scripties
Kalender
Links
Login/Registreer
THEMAS
Effect van architectuur
SOA
BPM
Methoden
Architectuurprincipes
Financiële sector
Overheidssector
Zorg sector
Advertenties
Zoek je een baan?
Zoek je hulp?
Zoek je een opleiding?
Zoek je een tool?


Logica
logo_5fsap.jpg 

 
 
Aankondigingen
Using ArchiMate with an Architecture Method
Graham Berrisford and Marc Lankhorst   
woensdag, 10 juni 2009

Introduction

The ArchiMate language for enterprise architecture[1] 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.

But ArchiMate is not just a set of box shapes and line styles. If you only use ArchiMate symbols to draw the artifacts of an architecture method, you can miss the point of ArchiMate, and possibly undermine its qualities. ArchiMate is a component-based development approach, with its own meta model, entity definitions, and philosophy.

In this paper, the first of a series edited from our conversation on the topic over recent months, 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.

The motivation for this series of papers is threefold:

  1. We are not so worried if people use methods like TOGAF in ways that deviate from what is defined as “core” TOGAF. We are more concerned that people rarely use a modelling language as its authors intend. The truth is that most people (other than programmers) do not use UML. They use UML tools. They use UML boxes and lines to mean whatever they want. They do not even realise they are not using UML. That undermines the notion of UML as a language. If we can help ArchiMate being abused in the same way, then we would like to.

  2. Consultants may well combine methods like TOGAF and ArchiMate in ways their customers accept. But if nobody notices they are not using either “properly”, then we will never correct the weaknesses in the methods. We want to expose the discrepancies between TOGAF and ArchiMate, and their weaknesses, sufficiently clearly that someone can and will address them. That requires a properly detailed analysis of inconsistencies - between the methods and within them.

  3. Teachers of architecture processes and notations need explanations that work from first principles to form a coherent overall explanation. We are not satisfied with informal alignments of methods that depart from what their authors intended – since students are then left without understanding the basic principles and ask embarrassing questions that cannot be answered.

Naturally, it is never possible to “enforce” correct usage of any language or method. No method is perfect. They are all products of inevitable compromises. In the end, the skills of the architect are much more decisive than the methods he or she uses. Nevertheless, we should explain our methods in ways that make them easy to understand, minimise confusions and maximise the quality of the end result.

In this paper, we first outline the basic principles on which ArchiMate is founded. Next, we will address a series of questions that will help you decide how readily you can use ArchiMate with your preferred architecture method.

Our conversation is continuing and we will edit that into more specific papers on using ArchiMate with The Open Group Architecture Framework (TOGAF)[2] and on some fundamental differences and similarities between the two. We have added brief references to this paper. This conversation also intends to extend and improve the ideas on combining ArchiMate and TOGAF outlined in [3] and it applies various thoughts on modeling and abstraction as described in[4]. These ideas may also serve The Open Group’s working group on the convergence of ArchiMate and TOGAF as input.

ArchiMate basics

Within many of the different domains of expertise that are present in an enterprise, some sort of architectural practice exists, with varying degrees of maturity. All kinds of frameworks try to map these domains, such as the Zachman framework, TOGAF, and many more. However, due to the heterogeneity of the methods and techniques used to document the architectures, it is very difficult to determine how the different domains are interrelated. Still, it is clear that there are strong dependencies between the domains. For example: the goal of the (primary) business processes of an organisation is to realise their products; software applications support business processes, while the technical infrastructure is needed to run the applications; information is used in the business processes and processed by the applications. For optimal communication between domain architects, needed to align designs in the different domains, a clear picture of the domain interdependencies is indispensable.

Hence a language for modelling enterprise architectures should focus on inter-domain relations. ArchiMate therefore provides concepts to model both the global structure within each domain, showing the main elements and their dependencies, and the relations between the domains, in a way that is easy to understand for non-experts. To facilitate learning and understanding ArchiMate, it has a limited set of concepts and is built on a number of basic elements that are visible throughout the various layers of the language.

First, its basic structure draws on the deep grammatical structure of natural language. All human languages have sentences consisting of subjects, verbs and objects; only their order differs. So we have languages with an SVO grammatical structure like English, SOV like Hindi, or VSO like Arabic. Similarly, ArchiMate distinguishes between active structure elements (the business actors, application components and devices that display actual behaviour, i.e., the ‘subjects’ of activity), passive structure elements, i.e., the ‘objects’ on which behaviour is performed, and behavioural elements, the activities that are carried out, i.e., the ‘verbs’. Behavioural concepts are assigned to active structural concepts, to show who or what carries out these activities.

This subdivision also has implications for the design process. In developing a greenfield architecture, we often work from behaviour to structure, i.e., first design the necessary functionality and next assign it to the constructional units that have to provide this functionality. In accommodating pre-existing elements into the architecture, a bottom-up (or perhaps middle-out) way of working is often called for: first describing the existing components, actors, etc., and next analysing their behaviour and extracting the services they provide.

Second, ArchiMate distinguishes between an external view and an internal view on systems. When looking at the behavioural aspect, these views reflect the basic principles of encapsulation that are also prevalent in service orientation. The service concept represents a unit of essential functionality that a system exposes to its environment. For the users of a system, only this external functionality, together with non-functional aspects such as the quality of service, costs etc., are relevant. Services are accessible through interfaces, which constitute the external view on the structural aspect.

Again, this is also reflected in the design process when we use ArchiMate: usually, we first design the desired external properties of a system, and next its internals.

Although, at an abstract level, the concepts that are used throughout EA models in ArchiMate are similar, ArchiMate defines more concrete concepts that are specific for a certain layer of the architecture. In this context, we distinguish three main layers:

  1. The Business layer offers products and services to external customers, which are realised in the organisation by business processes (performed by business actors or roles).

  2. The Application layer supports the business layer with application services which are realised by (software) application components.

  3. The Technology layer offers infra structural services (e.g., processing, storage and communication services) needed to run applications, realised by computer and communication devices and system software.

This results in the language framework shown below. In this framework, we have projected commonly occurring architectural domains.

Core questions

To assess whether an architecture method matches the ArchiMate language sufficiently to use the two in combination, we need to investigate whether the core ideas of ArchiMate as outlined in the previous section are in accordance with the method’s fundamentals. This leads us to the following set of questions:

  1. Does the method separate process from artifacts? If a method’s process (way of working) is too tightly coupled to the artifacts it delivers, using a language like ArchiMate for these artifacts may prove problematic.

  2. Does the method separate structure from behaviour? This separation is an important element of ArchiMate with impact on the design process, as described above.

  3. Does the method separate external from internal? As explained, the concept of encapsulation is another fundamental tenet of ArchiMate (and many other modelling languages).

  4. Does the method separate logical from physical? Many methods use a progression from more abstract (or logical) to more concrete (physical) things. ArchiMate’s realisation relationship is an example of such a progression, but the terms ‘logical’ and ‘physical’ are used in various ways in different methods. The concepts for abstraction used by the method need to match ArchiMate’s sufficiently.

  5. Does the method separate the general from the specific? This is another kind of abstraction that features in some architecture methods. ArchiMate has the generalisation relationship but doesn’t really emphasise this dimension. Some methods do, however, and if so, how does this match with ArchiMate?

  6. Does the method present domains as layers? As outlined before, ArchiMate provides a three-layer structure, Does your preferred method feature the same layering?

  7. Does the method’s meta model align with ArchiMate’s? Some methods come with their own explicit and/or implicit meta model. Do these match sufficiently, i.e., can we provide a workable mapping of concepts and relations?

  8. Does the method rely on UML? Since ArchiMate uses some concepts derived from UML, but differs in some important aspects, some confusion may arise if your chosen method is based on UML (or on a UML profile).

  9. How abstract is the method? ArchiMate targets the enterprise level of abstraction and the level directly below that (domain architectures). Its concepts possess just enough ‘meaning’ for that level of abstraction, which should match with the level targeted by a method used in conjunction with it.

The subsequent sections address these questions one by one.

Does the method separate process from artifacts?

Marc: Wherever a method separates architecture process from architecture descriptions (entities, artifacts and outputs) we should be able to use the process to produce an ArchiMate-style architecture.

Graham: We’ll expect an architecture method to come with its own architecture entities and artifacts. Moreover, the bigger challenge for ArchiMate is that its process steps will produce outputs that imply a meta model relating those architecture entities.

Marc: Yes. We don’t want following the process of an architecture method to water down the essential ideas of ArchiMate.

Marc: Does TOGAF separate process from artifacts?

Graham: Inevitably, the ADM process refers to artifacts and deliverables. And strictly speaking, TOGAF defines the process steps and their outputs as “core”, meaning that if you don’t produce the outputs, then you are not following TOGAF.

Marc: Still, I have seen the ADM process used to construct an ArchiMate-style architecture. E.g. at a life insurance company here in the Netherlands.

Graham: Using ArchiMate to construct ADM artifacts and outputs is more challenging, because we have to address the underlying meta models.

Does the method separate structure from behaviour?

Marc: Yes. We don’t want following an architecture method to water down ArchiMate’s separations between internal and external, and between structure (active & passive)and behaviour.

Graham: The table below shows these two essential dimensions as rows and columns, and contains the five entities in ArchiMate’s meta meta model.

ArchiMate dimensions Structure (passive) Behaviour Structure (active)
External
Service Interface

Object

Internal
Behaviour element Structure element

Marc: You’re right about the essential nature of this two-way classification. The separations between internal and external, and between structure(active & passive) and behaviour are central to ArchiMate.

Graham: To make the same distinctions explicit throughout any given architecture process could require significant reorganisation and rewriting of the process. (By the way, the structure-behaviour distinction does feature in the ISEB reference model for Enterprise and Solution Architecture[5])

Marc: Does the structure-behaviour distinction appear in TOGAF?

Graham: Not explicitly, but it isn’t hard to find.

Does the method separate external from internal?

Marc: ArchiMate’s external-internal dimension separates services and interfaces from their realisation or implementation by process and components.

Graham: This interface-component distinction is the common thread in all component-based development methods. It is a feature of SOA. It is related to distinctions we might call requirement-design, and logical-physical.

Marc: Does the external-internal distinction appear in TOGAF?

Graham: Yes, though the distinction is not drawn clearly and consistently throughout ADM, and it isn’t the core idea that it is in ArchiMate.

Does the method separate logical from physical?

Marc: Object-oriented software architects model the implementation of interfaces by components using realisation relationships. And in ArchiMate, such relationships are used to model the progression from‘more logical’ to ‘more physical’.

Graham: Ah! You may reasonably say that services are more logical, and the components that provide them are more physical. But a component maybe either logical or physical in the sense we need to address under this heading.

Marc: I gather that in TOGAF, an information system service is realised by a logical application component, which in turn is realised by a physical application component.

Graham: Only very loosely speaking. Both those relationships are many-to-many. And your two “realised”have two different meanings. The first describes the external-internal relationship that is strongly emphasised in component-based development methods. The second describes the relationship between vendor-neutral (logical) and vendor-specific(physical) specifications that is strongly emphasised in public sector methods and frameworks.

Marc: I know Zachman, TOGAF and other frameworks put considerable emphasis on this logical-physical distinction. However, people do get confused in this area. That is why we didn’t put the logical-physical distinction into the ArchiMate language as a separate dimension.

Graham: I understand people’s confusions, and your reluctance to cloud their understanding of ArchiMate. But this logical-physical dimension is fundamental to many methods. So we must clarify it and address it.

We have discussed two kinds of logical-physical distinction. ArchiMate is centred on the idea that required services (logical) are realised by designed components (physical). Whereas many architecture methods are centred on the idea that vendor-neutral component specifications(logical) are realised by vendor-specific component specifications(physical).

An architecture method typically follows a process of logical-to-physical realisation in which requirements are realised as logical components, which are realised as physical components, which are realised as deployed solutions.

Marc: Does this kind of logical-to-physical dimension appear in TOGAF?

Graham: Yes, very much so. It appears as in the content classification scheme known as the Enterprise Continuum. And it appears in the progress of the ADM process.

Does the method separate the specific from the general?

Graham: Enterprise architecture is cross-organisational and strategic. It is about generalities: general principles, general standards, industry reference models, common systems, design patterns, reusable components. Enterprise architects deal largely in generalisations, be they at the logical or physical level.

Marc: Generalisation is not a big deal in ArchiMate philosophy, though you can model it of course using the generalisation relationship.

Graham: Yes. It is another kind of abstraction. This table below shows idealisation and generalisation as orthogonal dimensions.

Generalisation Idealisation Universal Fairly generic Fairly specific Uniquely
configured
Ideal        
Logical        
Physical        
Real        

Marc: Does the general-to-specific dimension appear in TOGAF?

Graham: Yes. It appears as the horizontal axis in the four-by-four content classification scheme called the Enterprise Continuum.

Does the method present domains as layers?

Marc: ArchiMate presents the three architecture domains (business, application and technology) as layers. Might we map the application and technology layers to the logical and physical levels/rows in the Enterprise Continuum, or the Zachman framework?

Graham: No, though the Zachman Framework is widely misinterpreted this way. John has restated his basic ideas (on his web site) as these. “The Zachman Framework is a schema [based on] classifications that have been in use for literally thousands of years.

  • The first is the fundamentals of communication found in the primitive interrogatives: What, How, When, Who, Where, and Why.

  • The second is derived from reification, the transformation of an abstract idea into an instantiation.”

So, the purest form of John’s schema is a table that maps the levels of idealisation (in rows) to six interrogatives (in columns).

The Zachman
Framework		 What How Where Who When Why
Ideal to Real Identification            
Definition            
Representation            
Specification            
Configuration            
Instantiation  




However, John has always applied this schema to the world of information systems. I’d summarise the levels thus. Level 6 is run-time systems. Level 5 is machine-interpretable code, data definitions and configurations(compile-time specifications). Level 4 is more abstract specification of the compile-time specifications. Level 3 is more idealised vendor-neutral specifications. Level 2 is application-independent specifications of the business. Level 1 is the sketchiest outline.

TOGAF focuses on level 2 more than any other. The table below maps the four levels of the TOGAF 9’s Enterprise Continuum to the six levels of Zachman’s schema - as they are variously interpreted.

Levels in TOGAF’s Enterprise Continuum Zachman levels v1 As John means them Zachman levels v2 As stakeholders or viewpoints Zachman levels v3 As what? architecture domains or layers?
Context & requirements Identification Planner Scope
Architecture continuum Definition (conceptual) Owner Enterprise
Representation (logical) Designer System
Solutions continuum Specification (physical) Builder Technology
Not addressed Configuration Subcontractor Detailed
Deployed solutions Instantiation Operations Operations

The 2nd and 3rd interpretations of the Zachman levels are somewhat at odds with the first. The 3rd has been bent by Jaap Schekkerman and others (CapGemini?) to fit layered architecture domains. Jaap’s schema turns levels 2, 3 and 4 into architecture layers. But that is to radically change the meaning of the levels. You might as well map architecture domains to John’s columns as to his rows. A much better match is to be found between the levels/rows of the Zachman Framework and the Enterprise Continuum.

The truth is, no single two-dimensional table is adequate as an architecture framework. We need to separate six, seven or eight dimensions. See also [4].

Marc: Does TOGAF present architecture domains as layers?

Graham: There is one over-complex nested box diagram that can be read to do this, and you could say the idea is implicit, but it is not thoroughly worked through.

Does the method’s meta model align with ArchiMate’s?

Graham: There are bound to be mismatches between the meta model of ArchiMate and that of any architecture method we examine (if it has its own meta model of course). They may well be serious enough to confuse people, and they could damage understanding of ArchiMate.

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

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

Marc: 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.

Graham: Hmm…I am not convinced. We need to do lot more work at the level of detailed entity-by-entity comparisons.

Does the method rely on UML?

Marc: ArchiMate is not intended as a competitor to UML for software architecture.

Graham: Nevertheless, they may be used in the same organisation, or even the same team. ArchiMate is both similar to and different from UML. I’m not bothered about differences between box shapes. I am more concerned about differences between relationship lines. The following table of gaps and differences shows the four kinds of abstraction relationships are the same in ArchiMate and UML, but the remaining relationships are different.

 Comparison UML Line symbol ArchiMate
Gaps Dependency ???
??? Assignment
??? Access
Matches (Abstraction) Association Association
Aggregation Aggregation
Composition Composition
Specialisation Specialisation
Realisation Realisation
Differences Data flow Trigger
Trigger Use
??? Flow

Marc: The table is a reasonable summary. We might include a dependency-like relation in a future version of ArchiMate, if sufficient demand from practice arises. The reason we didn’t include it originally is that we found that all dependencies in practice turned out to be one of the other kinds of relations (e.g. use or access).

Graham: Yes. That is because a dependency is an abstraction (by composition) of other kinds of relationship, for example several invocations or data flows.

Marc: Does TOGAF use UML in any way?

Graham: No. TOGAF is concerned with the application portfolio rather than application design. Class diagrams are mentioned in different context from software design. Interaction diagrams are not mentioned in the definition of a process-system realisation diagram.

How abstract is the method?

Graham: Enterprise architecture is cross-organisational and strategic. Enterprise architecture diagrams are usually more abstract than the solution architecture diagrams. Enterprise architects draw dependency relationships that are abstractions from the more atomic relationships drawn by system, solution and software architects.

Marc: True, but in ArchiMate the “use”relation (missing from UML) largely serves this role. The other major kind of dependency is a realisation. Even at a high abstraction level, it is usually clear if one architecture element uses another or is realised by another.

Graham: Yes, an enterprise architect might draw a line to represent not only “uses” and“realises” relationships, but also “replaces” and “migrates to” and “traces to” relationships.

Marc: Relationships covering the change of an architecture between states, like your examples, are useful as well (and are currently lacking in ArchiMate), but I wouldn’t group them in the same category as the other types of dependency. We could add a dependency as a generic super class of all directed relations in ArchiMate (pointing in the opposite direction to the UML dependency), but that would result in a relationship with a very weak meaning -basically a sort of ‘directed association’.

Graham: Enterprise architects often document relationships for use in impact analysis, gap analysis, cluster analysis and traceability analysis. In such models - a general dependency relationship may well be enough.

Marc: But you can also model this using the slightly less generic relationships like “use” and “realisation”. We have tried to avoid weak relations to make ArchiMate models more ‘meaningful’. Otherwise we might end up with models consisting of nothing more than boxes and lines (since the same argument holds not only for the relations, but also for the other concepts of the language). Nevertheless, if there is a real need for a dependency-like relation, this could be added in the future.

Graham: Experience suggests that, at the most abstract level of enterprise architecture description, we do indeed end up with diagrams that are simply boxes and lines. Enterprise architecture is abstract – cross-organisational – strategic. The diagrams are along way from the realisation of the architecture as a physical system. As you reverse engineer, you abstract from, the bottom-level and detailed diagrams to higher-level more abstract views, the meaning of the lines between the boxes evaporates.

Marc: But then you need to assign more meaning to these boxes and lines to understand or explain these diagrams, either implicitly (by the name in the box) or explicitly (by using specific types of boxes and lines like ArchiMate does). In the first case, you then need to explain your naming scheme, and implicitly you are then constructing a kind of modelling vocabulary. Eventually, you’ll run into the same discussion. To have a meaningful and workable architecture, you can’t do without some meaning. Of course, we can debate how generic or specific these concepts can be, and a dependency might well be useful in ArchiMate too, but using concepts that are too generic leaves you with a pretty picture that isn’t very useful in practice.

Graham: Meaning can be added when we elaborate from enterprise architecture diagrams to solution or software architecture diagrams. The main purpose of the higher level enterprise architecture diagrams is to help impact analysis in change management, rather than to help designers.

Marc: True, but I wouldn’t want to abstract away all meaning. I think it’s a matter of balance.

Graham: In my view, ArchiMate is probably best used at the level of system or solution architecture. Its use at the level of cross-organisational strategic enterprise architecture will likely be more limited. But I am sure there is a great deal more to be said about abstraction in general, and levelling of architecture specifications in particular.

Marc: ArchiMate extensions towards goal/requirements modelling are envisaged; these should make it more applicable at the “level of cross-organisational strategic enterprise architecture”.

Marc: How abstract is TOGAF?

Graham: Very. It tells us “physical elements in an enterprise architecture may still be considerably abstracted from solution architecture, design, or implementation views”.

Conclusion

Although it would be easy to think that ArchiMate can be used with ‘any’ method, there are some serious considerations to be addressed, as we have shown in the previous sections. In the next instalments of this series, we will specifically look into the use of ArchiMate together with TOGAF, and some fundamental differences and similarities between the two.

References

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

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

[3] Marc Lankhorst, Hans vanDrunen, “EnterpriseArchitecture Development and Modelling – Combining TOGAF andArchiMate”, ViaNova Architectura, 21 March2007. http://www.via-nova-architectura.org/magazine/magazine/enterprise-architecture-development-and-mode.html

[4] Graham Berrisford, Paperson abstraction etc. in the “Library” at http://avancier.co.uk. In particular http://avancier.co.uk/12%20Abstraction/01%20Abstraction.htm

[5] British Computer Society, Referencemodel 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 has been edited from conversations between Marc Lankhorst (group leaderService Architectures at Novay and a founder and teacher of ArchiMate® [1]) and Graham Berrisford (a TOGAFTM 9 [2] instructor for Architecting-the-Enterprise).

Creative Commons Attribution-No Derivative Works Licence 2.0

No Derivative Works: You may copy, distribute, display only complete and verbatim copiesof this document, not derivative worksbased upon it.

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

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

ArchiMate® and TOGAF™ are registered trademarks of The Open Group.

[PDF]






Reacties (6)
RSS comments
Geschreven door Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken op 10-06-2009 11:35
 
 
I am curious in what way ArchiMate exactly supports behaviour modeling. Is it possible to create things like use case, activity, sequence or state machine diagrams (which are the behaviour diagram types of UML/SysML)? 
 
Can you show an example of a behaviour diagram made with ArchiMate?

  
Geschreven door Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken op 10-06-2009 13:40
 
 
Hi Peter, 
 
ArchiMate isn't intended for the detailed level of (behavioural or any) modelling that UML/SysML are aiming at, since it is used at a higher level of abstraction (EA and just below). But for some examples, have a look at http://www.archimate.org/en/start_using_archimate/good_practices.html 
 
Marc

  
Geschreven door Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken op 10-06-2009 15:58
 
 
Marc, 
 
I'm still confused about the meaning of behavior in Archimate. E.g. the ArchiMate documentation states: "The language consists of active structure elements, behavioral elements and passive structure elements. The active structure elements are the business actors, application components and devices that display actual behavior, i.e., the ‘subjects’ of activity (right side of the Figure 3). Then there is the behavioral or dynamic aspect (center of Figure 3). The active structure concepts are assigned to behavioral concepts, to show who or what performs the behavior." 
For me it is very strange (and confusing) that the things that perform behavior (the subjects of activity) are not the behavioral concepts...  
 
You state in the article: "The separations between internal and external, and between structure(active & passive) and behaviour are central to ArchiMate." So I was hoping to see some clearer examples of the differences between behavior modeling and structural modeling with ArchiMate. For me the examples in the good practices section are more a way to model the structure of the high-level activities then to show behavior.

  
Geschreven door Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken op 10-06-2009 16:07
 
 
I'd say its fairly simple: my behaviour is what I do, but not what I am. So look at a business process, for example: clearly a piece of behaviour, i.e., what the business "does". The roles or actors (like me) are the structural things that perform this behaviour. So I can describe the behaviour in terms of processes, subprocesses, services delivered, etc., and those who perform that behaviour: the organisational units, individual actors, etc.  
 
BTW, Graham likes to add that in his view a use case definition is a behavioural model (a process), but a use case diagram is a structural model (relating actors to processes, with no sequential flow.) Just to show that his and my notions of behaviour and structure are also subtly different.

  
Geschreven door Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken op 10-06-2009 18:34
 
 
Marc, 
 
I'm following Graham :-)

  
Geschreven door Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken op 11-06-2009 19:10
 
 
You'll enjoy our 3rd paper then!

  

Alleen geregistreerde gebruikers kunnen reacties geven.
Log in of registreer.
 
[ terug ]
Gerelateerde artikelen
Methoden en technieken
woensdag, 01 juli 2009
Dit thema bevat artikelen die zijn gerelateerd aan architectuurmethoden en technieken.

meer
The Framework is the Meta-Architecture of an Enterprise Architecture
Adrian
zaterdag, 06 maart 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
dinsdag, 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
donderdag, 22 oktober 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
Using ArchiMate with TOGAF (2)
Graham Berrisford and Marc Lankhorst
woensdag, 12 augustus 2009

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.

meer
Bedrijfsmodelleren vanuit producten en diensten
Frits Cost
woensdag, 08 juli 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
woensdag, 24 juni 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
Een pragmatische aanpak voor enterprise-architectuur
Danny Greefhorst, Sander Rodenhuis, Toine Schijvenaars, Erwin Oord, Jan Willem van Veen
maandag, 11 mei 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
dinsdag, 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
vrijdag, 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
dinsdag, 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
maandag, 30 maart 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
dinsdag, 17 maart 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
vrijdag, 06 februari 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
donderdag, 05 februari 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
maandag, 02 februari 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
zondag, 31 augustus 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
woensdag, 05 maart 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
maandag, 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
woensdag, 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
maandag, 13 juni 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
maandag, 05 juni 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
maandag, 27 augustus 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
vrijdag, 22 juni 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
vrijdag, 15 juni 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
donderdag, 19 mei 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
vrijdag, 22 juni 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
vrijdag, 22 juni 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
vrijdag, 22 juni 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
vrijdag, 22 juni 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
vrijdag, 22 juni 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
vrijdag, 11 mei 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
vrijdag, 11 mei 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
woensdag, 21 maart 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
zondag, 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
woensdag, 04 oktober 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