Excessive complexity is something that most organizations over a certain size have to deal with. The more successful you are, the bigger the enterprise gets, and the farther removed it gradually becomes from the original core tenets that probably made it successful in the first place. So how does this hurt a company? Well, if we’re talking about the IT estate, erratic expansion and the resulting unmanaged complexity makes its presence felt in the form of higher IT management costs, increased risk, and a slow rate of innovation.
Across the globe, Enterprise Architecture teams deliver three key organizational functions. Firstly, they provide understanding of their current organization; this enables the organization to effectively control and regulate its existing operating model. Secondly, those teams provide a window into the organization’s potential, insight into where value can be found and unlocked, and an insight into the future. Thirdly, EA teams drive, enable and support the iterative improvement of this direction setting insight, and with that they translate strategy into reality, creating real business value.
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 used to support this goal 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.
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 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.
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.
In our previous blog post, we outlined why Enterprise Architecture and Agile/DevOps are key in becoming an adaptive enterprise. We also described several use cases where EA can strengthen Agile and DevOps practices. Now, we want to focus on the ways in which you can connect these in practice, using architecture models and appropriate tool support.
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
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.
In my previous blog post, I described the new EU General Data Protection Regulation (GDPR) that will go into effect in May 2018, and I outlined its profound effects on organizations, not just in Europe but around the globe. This regulation, and related EU Directives such as the ePrivacy Directive and the Network and Information System Security (NIS) Directive, force organizations to rethink how they deal with personal, privacy-sensitive data. In this blog, I want to address the steps you can take as an architect to help your organization comply with these regulations.
Few companies have a systematic and reliable way of translating their business strategy into action across all relevant parts of the organization. Research on digital transformations by MIT Sloan  distinguishes between the ‘what’ (what does an organization want to achieve) and the ‘how’ Read more
In the past, my colleagues and I have written several blogs on the combination of enterprise architecture and agile ways of working (e.g. Enterprise Architecture and Agile Development: Opposites Attract?, Enterprise Architecture and Innovation: A cultural change, Escaping the Jaws of the Project Monster). In this blog, I want to focus in more detail on the use of the ArchiMate language in the context of agile methods, in particular the Scaled Agile Framework (SAFe). Read more
In many organizations a mythical creature lays deep down in the catacombs, otherwise known as the server rooms. This dark monster has an obsessive-compulsive disorder. Normally these creatures are in search of gold. However, this kind doesn’t fancy gold, this one hoards applications!
Everybody is familiar with the SMART abbreviation. It stand for Specific, Measurable, Acceptable, Realistic and Time bounded. But this blog is not about that kind of SMART. In this blog I will discuss how to apply another type of SMART within the context of Enterprise portfolio management.
Process models are a powerful means to describe, analyze and communicate processes. However, process models are often outdated and underused. The reasons for this differ. Sometimes it seems that people are unable to read and understand models; people do not know the models are available; or content is unrecognized or outdated. Putting effort into the design and the way you publish your models is key to success in handling these issues. This way, the effect of process models can be optimized! So how can you optimally use your process models? In this blog I present five simple steps that help BPM practitioners to realize this.
“Business Process Management is old school; Business Analysis is the new hype”. Huh…? With all terminology and current trends, it is easy to get confused. If you ask five different people to clear things up, you will probably get five different explanations. It is all about definitions. In this blog I will distinguish Business Analysis from Business Process Management. Read more
During Business Process Management trainings, people often ask me about the best modeling technique: How to model a process model? Where do I begin? Top-down or bottom-up process? Questions that many of you have asked yourselves when beginning to design a process model. In this blog I would like to take you along with me to the world of top-down or bottom-up modeling. Let me start by clarifying some frequently used terms. Then, I will share several personal experiences and my preferred method of working.
Very few organizations have a systematic and reliable way of translating a business strategy into action across all relevant elements of the organization. Implementing a long-term plan by successive decomposition, design and realization steps is only possible in stable circumstances. Classical top-down strategy implementation cannot keep up with the transformation speed required in a rapidly changing environment.