The promise of enterprise architecture is that it helps improve decision making. Typically, the role of the enterprise architect is to advise and enable other stakeholders to make better decisions. Therefore, Enterprise Architecture – more than anything else – is a social discipline, in that it demands social skills and interaction in order for practitioners to successfully engage with stakeholders and change their behavior. Read more
Business Process Management
In our previous blog post on planning and roadmapping, we discussed the general idea of planning and roadmapping in the context of enterprise architecture and capability-based planning. We addressed different levels of roadmaps, ranging from short-term sprints of a few weeks to long-term, multi-year roadmaps. We also provided some first insights into the use of ArchiMate concepts for modeling roadmaps. In this installment, we want to go deeper into different ways of modeling the evolution of your architecture.
A key driver for management in general and enterprise architecture in particular is to get a better grip on the future, on the evolution of your enterprise. A common technique to support this is roadmapping. A roadmap is a strategic plan that shows the main steps or milestones needed to achieve a desired outcome. It articulates the strategic direction of your enterprise and shows the path forward. It helps you identify what is needed and what the main dependencies and priorities are, and serves as a communication instrument to align the organization along a common course of action.
– Marc Lankhorst, Fabian Aulkemeier
In a previous blog post on the features of our collaboration platform, we have explained how you can support people in working together on architectures and other models via structured workflows. In that post, we looked ahead at future features to support this kind of collaboration. Time to update you on the latest developments!
In my recent blog post on stakeholder communication, I described various basic forms of communication about architecture, with diagrams, tables, heatmaps and the like. What I did not touch upon in that post is how you can enrich your architecture (and other) models with additional data and display the results in various dashboards. That is the topic of this post.
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.
-Nick Reed and Bart Molenkamp
In today’s business landscape, effective transformation is critical for enterprises to stay competitive. By definition, transformation happens over time.
Enterprises (or some subsection thereof) have a current state which needs to change for the better. That change – however small or large – results in a different future state. With the widespread adoption of Agile working practices and DevOps-based continuous delivery, these changes can be very small and very frequent.
Marc Lankhorst, Fabian Aulkemeier
Enterprise architecture, agile software development, and DevOps are sometimes seen as being at odds. We think they can fruitfully collaborate and interface, but how do you do that? How can you align the concepts and processes from these worlds and bridge the cultural gap?
Kevin Wallis (MOD ISS) & Marc Lankhorst (BiZZdesign)
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.
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.
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.
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.
In my previous blog post, I described how Enterprise Studio supports the Business Model Canvas, Ecosystem maps, Balanced Scorecards including SWOT, PESTEL and Five Forces analysis, and heatmaps to highlight salient information for your organization. Now, I want to focus on more advanced views and analyses that help you evaluate the viability of your strategy and business models and then take steps towards their implementation.
The effective use of digital technologies is paramount in a competitive environment. To succeed, you don’t need a separate digital strategy; you need a business strategy for the digital age. But digital transformation is difficult to manage because it requires you to change many moving parts of your enterprise, much like redesigning and rebuilding an airplane while in flight.
In the final installment of this blog series, I want to address the domain of risk, security and compliance, an area of increasing importance for architects, process designers and others. As an example, in some previous blogs, I have already outlined the new EU General Data Protection Regulation (GDPR) and its impact. In one of my posts, I used a simple example of data classification and how you can use this to assess your application landscape. Read more
In my previous post, I discussed how you can analyze the business and technical value of your applications, and how architecture models are key in calculating metrics such as the business criticality or strategic value of applications. In this post, I want to focus on financial analyses, and in particular on cost models.
In the previous installment in this blog series, we looked into planning and analyzing change in the enterprise by linking the life cycles of elements such as applications and projects. But how do you decide what to do with, for example, your application landscape? Which applications need to be improved, re-platformed, functionally upgraded, or phased out?