Artificial intelligence (AI) is probably the most important new technology today. It has clear use cases, and the value that it’s produced so far is indisputable – just think of the digital assistant on your phone, driverless cars, even Gmail uses it. But it’s no longer the sole remit of huge tech companies. With AI becoming more established, many organizations are starting to get access to and try their hand at running artificial intelligence initiatives. The business world is after all similar to an arms race, and having the latest ‘weapon’ to help you get ahead of competitors is an irresistible prospect. The forecast? A large wave of new AI deployments in the near future… and with it, a lot of heartache.
Making the case for Enterprise Architecture in your organization is not always straightforward. That’s because management and, generally speaking, business stakeholders tend to want numbers up front, which is impossible to calculate beforehand. Now, there are plenty of studies that have been done that prove the value of Enterprise Architecture, but that’s only possible after engaging in the practice.
Today, organizations need to move at speed and adapt their business to a volatile environment, while at the same time dealing with many inside and outside stakeholders and influences, ranging from customers and partners in the ecosystem to regulators, competitors, and the uncertain effects of politics (viz. Brexit or the US-China trade war). To be an adaptive enterprise, business architecture is an indispensable discipline. Without an architectural approach to your business, you will quickly get mired in the myriad changes and effects, without a clear path forward.
It seems like an unlikely pair, doesn’t it – Agile and Enterprise Architecture? Yet, as Agile awakens to the reality of having to move fast but in concert with other parts of the organization, and EA itself becomes more engaging and business goals-oriented, it actually makes a lot of sense to want to combine the two. Both practices bring significant benefits to an organization. Together they promise to unlock efficiencies that would increase business performance to a whole new level. Who could say no to a mix of organizational agility and solid strategic decision making? That would boost any business or digital initiative.
Much of what we do in the world of enterprise architecture and business process management is based on pre-defined analysis and design techniques, like a game that has a well-defined set of rules and operates within a bounded, predictable universe. You know what the aim of the game is (check-mate your opponent, or reduce the cost of your application landscape, for example) and follow the rules to get the optimal outcome.
Enterprise architecture done well holds terrific benefits for organizations dealing with the challenges of an increasingly digital world. All enterprise architecture initiatives are not created equal, however. While some grow and develop into important business success enablers, others may simply flounder after a while.
Application Programming Interfaces (APIs) have emerged in recent years as a key enabler of digital transformation and enterprise agility.
By defining and deploying APIs, senior IT leadership can increase the responsiveness and adaptability of IT systems – both legacy and modern – by linking applications and data faster and more effectively. This enables a de-coupling between Agile ways of working for systems of engagement – the “front end” applications used by end users, where user experience and responsiveness are vital – and the more highly governed working practices for “back end” systems of record that often still underpin core capabilities of the enterprise.
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.
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.
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.
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 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 BiZZdesign 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.
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
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.