In previous blog posts, we have written about various analysis techniques that help you get more value from your models, as well as dashboarding techniques to visualize data in all kinds of ways. These two topics point to a more general theme: the new possibilities you get from enriching your models with various types of external data. We call this Business Intelligence 2.0.
In the two previous installments, we discussed planning and roadmapping in the context of enterprise architecture, and how you can use the concepts of the ArchiMate language to model your roadmaps. We showed how you can model the evolution of your enterprise at coarse-grained level, using concepts such as ArchiMate’s ‘plateau’. In this installment, we will discuss more fine-grained modeling of change in Enterprise Studio. Specifically, we will show you how you can model the lifecycles of individual elements of your architecture. Moreover, our platform supports analysis based on life cycles and the dependencies between elements, for instance, to find conflicts in your transition plans.
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.
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!
– Marc Lankhorst, Fabian Aulkemeier
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.
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 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.
-Nick Reed and Bart Molenkamp
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.
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.
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.
Defining a good strategy is difficult, especially in this rapidly moving digital world. But realizing your strategy is even more complicated. After all, how do you ensure a strategy is implemented in a coordinated, coherent way? How do you manage all of the moving parts?
– By Marc Lankhorst and Fabian Aulkemeier
An enterprise architecture model, or any other model in your business design practice, contains input from numerous actors within your organization. Your architecture’s governance must continuously collect that input, validate its accuracy and retain a record of all interventions to ensure compliance with regulatory requirements, architecture principles, technology standards and other constraints.
In recent years, the concept of ‘value stream’ has become increasingly popular. It is a useful element in the toolbox of business architects, and is advocated in, for example, the Open Group Guide to Value Streams and the BIZBOK® from the Business Architecture Guild®. Though ArchiMate® has had a value mapping element since its inception, until now it does not have a value stream element. In this blog we propose to add a value stream element to ArchiMate in a way that supports approaches such as those described in the Value Stream Guide and the BIZBOK, is coherent with the language structure, and minimizes the impact on the rest of the language.
Information Mapping – Business Blueprints are an essential instrument in every business architect’s toolbox. The Guide to the Business Architecture Body of Knowledge (BIZBOK Guide®) defines four core business architecture domains: Value Streams, Capabilities, Organization and Information.