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
Enterprise Architecture Software
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.
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.
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?
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.
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.
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.
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.
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.
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.
I am very excited to announce the new version of Enterprise Studio and an all new Web Portal. This release includes many new capabilities making our software suite more powerful than ever. Next to our excellent modeling, repository and analysis capabilities (top in the market according to Gartner*), our software suite now includes a state-of-the-art Portal. The visualization, analysis and collaboration capabilities enable a much wider range of stakeholders to gain insights across the enterprise, covering a broad range of transformation stakeholders. We proudly name our Portal HoriZZon. 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?
Strategists, architects, process experts, software developers, data managers and other professionals involved in changing the enterprise often put substantial effort in creating all kinds of useful models of their designs. In many cases, such business models, enterprise architecture models, business process models, software models, data models and more are only used to specify some design, i.e., to describe what should be built. But there is much more value to be had from these models, by using powerful analysis techniques to create new insights. Read more
In my previous blog I wrote about the importance of models to successfully complete a merger, acquisition or divestiture. Of course, one organization’s divestiture may be another one’s acquisition. In this blog post I’ll share one my personal experiences as a consultant, supporting two government agencies that were in the middle of this process.
Organizations involved in major strategic changes such as mergers, acquisitions and divestitures often focus mostly on the financial and market aspects of the change. What is the impact on your market share? How can you increase buying power from your suppliers? What cost savings can be realized by exploiting synergies? Read more
When I give a presentation to a technical audience showing any kind of picture with an arrow in it (not necessarily an ArchiMate diagram), more often than not, someone will raise their hand and ask: “What does that arrow mean?” When I answer, they will follow up with “Shouldn’t it be the other way round?” Read more
When we think about supporting Business Transformation, we immediately start with the detail. Architects and analysts dive into the nuts and bolts, create some brilliant ‘technical designs’ and models but to non-architects, it often appears as “just boxes and lines”. In this blog I will explain some simple techniques to help bridge the gap.