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.
Previously, I have blogged about stakeholder management and showed you some useful techniques to support this important part of enterprise architecture. In this blog post, I want to address different ways to share architecture information with different types of stakeholders involved in changing your enterprise.
Artificial Intelligence (AI) seems to be a buzzword lately, promising techniques and tools that could influence our lives, our work and the way we do business. For many designers and enterprise architects, the question becomes: What would be the role of designers on all levels (strategic, EA, BPM, data, technical) in incorporating AI in a company? There are even ethical questions that may arise when instituting AI in a company, which you must take into account before making the change.
Humans have evolved to make fast decisions. For example, when a stranger approaches you, you know almost instantaneously if they represent a threat, if they are angry, friendly or happy. The cognitive processing involved is mind-boggling if we actually stopped to think about it (which we don’t).
We subconsciously process a myriad of information, such as the person’s stance and their facial expression, and make a decision in a split second about whether this stranger represents a threat or opportunity. Or, in the language of evolution, we decide “Which one of us is lunch?” and “What am I going to do about it?”
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.
Large architectures of big organizations can become quite large and complicated, posing a challenge for the architects developing and maintaining them. In previous discussions, we have addressed a number of techniques for organizing and controlling such large models to keep things manageable. In this installment, we look at the processes and practices you can use to optimize the collaboration between the people working on these architectures.
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.
In the previous installment of this architecture models series, I wrote about organizing your model repository according to business, information and technology domains. I also explained the need to create separate current- and future-state models, and the separation between and model content and views. In this part of the series, I have a few more things to add on the topic of naming and modeling conventions, as well as advice on how to set up governance and quality assurance structure around your models.
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.
If you have some experience in modeling real-life, full-size architectures for large-scale organizations – preferably in the ArchiMate language, of course – you have likely come across the challenge of organizing your models in logical and manageable ways. In this two-part series, we’re going to share our top 6 ways to organize your architecture models. These six methods should help you keep your models neat and tidy while also supporting better outcomes for your strategic initiatives.
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?
Cybersecurity threats are ever increasing. It is sometimes said there are two kinds of organizations: those who know they have been breached, and those who don’t know it yet. To mitigate the risk and damage associated with cybersecurity, it’s important to know how to assess these risks and improve your defenses via security-by-design. It’s also important to plan for what to do if (and when) things do go sideways.
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.
In modern enterprises, change is no longer a simple, top-down affair. All levels of the organization need to be involved, and everyone from shop-floor employees to the CEO need to work on local improvements to business processes. Lean projects and agile product development teams must rapidly innovate digital environments, strategists need to invent and experiment with new business models, project and program portfolio managers have to decide on investment allocations, and those responsible for domains like risk management and regulatory compliance have to do their part. This “all hands on deck” approach requires enterprise-wide transparency and visibility of plans, structures, opportunities and constraints.