Our recent blog post on abstraction levels in architecture models resulted in a lively discussion on LinkedIn. As part of that discussion, the notion of layering was questioned, and in particular the layers that are built into the ArchiMate language. In this post I want to clarify the thinking behind the language structure.
In the past I’ve written several blog posts on enterprise architecture in an agile world, most recently together with my colleague Fabian on our tool support for Agile and DevOps, and a bit longer ago on the use of ArchiMate in an agile context. In this blog post, I want to revisit the latter subject and add some newer insights and ideas with SAFe®.
One of the more interesting developments in the tech space taking place right now is the emergence of digital twin technology. For those of you asking What is a digital twin? right now, allow us to elaborate.
Interviews are where jobs are won or lost. A résumé – especially a strong one – will ensure you get your foot in the door but to actually secure the position you need to shine during the interview, which means being prepared. Preparation makes you look knowledgeable and relaxed, two traits that people generally prize in their work colleagues.
In my previous blog post (https://bizzdesign.com/blog/a-pattern-for-sizing-archimate-diagrams) I described why it is useful to reduce complexity when creating architecture diagrams. It supports the architect by guiding the creation of diagrams and it supports the reader by not creating overly complex diagrams (too many different types of concepts). Each viewpoint addresses a specific concern, e.g. a capability map to show what the capabilities of a company are. In this blog I will focus on the application layer to provide practical examples using the viewpoint creation pattern described in the previous blog post. The examples are quite generic. They are meant to be used as a starting point for professionals looking to learn more on the subject so they appeal to a large audience.
Enterprise architecture is often perceived as an abstract, conceptual, and somewhat esoteric discipline practiced by ‘high priests’ who provide guidance with their lofty ‘architecture principles.’ It’s true that architects are often concerned with overarching, cross-cutting concerns that are not always visible to the people ‘in the trenches,’ but this view of enterprise architecture is misguided at best and increasingly misses the mark.
In the previous instalments in this series, we discussed common drivers for architecture in defence and industry, commonalities between the architecture practice in defence and the civil sector, and why the ArchiMate language was chosen as a recommended standard for expressing architectures in the NATO Architecture Framework v4. In this final instalment, we discuss the work that still needs to be done for using ArchiMate in the context of NAF v4.
– Kevin Wallis (MOD ISS) & Marc Lankhorst (BiZZdesign)
In the previous two instalments in this series, on drivers for architecture in defence and industry and on comparing NATO Architecture Framework practice with the civil sector, we described the common drivers for architecture in defence and industry. We also discussed the commonalities between the architecture practice in defence and civil sectors. We noted that collaboration and interoperability in networks of organizations is an increasingly important driver for architecture, and we highlighted the growing use of commercial “off-the-shelf” products in both defence and civil organizations. Where architecture practice is concerned, we also explained how processes are largely similar (as captured, for example, by TOGAF’s Architecture Development Method), that architecture artefacts play an increasingly important role in public procurement and other arenas, and that both worlds are increasingly using reference models to capture commonalities and share knowledge.
In the first instalment of this series, we compared drivers for enterprise architecture in defence and industry and found that there is are increasing commonalities: a growing focus on interoperability and collaboration in complex ecosystems. a blend of the physical and IT worlds, and the preference for “off-the-shelf” products over custom development. These commonalities also lead to increased usage of the same methods and standards for enterprise architecture. In this instalment, we’ll compare the architecture practices of defence and civil sectors.
-Kevin Wallis (MOD ISS) & Marc Lankhorst (BiZZdesign)
In this blog series, we want to update you on the UK Ministry of Defence’s (MOD) use of the ArchiMate modelling language as described in the NATO Architecture Framework version 4, which was officially approved by the NATO Consultation, Command and Control Board (C3B) in January. The document states: “NAF v4 compliant architectures can be created using the following meta-models; The Open Group®’s ArchiMate® and the Object Management Group®’s Unified Architect Framework (UAF)® Domain Meta-Model (DMM)®.” In addition, the approved method for architecture is based on The Open Group’s TOGAF® framework.
In my recent blog series, I highlighted the importance of communication for strategic transformations. This affects several functions and various roles in your organization by asking different questions, such as:
Everyone remotely involved with enterprise architecture and similar disciplines knows the importance of knowing your stakeholders. Stakeholder management is a key technique in EA and many methods, including TOGAF, stress its importance. But there is more to management than keeping individual stakeholders happy. In this blog post, I want to introduce three techniques that not only help you ensure stakeholder satisfaction, but also make good use of stakeholders and their influence in achieving business goals.
In the first blog of this series, I explained how important it is to raise your digital change capability to become an adaptive enterprise. I also highlighted the role of effective communication, as well as approaches to categorize and visualize enterprise architecture descriptions based on the TOGAF and ArchiMate standards. In this series, I also included guidance on which approach to select for modeling Architecture and Solution Building Blocks (both are types of logical or physical components). To round out this series, I will end by discussing the connection to Deployed Solutions.
Previously, I have written about the use of a modeling language and the practical usage of the TOGAF Enterprise Continuum to classify architectural descriptions along different levels of abstraction. In this blog, I’m going to demonstrate how the content of these descriptions can be visualized with a standard notation. While TOGAF 9.1 provides the standard architecture development method (ADM), ArchiMate is the worldwide standard to model and visualize the content of enterprise architectures. Both are a public standard of The Open Group.
Previously, I wrote about the need to digitize change capabilities and how enterprise architecture can support and provide value to your organization. I also discussed how to categorize architecture descriptions along different levels of abstraction. But there is one dimension I didn’t dive into: How generic or specific is the architecture description compared to your organization?
Adaptive Enterprise – We are currently living in an interesting time. The digitization of all business capabilities has reached a new level and has had a huge impact on virtually every industry. Business models are being redefined and new companies have emerged to become global players. Today, companies must be more agile than ever before and the speed of change will only continue to increase.
Since the release of ArchiMate 3.0 last June, my colleagues and I have written a series of blog posts about combining ArchiMate with other standards, methods and modeling techniques. This post summarizes what we have shown you.