 Please a big warm welcome for Klaus Nieman. Thank you very much. So good morning, and welcome to my presentation on the Enterprise Architecture Digital Readiness Framework, which we developed over the last two years. I would like to share some insights, some ideas, some findings from studies we did based on that framework. First, let me show how we got there, where we are right now. I had the opportunity to guide a major joint venture project in 2016. This was set up by nine companies from Germany and Switzerland. And the working title for this project was Agile EA. But all of these enterprises had very extensive experience with Enterprise Architecture. So they had like 10, 15, 20 years practice within Enterprise Architecture. And all of them were facing the challenge of aligning Enterprise Architecture with digital transformation. So this project gave us the chance to derive several case studies from the project. And based on these results, we developed in 2017, we developed the Enterprise Architecture Readiness Framework, which we used to perform a study on digital fitness of EA organizations. We pre-tested the framework with six guided interviews and then put it online. Now it's like three, four months, it's online. And we have about 100 data sets gathered through that period of time and evaluated that results. And I would like to share some of those results with you. We did some data analysis on that. We did some deep dives with respect to specific findings. We tried to derive some guidelines and recommendations from the study in order to improve digital readiness of EA organizations. So first step will be to look a little bit on those case studies, three major findings. The acronym VUCA, the Volatility, Uncertainty, Complexity, and Ambiguity best describes what is happening around Enterprise Architecture right now from one of our case studies. Or more than one of our case studies, we learned that. And we feel that Enterprise Architecture is somehow asked to find answers to these challenges and should find a way to replace this VUCA world by the so-called VUCA antipodes, which are typically called vision understanding, clarity, and agility. This overall situation imposes very much of impacts to the Enterprise Architecture practice in particular on the IT department as well. So this was more or less one of the first findings from the case study. A second finding was that we have new customers and channels, we have new requirements that we need to address within Enterprise Architecture practice. There are some of the well-known customers, like the plan-build-run people within the IT department. And there are also new customers in the IT department, like, for example, scrum masters or innovation managers. And there are some well-known customers in the business department as well. And we find some new customers or potential customers in the business area, like the chief digital officer or one of my favorite quotes that be gathered from that, a quote from a CEO who said, whenever they show up, the Enterprise Architects, it gets expensive and longstanding. By the way, did you ever hear somebody say, hey, you fireman when you are around, something is burning and somebody will be hurt? Something like that. The third finding from those case studies is about the role of architecture in the world where IT gets more and more a commodity. And IT spendings are not only decided upon within the IT department, but in business as well. So the classical IT budget, 70% IT operations, 30% for adaptive and corrective maintenance and development is now amended by IT spendings, which are not decided within the IT department but in business departments. And they typically don't ask enterprise architecture about their investments. They simply do it. And so enterprise architecture has to find a way to play a role within this situation. So the major findings, three major findings from the case studies we did in 2016, speed innovation capacity are challenges for architecture in a VUCA world. New customers and channels produce new requirements. And the third finding, whenever this thing will work, a large portion of the future IT landscape is shaped by non-IT units. Architecture needs to play a part in that. So based on those findings and several other findings that we had within those case studies and the project, we started out in 2017 to develop the framework to evaluate digital readiness of EA organizations. The framework consists of 11 influencing factors. We differentiate on extrinsic factors, which are given and partially influenceable, where we have the relevance of digitalization within the enterprise. We have the EA mandate, and we have the EA customers and the markets we are focusing on. By the way, in this presentation, we think about enterprise architecture more or less in terms of a profit center, looking at the rest of the enterprise and looking at customers, which we deliver services for. Then we have a second element, which we call acceptance factors, where we have market channels, and we have the EA value proposition. And we have a third category of factors, the intrinsic factors, which are the foundation for digital readiness, and they must be shaped under EA's responsibility. In this part, we find services, which we use to structure our methods and tools, the information we are managing, and the organization that we set up to provide those services. We also have communication skills and feedback culture within this sector, and we have the self-conception of the enterprise architects in the organization. The overall framework was developed in terms of thinking writing a letter to the chief architect, like, dear chief architect, did you open new market channels in order to address new customer groups, such as business development, a chief digital officer, is your value proposition aligned to the requirements of the digital age, our communication skills, and feedback culture in place, are your EA services. You are underlying methods and tools, your organization in place for the digital age, and is your EA organization aligned to digital transformation. And finally, does the self-conception of your architects reflect the needs of digitalization? So based on that, we structured a questionnaire around those 11 factors. We set up 50 questions with five options each. And as I mentioned before, right now, we have like 100 data sets derived from the online questionnaire, from guided interviews, and from some sessions that we were setting up directly, so-called, ask me anything sessions. So some of the results at a glance, as you can see from this chart, the market channels and the customers in the markets seem to be pretty good aligned with the needs of the digital age. But on the other hand, communication skills, and feedback culture, and services seem to be still under development in terms of digital transformation. Let's look at that from a little different perspective. If you look at the relevance of digitalization within those enterprises, then we found that all of the enterprises we asked told us that they have a very high relevance of digitalization. So this doesn't distinguish between all these enterprises. So we focused on the other 11 factors on our search for optimization potentials within those factors. The customers and markets and the market channels seem to be very high aligned with the requirements of the digital age. The EA mandate, so that's what we get from the outside, from others. Oops. Sorry. This is, here we are. So the mandate seemed to have a high alignment with digital requirements. Methods, tools, information, and self-conception do have a medium alignment to requirements from digitalization. The EA value proposition and the organization of the Enterprise Architecture Department itself seem to be low. And the communication skills and the feedback culture as well as the services seem to be very low in terms of requirements of digitalization. So whenever I talk about we, it means the majority of those 100 enterprises we surveyed within the study. And I would like to show some exemplary questions that we asked aligned with the results we found on those questions. The first of this question was, do we have the mandate to enable and drive digitalization? Second question was, do we address the right customers to the right extent? We used this so-called transformation driver portfolio, which we developed in our practice, to analyze these areas. The transformation driver portfolio expands over operations and strategy and IT and business. So we identified four domains where we typically find transformation drivers and practice areas for the Enterprise Architecture, which are housekeeping demands from the IT landscape, demands, operational demands from the business, technical innovations, the need to innovate technology, and business model innovations. So in terms of this question, we asked those 100 companies whether they operate in all these four practice areas or they don't. The third question that we asked is, do we know our customer's job? We used the value proposition mapping from strategizer to analyze this question. On the right-hand side, you find typically the jobs of your customers, their pains and their gains. On the left-hand side, you find the products and services that you as an Enterprise architect offer and the gain creators and pain relievers that are defined by the Enterprise Architecture practice in order to help the customers. The fourth question we asked was, do we understand the business? We used our business architecture structure to analyze this question. We have a three-layer business architecture model with business motivation, where you typically find mission and vision and goals and strategy and drivers and things like that. We have the business model, where we find our value proposition, where we find our products, our markets, our channels, our partnerships. And we have the business operation layer, where we typically find capabilities, processes, functions, information, and organization, which the Enterprise typically sets up to drive the business model and to support the business motivation. The fifth question that we asked was, do we provide help and initial acceleration for digitalization projects in order to analyze this question? We used our standards portfolio, which is a portfolio which is set up by three layers, business application and infrastructure standards. And we also have four columns, building blocks, patterns, methodologies, and directives. These are used to indicate the strengths of a standard, strengths, declines from left to right. So typically, building blocks are blocks that you can directly use, and they are pretty strong, defined, and directives, such as principles, are much more weak. The sixth question that we asked was, do we really acknowledge feedback? The answers that we got from these questions, do we have the mandate to enable and drive digitalization? So like 80% of all of those enterprises that we asked felt that they had the right mandate. The second question, do we address the right customers to the right extent? Remember this transformation driver portfolio? So based on that question, we found that around 80% of the enterprise architects, which answered our questionnaire, felt that they really address the right customers to the right extent. But do we know our customers' jobs? And related to this question, we found that 70% of our enterprise architects did not know all pains of our customers, or they didn't focus their services on the pains of their customers and the jobs of their customers. Do we understand the business? We found that around 60% of all the enterprise architecture practices we talked to do not have proficient knowledge about methodologies for business modeling or business motivation modeling. They know about methods for business operations modeling, but nothing about or not very much about business modeling and business motivation modeling. Fifth question, do we provide help and initial acceleration for digitalization projects? Oops, sorry. 40% of all the enterprises did not adjust their standards or their portfolio at all in relation to digitalization projects. And the sixth question, do we really acknowledge feedback? 60% of all the organizations do not evaluate feedback, or they only do it on occasion. So the major findings from the digital readiness study in on this slide, we do have the right mandate. We do address the right customers, but we do not know too much about our customers. We are not proficient enough to understand the business and facilitate business innovation. We do not provide sufficient help and initial acceleration for digitalization projects, and we do not really acknowledge feedback from our customers. That's what we found within the study. Some individual statements, just to put that into the right corner. There was an individual statement from a chief architect of a media and publishing group. New EA customer groups, such as business development, CDOs, business partners are not even addressed. Good methods and tools, but weak service definition. We need to put the power on the pavement. A true customer relationship in channels do not match a weak value proposition. There's more tinsel and glitter. And our mandate doesn't allow for experiments. We are not allowed to create new standards. And the last statement, we don't like to see architects around here. They don't talk business as much as we are required. That's a statement of a chief of a digital lab that we visited during the study. The guidelines and recommendations that we derived from that are more or less on four pages. How to put that into execution, adopt business architecture toolset, manage heuristics, set up architecture engineering, and align EA value proposition. Just a short look at those four recommendations. Our first idea on that was to adopt or set up a toolset for the early stages of new initiatives. We did that with something we called the MIPRO toolset. For the creation of new ideas, the development of new business models, the implementation and test of those business models before we go into normal operation, we adopted a set of proven and well-known methods from business creativity, business modeling, future sciences. We described those methods. We found some heuristics when to use those methods and how to use those methods and created a set of templates in order to adopt those methods. The second topic is manage heuristics. Architecture delivers heuristics based on proven solutions. One of the questions that we found very, very often during the study was how about governance when discussing the digital readiness. Who is going to take care of our standards if we go agile, for example? If you look at that process of standardization and using standards, then we typically answer the best thing is not to standardize and communicate about standards. We should not discard this standards portfolio, but we should think about the way how we communicate standards. So instead of communicating a standard whenever a customer approaches you and is looking for a solution, it's much better to communicate the solution aligned with the heuristics that originally led to the standard. A good standard portfolio will typically help us to find the right solution whenever you not only manage the standards, but also the heuristics which helped to define those standards. So whenever you communicate instead of standards, heuristics and solutions in the process of communicating with your customers, and whenever you will use your architecture repository to document those heuristics, not only the standards, then this whole process of communicating standards will be much easier. Architecture extends a proven engineering methodology for solution architecture development. It's a third action we are talking about. We are thinking about an iterative tool set to construct solution architectures based on heuristics. I have a vision for many years now. This is like having an engineering handbook, like civil engineers or mechanical engineers have where you find best practices and heuristics and things like that. And the solution architecture process should more or less be based on something like this engineering handbook. So if you look at solution architecture and if you ask yourself the question how good the solution architecture is supported in the community, there are only a few tool sets. There are only a few training sessions dedicated especially to solution architecture. But from our practice, we would say it's about 80% of the overall architecture work that is done within a specific enterprise, which is solution architecture. The rest might be strategic planning and enterprise architecture and standards management. But the major part of this architecture word is solution architecture. So I think it's much more worth the time of developing such an engineering handbook, although it's a vision. As you see, I do not agree with the famous quote of a firm former German chancellor who said the one who has visions should see the doctor. That is more or less not valid for this case. So an iterative process based on identifying requirements, using heuristic testing solution ideas, and developing solutions. This does not work. And the last step, align the value proposition. Architecture delivers a clear customer-specific value proposition aligned by continuous feedback. As you heard from a former slide, we used this value proposition canvas. I have an example here for the chief digital officer with the typical jobs of a chief digital officer, the pains and the gains that this chief digital officer typically suffers from, the pain relievers, the gain creators, and the products and services, which are typically offered by enterprise architects to define a value proposition in order to support the chief digital officer, which must be combined with the feedback process to realign this value proposition over the time. So we have four optimization potentials, knowledge about EA customers, proficiency in business architecture, sufficient help and initial acceleration for digitalization, and feedback, feedback culture. And we have those four approaches, which align with the optimization potentials. And to close this session with one statement, what we can learn from others, I think it's a real challenge to improve enterprise architecture and to align enterprise architecture management with those challenges from digital transformation. But as we can learn from others, speed, agility, flexibility on the one hand side, and stability, and safety on the other hand side, they can come together and they can be combined. And so can we do it in enterprise architecture from my understanding. So thank you very much for listening. Thank you very much, Klaus. If you take a seat, we do have a few questions have come in. First question, does your survey include government organizations who have a major driver as mandate requirements? Yeah, actually, there were some government organizations. And in fact, one of the organizations which had a very high degree of digital readiness was an IT service center for government organization. OK. Given what you've learned, the question just reads, so what's the future for EA teams? The future for EA teams, yeah. Actually, that's a working title that we are working on right now. The future for EA teams, as I mentioned during the presentation, there is this vision that I share with my colleagues for many years. This bridging the gap, how the open group calls it, like 20% in strategic architecture work and 80% in solution architecture work. The future of EA, I think, is more and more integrating those both ideas and getting an overall architecture practice within the enterprise and dedicating the whole thing to execution, which is most important. Enterprise architecture without having this lever into execution doesn't work at all. Why wouldn't you make standards easy to consume in a catalog? The IT for IT request to fulfill value stream, for example, addresses this requirement? Yeah, this is more or less a question of history. We developed that standard portfolio in 1998, so long before we talked about IT for IT. So there is something to maybe look at there to update. How mature do you consider the EA solution market to support the end-to-end EA activities for the digital enterprise? Excuse me. How mature do you consider the EA solution market to support end-to-end EA activities in the digital enterprise? Yeah, the EA solution market. I mean, there has happened many over the last couple of years. We still have many tools which are able to support both operational architecture and strategic architecture management, solution architecture as well as enterprise architecture. The tools which came up the last two, three years, they focus more or less from my understanding what I see on the strategic end of architecture management. So somehow it's more or less the other way around. The tools go in the direction which the practice should not follow. So I think it's better to think about tool environments here. And last question, what is your vision from a tools and methods perspective to operationalize the EA framework you described? The readiness framework. Yeah, it's more or less, it's a questionnaire and we already implemented it on one of the tools that we use with our customers. So it's a potential to do that and use the questionnaire in that term. I know you referred to it being online as well. Yes, unfortunately it's German still because we focus on the German market, but we'll change that. Thank you very much. Thank you. Thank you.