Category Archives: EA Meta Models

ArchiMate 3.0 Released by The Open Group

The ArchiMate Forum of the Open Group released the ArchiMate 3.0 specification supported by a set of announcements and events (see official blog post here). Thus, I think it is reasonable to provide an overview of the existing information and update my knowledge base.

Please find below a list of links in relation to the new version of ArchiMate:

If you know further useful resources on ArchiMate, please let me know.

The Open Group released ArchiMate 2.1

Actually ArchiMate 2.1 is a specification maintenance release incorporating comments, corrections and clarification issues which were raised since version 2.0.
For further details with respect to the changes refer to this official blog post by The Open Group. In addition a detailed listing of the changes is available as a dedicated document.
Only hours after the release, vendors of flexible EAM tools announced support to version 2.1… 😉

The Open Group’s Conference in Newport Beach, CA – Watch out for the Proceedings

The Open Group’s conference in Newport Beach draws to a close. Watch out for the proceedings and check what conference documents/slides they’ll make available… 😉

Avolution’s ABACUS® 4.0 is ArchiMate® 2.0 Certified

Avolution today announced that its latest release of ABACUS (version 4.0) is now officially certified against The Open Group’s standard, ArchiMate® 2.0 (see Avolution’s press release here). I want to point out that I’m not sponsored by Avolution or any other vendor but what’s interesting from my point of view is that currently only a three tools are currently ArchiMate 2.0 certified: ABACUS® 4.0, Architect 3® by BiZZdesign and ArchiMate for IBM’s System Architect® (see The Open Group’s Tool Certifcation Register here).

Seems to me that the other vendors struggle with the flexibility in relation to the metamodel which is required by ArchiMate 2.0 (see this post for more details on that issue).

I’ll keep an eye on other ArchiMate 2.0 tool certifications… 😉

No Politics, Just Great Architecture

A few days ago a friend of mine changed the short description of his business on his Linkedin page to the slogan: ‘No politics, just delivery.’. What a brilliant slogan! He’s working in the IT project business for many years and I assume that he’s tired of all these projects that are heavily influenced by politics. Of course each nontrivial IT project has to deal with miscellaneous stakeholders and their conflicting objectives/requirements including politics but I think he’s referring to those ones where politics dominates and sometimes leads to strange decisions and project conditions.

Transferring his idea to my primary business of (enterprise) architecture management I adopted it spontaneously to ‘No politics, just great architecture.’ because sometimes there is architectural work that is heavily influenced by politics too. When I spend a few more thoughts on it I was struggling with the adjective great. Of course there is no great or even bad architecture. Remembering the very basics of evaluating architectures an architecture always has to be considered in its context that is framed by the specified requirements (including objectives, principles, constrains) that it has to fulfill (see [ClKK2002, Mali2008]). So it’s much better to characterize it as a capable architecture, i.e. an architecture that fulfills all the requirements that are imposed to it, but ‘No politics, just capable architecture.’ doesn’t sound so smashing… 😉

Anyway there is still the question how to deal with such situations which are heavily influenced by politics. When looking at the enterprise architecture discipline in particular what should an enterprise architect do if he realizes that he is doing architectural work in a politics dominated environment? Furthermore from my point of view it is interesting if there are any best practices or strategies how to cope with such challenges. When looking at TOGAF for example (see [TOGAF2011]) there’s no special chapter or topic explicitly dealing with this question but of course there are a lot of basic methods, guidelines and techniques described in this framework (e.g. architecture requirements management, stakeholder management) that provide the foundation for coping with such situations.

When thinking of the most important pillars of this foundation I came up with the following ones:

1. The role of the enterprise architect should be executed in an objective manner

The enterprise architect role is responsible for providing a capable (alias ‘great’) architecture that fulfills the requirements imposed to that architecture as good as possible. When investigating and evaluating the architectural options the architect himself should be objective, i.e. he should adhere to the facts and should not rely on personal flavor. You might say: ‘Yes, of course!’. Sounds like simple logic but it isn’t… According to Bass, Clemens and Kazman there are four major factors that influence the development of an architecture: Stakeholders, the developing organization, the technical environment and the architect’s experience (cp. [BaCK2003, p. 9-12]).

Source: On the basis of [BaCK2003, p.11]

The latter characterizes the fact that within the development of an architecture the architect gains additional knowledge and extents his experience (cp. [BaCK2003, p. 11]). A successful implemented architecture will inspire an architect to design a similar architecture for another project. An architecture that fails to deliver the expected requirements (including objectives, principles and constraints) is unlikely to be chosen second time. If an architect has little experience with respect to an architecture, architectural building block and/or architectural pattern it is less likely that he will take it into the range of design options.

