Skip to Content

Tooling around with TOGAF and ARIS (part I)

In the following blog series, we will talk about one of the most sensitive questions for Architects: how to maintain and make Enterprise Architecture artifacts really useful for the customer.  Our intent is to show how to make them really valuable to customers who spend a considerable amount of energy and resources in assembling comprehensive architectural and landscape information and have to make it available in a consistent and enterprise-wide manner. We are going to examine one of the most widespread IT and process modeling and repository-maintenance tools – the ARIS Suite, and how it can be used to maintain a TOGAF architectural repository, using ARIS TOGAF content. We’ll also discuss some tips about implementing a best practice architectural repository and illustrate this with examples, and a real-life customer case study. This series is not meant to be an introduction to TOGAF or Enterprise Architecture in general, so the reader is required to have some knowledge on the subject.

For too many customers, Enterprise Architecture becomes an interesting discipline once they are able to see how their Business, Information Systems, and Technology architecture all interrelate with each other.  Customers would like to understand, for example, what the impact on a process or KPI when a technology element fails, or a system has to be stopped and upgraded, is, and, likewise, how the realization of a strategic business objective translates into application, and technology requirements and projects; and, then, how to plan the architectural evolution and overall IT governance. This means that as important as is the EA method itself, the creation and maintenance of easy-to-use, comprehensive architecture artifacts through the right tools plays an important role in implementing this practice.  That is a very influential aspect for Enterprise Architecture adoption and often weights a lot in the “go-forward” decision.

TOGAF 8.1.1 is known as being more of a method-oriented – driven by the architecture construction method, its development phases and “how-to-do” scheme – than an artifact-oriented – driven by the description and interrelation of the artifacts that should be produced for the architecture to convey accurate and useful information (the “what-to-do” content) – Enterprise Architecture framework, of which the Zachman framework is a good example. That condition somewhat changed with the advent of TOGAF 9, when the addition of new content by the consortium participants, especially SAP with its SAP EAF, made TOGAF more artifact-aware.  With that, we see the introduction of the Architecture Content Framework (ACF) involving concepts as Catalogs, Views and Matrices and architecture meta-model.  Another noteworthy improvement was that of the Architecture Development Method (ADM), with a new iterative approach, and better, more precise narratives for several of its phases, for instance phases E (Opportunities and Solutions) and F (Migration Planning).

TOGAF does not prescribe any tool of choice for managing architectural artifacts, but it does provide a number of guiding principles that compliant tools should follow. Attempting to realize an EA framework without a sufficiently sophisticated tool may well be lower cost in the short term, but SAP has repeated seen that the consequences of this approach are siloed working, duplication of effort, a higher cost of governance and increased levels of unnecessary customization.

In our following blogs we will focus on:

  • Tooling around with TOGAF and ARIS (part II);
  • TOGAF and how it was used to document and maintain the Business, Application and Technology architectures of one of the biggest companies in Brazil
  • Managing architectural artifact tools in real project world.

I would like to thank Matthias Ledwon, Stephen Wood, Sascha Kuhlmann and especially Alexandra Weber for their invaluable help to make this blog possible.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.