Therefore an architect should be beware of the fact that his experience influences the architectural design process. In addition he should be open and curious in relation to previously unknown or unapplied design options. These might be the better ones although they were not used by the architect yet.

2. Document the design decisions taken and their rationale

Going back the very basics of documenting architectures the design decisions taken and their rationales should be a mandatory part of the architecture documentation. For example Clements, Bachman, Bass et al. describe this idea in their ‘Seven Rules for Sound Documentation’ (Rule 5: Record Rationale, see [CBBG2003, p. 24-29]). Here it is important to notice that all evaluated options should be documented to support the transparency of the decision process – not only those leading to the final design. Therefore each template for architecture documentation should contain a dedicated chapter and/or structure supporting this part of the documentation.

In case the architect works on the enterprise architecture level a motivational model as part of an overall EA metamodel supports the explicit modeling of the objectives, principles, requirements and constraints and their linkage to the architectural decisions and elements respectively. Take for example Open Groups’ ArchiMate standard which contains such an motivational model in its latest version 2.0 (see [TOGAF2012] and this related post).

3. Use qualitative metrics to the most possible extend

The paramount architectural evaluation is based on qualitative metrics solely but in rare cases the architect has all underlying data and evaluation models and therefore is able to calculate all required metrics. Nevertheless the architect should strive for using qualitative metric by identifying available basic data, useful evaluation models and trying to combine architectural decisions with relevant metrics. In case there are at least some metrics available pure political decisions could be argumented against easily.

REFERENCES

  • [BaCK2003] Bass, Len; Clements, Paul; Kazman, Rick: Software Architecture in Practice. 2nd Edition, Addison-Wesley, Boston et al. 2003.
  • [CBBG2003] Clements, Paul; Bachmann, Felix; Bass, Len; Garlan, David; Ivers, James; Little, Reed; Nord, Robert; Stafford, Judith: Documenting Software Architectures – Views and Beyond. Addision-Wesley, Boston et al. 2003.
  • [ClKK2002] Clements, Paul; Kazman, Rick; Klein, Mark: Evaluating Software Architectures – Methods and Case Studies. Addison-Wesley, Boston et al. 2002.
  • [Mali2008] Malich, Stefan: Qualität von Softwaresystemen – Ein pattern-basiertes Wissensmodell zur Unterstützung des Entwurfs und der Bewertung von Softwarearchitekturen. Gabler, Wiesbaden 2008.
  • [TOGAF2011] The Open Group: The Open Group Architectural Framework (TOGAF).  Version 9.1, 2011.
  • [TOGAF2012] The Open Group: ArchiMate 2.0 Specification. Technical Standard, February 2012.

The Open Group has been released ArchiMate 2.0

The ArchiMate Forum members had the new version on their desk for quite some time. I think The Open Group coordinated the release intentionally with its ongoing  conference in San Franscisco and let me wait for it 😉 Anyway the version 2.0 contains the main enhancements as I expected:

  • The motivation and implementation/migration extensions are integrated as optional language extensions to the core language,
  • the terms are slightly aligned to the TOGAF and
  • of course they included corrections and improvements.

You can find more information on ArchiMate 2.0 on the official web page http://theopengroup.org/archimate/.

In the next weeks I’ll have a closer look at the version 2.0. Particularly I’m interested in two aspects in relation to the new version:

  • The tool support of ArchiMate 2.0 and
  • the Plateau and Gap elements within the Implementation and Migration extension.

The vendors who want to support the newly introduced extensions the language will be posed to some challenges with respect to implementation of the ArchiMate metamodel. I assume this to be a challenge because the linkage between the motivational aspects and the core elements and the implementation/migration concepts and the core elements respectively is required to be highly flexible.

The Plateau and Gap elements of the Implementation and Migration extension are to my mind a bad approach to model different architectures (e.g. as is, to be and transition architectures).

But later more on that…

Upcoming Webinar on Working with Flexible EA Metamodels

Avolution will host a webinar on behalf of the The Open Group entitled: ‘Hybrid EA frameworks – TOGAF® 9.1 + ArchiMate® + BPMN + MoDAF/DoDAF = TOGAF®+?‘. Join this hands-on webinar to learn how easy your EA metamodel can be extended and changed when using Avolution’s enterprise modelling solution ABACUS®. I’ve been using the solution ABACUS® for a while. To my mind Avolution is revolutionizing the EA tool market due to its metrics-based approach and unlimited flexibility related to the EA metamodel. But have a look by yourself…