Architecture, Technology, and Digital Roadmap

TOGAF 10 was recently released. Major changes to the old version include a restructuring of the content to allow for easier understanding, fewer inconsistencies, and fewer duplications. The modularization of the content has progressed as well. There are now six individual documents forming the TOGAF Fundamental content and currently 23 more documents in the TOGAF Series Guides. Similar to a microservices architecture, this allows for single content pieces to be used or amended easier and new content to be quickly added as well. The TOGAF Standard now officially includes the TOGAF Series Guides which have been added to the library throughout the last years. While this seems a minor change at first, it means that the TOGAF Standard has now content that is subject to much shorter release and update cycles. The Open Group already stated that this will be the case in the future. In addition, the new version provides an updated and more elaborated view on central topics, such as information and master data management, agility, resilience, and adaptability. Last but not least, the TOGAF glossary content has received an update. Definitions have been added, changed, or removed.

Why Was a New TOGAF Version 10 Necessary?

A major critique about TOGAF was that it contained quite old content that in large parts was outdated. For instance, older versions did not address Digitalization, Cloud, and Agile topics sufficiently or from a decade-old perspective. Also, the TOGAF Standard was hard to read, way too long, and had a rather monolithic structure. The TOGAF Standard was hardly changed in version 9.2, but new and more modern content was established via series guides and added to The Open Group Library. In consequence, those sources, besides content from other organizations and companies, became much more relevant as input for architecture work. It is great to see that The Open Group addressed many of those critiques with version 10.

How Does TOGAF 10 Change the Relevance of the TOGAF Standard?

I analyzed the relevance of TOGAF 9.2 in detail in another few posts. My conclusion showed mixed results with particular aspects of TOGAF being outdated and others still relevant. Fundamental TOGAF Content Content that I believe is still relevant today is mainly about the fundamental architectural approach, frameworks, metamodel, and governance. Reviewing the fundamental content of TOGAF reveals that this content makes up for the largest parts in the new version. TOGAF 10 Certification In terms of signaling through a TOGAF 10 certification, I don’t think that anything changed. For Enterprise Architects seeking new job opportunities, having a TOGAF certification has always been very beneficial. The new release will not change anything for the better, or the worse. TOGAF 10 Content Updates A lot of content that I perceived to be outdated has been updated in the new version, such as content about Digital and Agile. Both topics have a dedicated series guide now. In addition, topics such as privacy, architecture services, architecture alternatives, and business scenarios received additional sections or descriptions. I find it especially valuable that the TOGAF Glossary has been updated. For many organizations, even those that don't strictly follow TOGAF standards, the definitions build the foundation for their organization-wide alignments and common basis. It is good to see that those are now up to date and compatible with today´s IT environments. Business and IT Audience in TOGAF 10 Last but not least, the new release specifies the audience of the TOGAF Standard. Different roles are addressed separately to customize their individual experience with the content. These include Enterprise Architecture practitioners, leaders of Enterprise Architecture teams, and sponsors of Enterprise Architecture teams. This has been a good idea because Enterprise Architecture becomes more and more omnipresent in organizations and business stakeholders nowadays actively execute Enterprise Architecture activities. If you are part of such a team, I recommend to have a fundamental knowledge about TOGAF.

Is TOGAF 10 Worth It?

On the 25th of April, 2022, The Open Group released the TOGAF version 10. This is a major milestone not only for The Open Group but for the whole Enterprise Architecture industry and all practitioners. Being the go-to standard for Enterprise Architects, the tenth version of "The Standard" has been desired for a long time. It also has to meet high expectations.

Who is Behind The TOGAF Standard 10?

The publisher of TOGAF 10 is The Open Group, a global consortium developing open, vendor-neutral technology standards and certifications. The Open Group members come from many large, global organizations from different industries, including IBM, Oracle, Huawei, and Philips. This ensures that frameworks and best practices developed are also relevant across industries. All in all, TOGAF is the most important source for Enterprise Architecture content that one may consult.

The History of TOGAF - What´s the Significance of the TOGAF 10 Release?

The first version of TOGAF was released in 1995. Version 9, the last major update, was released in 2011. In 2018, a minor update was released as version 9.2. Being a minor release, version 9.2 did by far not sufficiently address the tremendous changes that happened in and around IT in the last decade. In 2018, I analyzed the changes between TOGAF version 9.1 and 9.2. I concluded that few substantial improvements had been made to address the Digital Transformation as a whole. As a result, the importance of TOGAF declined, new sources for Enterprise Architecture best practices emerged, and especially questions about topics such as Digitalization, Cloud Computing, or Agility were answered by other sources than TOGAF. Still, everyone waited for the next big release of the TOGAF version 10, to provide answers to those questions from their perspective. The release of the TOGAF version 10 on the 25th of April, 2022 marks a significant milestone for The Open Group and the whole Enterprise Architecture community.

What is TOGAF 10?

Above all else, version 10 of TOGAF is a restructuring of the Enterprise Architecture content to make the Standard easier to read, consume, and also to manage, and update. The key to this is a further modularization of the content. This modularization already started with version 9.2, where the TOGAF series guides were initially introduced to provide additional content on topics that change more often and become outdated quickly. In contrast, the TOGAF Standard size was reduced from over 692 to 532 pages and only contained content that is pretty stable over time and does not need to be completely changed every few years. With version 10, The Open Group went further down this path. More content has been removed from the core content and added to the TOGAF series guides. In addition, the TOGAF Library, which holds further, quite useful content and has been continuously growing over the past years, has been officially added to the overall TOGAF content overview. The result is a picture that looks like an onion and has the most stable content in the center and quicker changing content in the outer layers.

The Content of TOGAF 10

The TOGAF Fundamental Content is split into 6 separate documents, which are: - Introduction and Core Concepts (88 pages) - Architecture Development Method (ADM) (154 pages) - ADM Techniques (88 pages) - Applying the ADM (36 pages) - Architecture Content (120 pages) - Enterprise Architecture Capability and Governance (64 pages) In addition, the TOGAF Series Guides cover lots of content that previously has been in the Standard itself, but is now published as a separate guide. In addition, there have been completely new guides added - a few of them already in the past months: - Business Architecture - Information Architecture - Security Architecture - Enterprise Architecture/Agile Architecture - Enterprise Architecture/Digital Enterprise - Technology Architecture - MSA/SOA Architecture - Adapting the ADM - ... Last but not least, the TOGAF library contains further documents supporting the TOGAF Fundamental Content and the TOGAF Series Guides. For instance, the library includes different translations, guidelines for specific industries (e.g., capability maps), and more subjective documents, as well as whitepapers, webinars, study guides, and reference cards.

What is New in TOGAF 10?

According to The Open Group, most changes to TOGAF address the restructuring of the content into modular pieces of digestible documentation. However, this is not the only notable change. I did not have the chance yet to go through all the content in detail. However, after first studying the new material, I noted the following changes in particular: TOGAF Series Guides are now Part of the TOGAF 10 Standard While in 9.2, there was the TOGAF Standard and the TOGAF Series Guides, the latter is now an official part of the TOGAF Standard. While the TOGAF Series Guides previously were further supporting material outside the Standard, this role is now taken by the broader TOGAF Library, providing further, faster changing, content. TOGAF Architecture Layers are Moved to The Series Guides A major aspect of the old TOGAF was the explanation of the different layers. In version 10, the layers of business architecture, information architecture, and technology architecture are moved to the series guides. As part of business architecture, the topic of business capabilities moved from the fundamental content into the series guide. This underlines the intention to move topics that might be less stable (e.g., definitions, importance, approach) into the series guides and out of the fundamental content. Security Architecture Becomes an Incremental Part The topic of security architecture has been added to the same level of importance as the other architecture layers. Yet, it has not been added to the Architecture Development Method (ADM). Digital and Agile are Now Part of TOGAF 10 More modern topics, such as Digital and Agile are now addressed within the TOGAF Standard. Each now has its series guide. Information and Data Content Has Been Added to TOGAF 10 The available content about information mapping and master data management increased significantly. Broader Audience of TOGAF The new version tries to become relevant to a broader audience. It provides steps and content for a particular audience. Also, the IT focus of some chapters has been removed to become relevant for business as well. For instance, around the topic of EA Capability and Governance. TOGAF Definitions Quite some definitions have been added (e.g., a definition of a product or a digital architecture), changed, or removed. There are surely more changes hidden trends in the new version, which I will write about after I had the chance for a detailed review of TOGAF 10.

Is TOGAF 10 Worth It?

My initial impression of TOGAF 10 is very positive. Let´s summarize the arguments: - The Open Group has managed to cut the TOGAF Standard into smaller, better digestible pieces. The new modular structure makes the content much easier to grasp. Different organizations with different architecture styles can also better choose what to consider and what not. - The core content of TOGAF has been further consolidated so that overall consistency increased and redundant content has been removed. Content that is likely to change quickly over time has been moved to the TOGAF Series Guides so that the TOGAF Fundamental Content increases in overall importance and relevance. - The new structure allows new content to be added more frequently to the TOGAF Standard by simply releasing new TOGAF guides. This is also done outside the normal release cycle of the Standard to address new, emerging ideas. - Several new concepts or topics that tremendously increased their importance over the past years were added, refined, or described in more detail. Those include most topics mentioned above, including the concept of architecture scenarios, information management importance, and customer master data management. All in all, I am positively surprised by the new version. Especially the modular structure and the inclusion of the further content created by The Open Group into the wider TOGAF Standard (e.g., many "How-To" guides) make it an extremely valuable piece of content for all Enterprise Architects.

TOGAF 10 Certification

Business Architecture has become a broadly used concept not only by Enterprise Architects, but also by all kinds of stakeholders, including business people. In today´s article, we discuss three major concepts that can be used to describe an organization´s business architecture.

How to Model your Business Architecture?

In an Enterprise Architecture model, business architecture usually sits on top of the other layers. It serves as the connection between the IT layers (e.g., applications, data, technology) and the translation to business terms. However, business architectures are not only used in the area of Enterprise Architecture. Moreover, development teams, product teams, and other teams regularly exchanging requirements and progress with business stakeholders have adopted the concept of a business architecture. In some organizations, this is reflected by the usage of business capabilities. In other organizations, value streams or business processes are used for that. What are the differences between them and when should you choose which one?

Business Capability Models

Business capabilities focus on what has to be done or what an organization can do. They are rather generic and high-level. Their goal is to provide a stable description of the business. In order to achieve that, a business capability is the result of a combination of different components. Typically, those are people, process, and technology. Considering all three aspects allows to describe an ability of an organization as independent as possible from each indiviual one. For instance, a capability should not describe a particular process of an organization or be based on a particular technology that the company uses. Consequently, a capability is more stable over time as it does not include many details about company particularities. Business capability mapping is used as translator between business and IT. Common situations in which there is a use case for business capabilities include (click here for the detailed explanation): - Provide IT landscape transparency on all underlying enterprise architecture layers (typically applications, data, technologies) - Prioritize projects based on the importance of their underlying business capabilities - Optimize demand management processes based on business capabilities - Optimize application landscapes based on business capabilities - Use business capabilities to align different IT landscapes in the context of an IT post merger approach If you want to get started with business capabilities and do not repeat the failures of others, I highly recommend you read through the 12 Must-Dos to get Business Capabilities Right

Business Process Modelling

A business process is the sequence, in which functional activities and decision points are conducted. In contrast to business capabilities, which describe the what, business processes describe how an organization does something. A business process brings clarity around the order and reason for activities being performed in a predetermined order. It illustrates dependencies and the effect if certain activities are not carried out. Nowadays, many companies have detailed business processes modelled on different levels. However, starting to model new business processes can be time-consuming. In order to save time and resources and to ensure industry standards, many organizations start their detailed modelling activities with an industry standard framework, such as the one from APQC. Business processes are used when the order of something or decision points are important. Typically, this is the case when process models are used to achieve operational excellence.

Value Streams

Enterprise Architecture frameworks help to do enterprise architecture right. However, different types of frameworks exist, which are often confusing. Today´s article explains the difference between Enterprise Architecture management frameworks, Enterprise Architecture layers frameworks, and Enterprise Architecture Assessment frameworks.

Enterprise Architecture Layers Help to Understand the Scope of an IT Landscape

There are different Enterprise Architecture layer frameworks and they differ in the set of layers that they include. Each architecture layer can be understood as one view on the IT landscape of a company. For instance, the application layer provides a view only on the applications, while the data layer focuses solely on the data, how they are connected etc. If you are establishing an EA practice, the right choice of an overarching framework is important. Organizations that deal with sensitive data or with data that might be very valuable, political etc., will put a higher focus on IT Security compared to a small startup that just started operations. Accordingly, the first company is more likely to include a security layer into its Enterprise Architecture framework. Let´s consider the top three options for Enterprise Architecture Framework layers. 1. The TOGAF Enterprise Architecture Framework A traditional and widely-spread choice is the TOGAF Enterprise Architecture Framework. It consits of three layers, which are business architecture, information systems architecture, and technology architecture. Interesting about the TOGAF Enterprise Architecture Layer Framework is that it is quite lean. For instance, the information systems architecture layer consolidates information about applications and data. If you are looking for a framework that focuses more on data integration architecture, you might want to choose a different framework. Leanr more about TOGAF with those 7 pictures. 2. Enterprise Architecture Data Integration Architecture and Application Architecture Layers The TOGAF framework, including the proposed layers, is often perceived as outdated. A more-often used model is the BAIT model of IT architecture layers. It has four layers, which are business architecture, application architecture, data and information architecture, and technology architecture.

The main difference to the TOGAF framework is that is has a seperate application layer and a separate data and information architecture layer. This is generally beneficial if your organization has a lot of applications to manage and also wants to specifically manage enterprise data, such as their metamodel, the data integration architecture etc. Due to the general increase of applications in an average application landscape and a steep increase of data importance, it sounds reasonable to show the two aspects seperately. Obviously, it is also possible to manage your enterprise data integration architecture without a dedicated layer in your enterprise architecture framework, however, it makes things easier. 3. Focusing on Enterprise Security Architecture Last but not least, IT Security importance is steadily rising. Given that, enterprise architecture frameworks start to separately point out that aspect in their IT landscapes. This framework is an extension of the BAIT model and is therefore called BAIT+S model, where S stands for the security architecture layer.

Again, not having a separate Security Architecture layer in your framework does not mean that you cannot have security architects, security architecture, and generally a sufficient focus on the topic. However, it makes it clear right from the core of enterprise architecture activities.

Enterprise Architecture Management Frameworks Help to Manage EA Practices

Next on our list is the Enterprise Architecture management framework. While the EA layers framework focuses on the IT landscape assets, the EA management framework focuses on the capabilities, activities, skills, and content that an Enterprise Architecture practice deals with or should deal with. Let´s take a look at the EA management framework of TOGAF, as well as my own suggestion. 1. TOGAF Enterprise Architecture Management Framework The TOGAF Architecture Capability Framework does exactly what I described above. It is a view on what an Enterprise Architecture practice should be able to to in order to work well and provide good results. As you can see in the picture below from The Open Group, an EA practice requires a governance body, a pool of skilled resources, a portfolio of projects and its governance, an architecture repository to store deliverables, results, and documents, and an interface to business operations.

Picture taken from: The TOGAF Standard, Version 9.2 - Introduction to Part VI (opengroup.org) 2. Best Practice Enterprise Architecture Management Framework TOGAF provides a decent start to understanding what is required to manage an Enterprise Architecture practice. However, one needs to combine different sources of information to get a full picture. Based on my experience, I usually propose a different approach with three main categories, which is shown below. - Strategy & Organization a) Strategy & Governance b) Organization Management - Content Management a) Business Architecture b) Application Architecture c) Data & Integration Architecture d) Technology & Infrastructure Architecture e) IT Security Architecture - Architecture Implementation & Support a) Architecture Realization & Synergies b) Enabler & Facilitator Each of the elements stands for a set of capabilities and services that an Enterprise Architecture practice should deliver to its organization. For instance, most common tasks around an application architecture include application strategy, application landscape management, microservices management, services management, software assets and licenses management, and configuration management. Another example would be Organization Management, which includes capabilities such as EA governance, organization & culture, processes, roles and responsibilities, EA environment, risk management, financial management, and performance and quality management. If you are interested in the full framework or in understanding specific aspects of it in detail, please feel free to get in contact with me and I am happy to help.

Enterprise Architecture Assessment Frameworks Help to Understand What you Should Improve in Your Enterprise Architecture

Enterprise Architecture management frameworks let you know what your organization should be caple of to do. An Enterprise Architecture assessment framework helps you to understand where you should improve your current activities. As both framework types are based on EA activities, they can be quite similar in practice. The difference is that the first one suggests what to have, the second one evaluates the quality of what you have. In addition, the heart of an Enterprise Architecture assessment framework are its assessment questions, which help to evaluate your As-Is state as objectively as possible. Examples of Enterprise Architecture Assessment Questions - How well is the EA strategy defined including vision and mission? - Are principles defined for all architecture layers? (e.g. business, application, data, infrastructure) - Are there any agile roles defined within the EA function? - To what extend are EA processes lean and light-weight? - To what extend is an microservice strategy defined? - To what extend is meta data assessed and managed? - ... A good assessment framework should have at least 5-10 questions per area in your management framework. When assessing, keep in mind that you need to ask the right questions to the right stakeholders in your organization. If you want to learn more about that topic, feel free to contact me as well.

Enterprise Architecture Frameworks - Different Types and Different Purposes

Today´s content forms the sixth and last of six parts of the series called “Who is still interested in Enterprise Architecture?”. In this series, I provide my view on the footprint of today´s Enterprise Architecture, the potential death of the role of an Enterprise Architect, the big players, such as TOGAF from The Open Group, AWS, or Azure, as well as the role of EA tool providers and other related certificates and developments on the market. In today´s part six, we draw conclusions from the previous parts and forecast what that implies for the future. Regardless of whether you are reading this article or whether you are listening to the podcast version, make sure to also check out the first five parts of this series!

Who is still interested in Enterprise Architecture? – Part 6 of 6

After the last post presented quite some degrees, university courses, classes, and certificates about Enterprise Architecture, today´s article focuses on trainings and online classes. While the difference is not always straightforward, the trainings and classes are usually shorter and cheaper and there is a larger number of providers and trainers. Also, trainings often focus on achieving a particular certificate that is widely accepted on the market (e.g., TOGAF, ArchiMate).

Online Classes and Trainings about Enterprise Architecture

1. Enterprise Architecture Center of Excellence trainings and certificates Enterprise Architecture Center of Excellence (EACOE) provides trainings, consulting, and certifications in Enterprise Architecture. We briefly covered the certifications in our last post. In addition, the EACOE provides a workshop approach, which has a length of 4 days and covers theoretical and practical aspects of EA. Fees amount to 3,695 US dollars. 2. The Knowledge Academy courses for future Enterprise Architects The Knowledge Academy provides Enterprise Architecture courses with a focus on market standard certificates. They provide two different courses packages: - Enterprise Architect Certification, which includes content to certify in TOGAF, ArchiMate, and Lean Six Sigma Green Belt. - Complete Enterprise Architect Expert Package, which includes content to certify in TOGAF, ITIL, CISSP, and AWS Architect. Unfortunately, there are no prices for the courses on their website and one must quote individually. They also state that there is a current offer, providing a 40% discount. However, the countdown for this “limited offer” resets when you refresh the page, so I don’t think this is real. 3. Web Age Solutions INC general enterprise architecture trainings Web Age Solutions INC provides a series of Enterprise Architecture trainings as well. They have two general EA trainings and one TOGAF training: - General Architecture Training. This includes the following classes: Integrating Enterprise Architecture and Solution Architecture, Integrating Solution Architecture, Management Skills for Architects, Architecture Foundation Workshop, Architecture Techniques, Fundamentals of Architectural Thinking, and ArchiMate for Architects. - Enterprise Architecture Training. This includes the following classes: Management Quick Start, EA Getting Started, Enterprise Architecture Practitioner´s Guide, Reference Architecture and Roadmaps, Establishing an Architecture Baseline, and Introduction to Agile Architecture. - TOGAF Training including both levels, as well as exam preparation. 4. Digital Academy certified enterprise architecture practitioner The Digital Academy provides a training called Certified Enterprise Architecture Practitioner. It has a duration of 7 days with 8 hours per day and costs roughly 5,300 dollars including the exam. The course content covers general EA topics, as well as specific TOGAF content. Classes include: Introduction to enterprise architecture, architecture lifecycle & development methodology, architecture principles and patterns, business architecture, information architecture, application architecture, technology architecture, architecture governance & management, architecture requirements & change management, EA and relationship to SOA, architecture partitioning, content framework and meta model, capability-based planning, business transformation readiness assessment, using TOGAF standard to develop security architectures, architecture repository, using TOGAF standard to develop SOAs, and risk management.

Online classes providers and individual trainers complement the Enterprise Architecture degrees, courses, classes, and certificates landscape

There is a vast amount of learning possibilities in Enterprise Architecture. Options vary greatly, from full degrees, specializations of general master programs, individual courses, classes, or trainings, as well as online business programs. In today´s article, I provide an overview of the different options that exist, what topics they cover, and how much they cost.

Enterprise Architecture Degrees – Master´s Degrees in Enterprise Architecture

I found four interesting full degrees in Enterprise Architecture. Two of them are offered by European universities (UK and Belgium), and two are offered by American universities: 1. Arden University Master´s Degree in Enterprise Architecture Arden University (UK) offers a Master´s degree in Enterprise Architecture. It is set-up as a part-time master with a duration of at least one year. Tuition fees amount to 10,550 British pound. 2. University of Antwerp Executive Master in Enterprise IT Architecture University of Antwerp (Belgium) provides an executive Master in Enterprise IT Architecture. It´s tuition fees are 24,000 Euros. The degree focuses on modules on business strategy, leadership, change and data science management with a total of 60 ECTS (equals 1,680 hours of work). 3. Penn State University Enterprise Architecture and Business Transformation Degree Penn State University (US) offers the degree Enterprise Architecture and Business Transformation. It requires a total of 33 credits and includes mandatory courses as well as a variety of elective courses. The following classes are mandatory: Enterprise Architecture Foundations I, Enterprise Modelling, Enterprise Information Technology Architecture, Architecting Enterprise Security and Risk Analysis, Managing and Leading People in Organizations, Financial Management, Global Strategic Management, and Strategic Business Architecture, and the research paper or project. In addition, there is a total of 12 electives to choose from the areas of Business Architecture, Project Management, Security Architecture, and Supply Chain. Tuition fees for this degree are 31,350 US dollars. 4. Stevens Institute of Technology Degrees Stevens Institute of Technology provides a couple of related courses, e.g. Technology Management Master´s Program. However, as most of them seem to target general IT Management, I am not considering them further.

Master Specializations, Courses, and Certificates about Enterprise Architecture

While there is only a small amount of university master´s degrees that solely focus on Enterprise Architecture, there is a much broader choice if you are only interested in a specialization or extended course in that area.

Enterprise Architecture Degree Specializations and Individual Courses

Degree specializations are offered more frequently and are usually offered in addition to a degree in Information Technology, Computer Sciences, Informatics etc. Often, universities offering such degree specializations also provide the possibility to take the required enterprise architecture classes individually. I am going to present 6 options in the following. 5. University of Twente Specialization in Enterprise Architecture & IT Management University of Twente has a degree specialization called Enterprise Architecture & IT Management. It is a sub-degree of the Master´s degree Business Information Technology. The full Master´s degree has 120 credits (each about 28 hours of work), while the specialization for the Enterprise Architecture & IT Management degree requires you to take at least four out of the following six courses: Smart Industry, E-Strategizing, Electronic Commerce, ICT Management, Implementation of IT in organisations, and Architecture of Information Systems. Tuition fees for this two-years Master´s degree amount to 4,418 Euros for European students and 25,500 Euros for students from other countries. 6. ITU University of Copenhagen Master´s Degree Specialization in Enterprise Architecture ITU University of Copenhagen (Denmark) has a Master´s degree in Digital Innovation and Management. As part of this degree, there is an elective called Enterprise Architecture. It has 7.5 ECTS (i.e., roughly 210 hours of effort behind) and covers the following topics: The role of EA in digital transformation, information, business, and application perspectives of EA, the role of EA in strategic alignment of business and IT, design and modelling techniques in baseline and target architecture, and governance structures within architecture. 7. University of South Australia Postgraduate Course in Enterprise Architecture The university of South Australia provides a postgraduate course in Enterprise Architecture. It has a length of 13 weeks with weekly classes of two hours. For Australian, the price is 3,100 Australian dollars, for all other students, it is 3,675 Australian dollars. 8. National University of Singapore Certified Enterprise Architecture Course The National University of Singapore has a course called Certified Enterprise Architecture Practitioner. It has a duration of 7 days, 8 hours per day, and costs roughly 5,700 Singapore dollars. The course has a strong focus on TOGAF as well as fundamental knowledge around the 4 architecture layers. 9. University of Denver Enterprise Architecture Course University of Denver provides a four-credits course on Enterprise Architecture. Costs are roughly 3,000 US dollars. The course covers basics of EA, such as reference architectures, architecture patterns, and a comparison of EA and other architecture types, opportunities and drawbacks of different EA frameworks, their practical appliance, as well as recent trends, such as cloud computing, global regulatory compliance, data protection, artificial intelligence, and ICT ecosystems. 10. Ryerson University Advanced Enterprise Architecture and Infrastructure Management Course Ryerson University (Canada) – The Chang School of Continuing Education provides a course called Advanced Enterprise Architecture and Infrastructure Management. It consists of 4 courses, from which three are mandatory: Business process design, enterprise architecture, and information systems security and privacy. In addition, one elective can be chosen from: Supply chain process architecture, data communications network design, cloud computing, and IS project management.

Enterprise Architecture Certificates and Workshops

Steve Nunn, the president and CEO of The Open Group, which is the organization publishing TOGAF, recently provided some insights onto what is planned for 2022. It is great to see that his statements further confirm what I presumed in 2020 about the future development of TOGAF. This article summarizes the most important statements, puts them into context and helps to understand the relevance of TOGAF in the future.

Current State of The Open Group

In his article about 2021 achievements of The Open Group and new developments in 2022, Steve addresses a couple on interesting topics, among others: - The Open Group celebrated its 25th anniversary last year - The amount of individuals certified has now reached 115,000. I already addressed this strong growth of certified TOGAF individuals in one of my posts when it just hit the 100,000 mark - Several specific areas of The Open Group reached milestones. Among them, the release of the OSDU Data Platform Mercury release, the SOSA technical standard for reference architecture, and the FACE training program - As I noted in 2020, only 3% of all global TOGAF certifications were achieved in China. Being China such a huge market, its clear that The Open Group should put an extra focus on expanding here. In accordance, a particular achievement of 2021 was to translate many documents into Mandarin to ease the usage and increase acceptance - Other growing markets are also specifially addressed, such as Brasil and India - Feedback for the ArchiMate 3.1 has been collected and the release is planned for Mid 2022 - IT4IT is also planning to release version 3.0 in the near future - The Open Group is hosting a Toolkit Tuesday Broadcast Series, which I found quite interesting to listen to! - The Open Group has also several forums working on activities towards solving urgent current questions, such as Cyber Security, Supply Chain Security, and mass vaccination campaigns - Lastly, the Open FAIR certification program reached 1,000 certified individuals

What to Expect from TOGAF in 2022

I often hear questions such as: Is TOGAF still relevant for Enterprise Architects? Is TOGAF still relevant nowadays? In 2022? What will replace TOGAF? Is TOGAF outdated? My observation is that TOGAF has still quite some relevance even today. However, some parts of it are outdated. Also, it seems that The Open Group has a new strategy regarding TOGAF and its other certifications, frameworks, and standards in mind. The recent information from Steve Nunn confirm those thoughts.

What is the TOGAF Roadmap 2022?

I assume that readers of this article already have a first understanding of what a business capability is. If this is not the case, please read this article on what you need to know about business capabilities first. Many organizations start with business capabilities because someone had the idea to use them somehow. Business capabilities are still a relatively new concept and there is little agreement and accepted literature when it comes to the theory of the concept, especially in terms of definitions, development methods, use cases, and standards. Several organizations have tried to establish standards, yet, the scope of their standards ends at the boundaries of their organizations. The results are little available guidance, heterogeneous development results, few success stories, and many sceptic stakeholders. In order to support organizations struggling with developing business capabilities, I have summarized my top 12 lessons learnt that I experienced during the past few years:

1. Understand the Exact Use Cases

Understand your use cases to determine what exactly you need. Business capabilities can support many different use cases, such as alignments of business and IT, across merging companies, or for strategic planning of future budgets and projects. However, do not assume that one can use one business capability map for all! In fact, the business capabilities required for different use cases will be very different in terms of number, level of detail, number of levels, and information and components that should be mapped. - A rationalization approach for an application landscape might for instance need just a few business capabilities and mapped information. Those could be applications, cost information, lifecycle of the underlying technology, and business happiness with the overall outcome. - A demand management approach, on the contrary, might need a large and detailed amount of capabilities. For such a use case, more than 20+ business capabilities can be mapped to a demand. The objective is to decide how many of these are already covered by existing solutions. Information to be mapped might then be scalability, interdependencies etc. - For a merger, you will not need any detailed capabilities, because you must stay on a level that is still comparable across the companies.  

2. Know All Your Stakeholders

Identify all relevant stakeholders for a particular business capability area. If you only work with one department to identify the business capabilities of a particular area, do not expect a holistic business capability map as result. Take the example of pricing. It is not only done by the Marketing Department, but is also impacted by many more areas in the business. The following areas also impact it: - the development and production costs, - strategic aspects from the Strategy Department, - the local sales shops that have to eventually consider transport, import, taxes, temporally and local discounts etc. Similarly, contract management is not only needed when a customer buys a product or service, but also with suppliers, business partners etc. Your organization might eventually be present in different markets and have different divisions that are all a bit different, use different applications, and follow different processes. However, they all pay onto the same stack of business capabilities that in the end represent the business capability map of your company.

3. Understand and Explain the Difference to Processes

Be prepared for tight discussions with “process people”. Many organizations have put a tremendous effort in developing detailed and sophisticated process descriptions for their organizations. Also, process descriptions are often more mature than business capabilities and hence there will always be some strong supporters of processes that do not consider the business capabilities as a viable alternative - at first. It is one of the key success factors of business capabilities to emphasize their benefits over processes, which is why I will briefly mention them here: First, a business capability is always defined and named as common as possible in order to maximize understanding from all kinds of stakeholders. For instance, it must not include company specifics, such as a technology or a particular process step. On the contrary, processes can vary greatly between two different companies and even if their name is the same, the actual content can be very different from each other. Secondly, business capabilities have always three components, which are process, people, and technology. Being the result of several components makes business capabilities more stable over time than its single components, for instance a process. Thirdly, the aim of business capabilities is to provide an exhaustive view of the company without overlaps. They are a theoretical concept that are chosen to minimize the interdependencies across two different capabilities. This makes it possible to analyze them separately. In contrast, processes reflect the actual doing of a company and they are not optimized for independent analysis. With these advantages at hand, it is crucial to also understand the great disadvantage of business capabilities, which is their theoretic nature. In order to benefit from capabilities, an organization needs to have the concept understood and defined for itself – which is challenging without good existing guidelines. This brings us to the fourth lesson to consider.  

4. Communicate the Concept Over and Over

Be well prepared to explain the concept of business capabilities 1,000 times and more to members of your organization – on all different levels. I have spent endless hours of presenting and discussing the concept of business capabilities. A major take away from this was that sharing and being able to reuse the content should have a very high priority. Generally, be prepared to answer questions such as: Why capabilities? How does it help us in our current situation? Why is it better than the last two concepts we tried? Why should we use them? How will you do it? What results do you expect? What’s in it for the executive level? For business? For me? There are endless questions.  

5. Provide Strict Guidance on the Development

Develop and communicate very clear guidance on how the business capability that you expect looks like. If you have already searched for business capability maps of other organizations, you noticed that, depending on the source, the results can differ a lot. Again, this is due to the missing standardization, as even the new TOGAF 9.2 strives new digital topics, such as business capabilities only on a very high level (Update: TOGAF tries to provide some standardization for the topic of business capabilities with its Series Guide: Business Capabilities - which indeed provides one of the best summaries so far). If there is no centrally accepted guidance, every stakeholder will create business capabilities that differ in terms of detail, the dimension, the components considered, and the wording. All those aspects make it challenging to harmonize and compare the results later on. From my experience, explanations cannot be detailed enough to sufficiently define a business capability in a way that people independently come to the same results. Instead, I prefer to provide small examples of how the business capability map should look like in the end. This way, attributes such as detail level, grammar, components, scope etc. become clear and are immediately captured.  

6. Reuse and Lever Existing Inputs

Reuse as much of existing sources as possible – internally and externally. A first business capabilities draft is often much closer to the status quo than theory would suggest. This is not bad at all, as it helps the organization to slowly change its mindset towards a capability-based view. Understand the first version of a business capability map as a starting point that your organization can use. In a next step, consolidate further, identify more capabilities that belong together. Also, identify whether there is still one or the other process in the map that can be transformed. When it comes to internal sources, consider strategy papers, process descriptions, organizational charts, or functionalities of your applications. When it comes to external sources, consider global process standards from APQC or FrameworX. However, be aware that none of these input sources is perfect and each has its advantages and disadvantages. How to get started with modelling business capabilities and which input to take is an important step.  

7. Be Aware of the Disadvantages of the Concept

One of the disadvantages of the sources is that there will be a bias towards one of the components of business capabilities: people, process, or technology. The type of bias will depend on the source you decide for. Obviously, if you use process descriptions to develop a first business capability map draft, the result will somehow be similar. There will be no swim lanes, responsible, or repetitive detailed process steps anymore. However, it will make clear that for instance HR is organized from hire to fire or R&D has capabilities from research to patent lifecycle management. On the other hand, if you start to investigate functionalities of your applications and cluster them logically, there will also be a bias. The result is very likely to have a technology bias, as you went through the systems one after another and considered every technical detail. Lastly, if you start with an organizational chart, you might quickly have your first business capability level at hand. Such a capability map woule include capabilities such as Marketing, Production, and Procurement. However, there is a high risk that you capture too much of your organizational specifics (i.e. people component) that you do not want in your map, such as divisions or regional organizations.

8. Think Long-Term – do not Expect Short-Term Results

Be prepared to not be able to deliver fast results or add value quickly. The biggest risk of the long-term success of business capabilities is that they are a very theoretical. They are a concept that needs time to add value to an organization. As most areas of enterprise architecture, the concepts need to be accepted by many people within the organization. Therefore, data needs to be collected, analyzed, and the implications need to be communicated and again accepted. This all takes time and there is a risk that the added value becomes quickly zero if key stakeholders do not support the idea. Also, top management must understand that the real benefits will be realized in the long-term. There might even be no positive effects in the short-term at all! It is therefore highly important to show the value added by business capabilities whenever possible, especially when there are discussions about the worthiness of the concept.  

9. Look Out for Every Opportunity to Pilot and Showcase

What this means for you is that you must be sensitive to opportunities. Your goal should be to show the value of business capabilities through pilots or showcases. There are enough opportunities if you continuously search for them. Be sensitive to stakeholders that show more interest into your work than others. They might just think alike and understand the real potential behind. Look out for early-on projects that suffer to harmonize a part of the landscape or that miss a clear representation of their strategic way forward. All these situations might provide you with a good chance to show some value of your draft business capability map.  

10. Manage Expectations

In all you do, do not expect to get 100% accurate and final results. Enterprise architects, especially business architects, know that their work never provides a definite answer. However, business might not be used to this. Business architects are used to provide recommendations, directions, or a couple of options. In contrast, business often looks at the definite numbers of the business case. As business capabilities are an enterprise architecture concept, they are conceptualized to provide recommendations across a wide spectrum of questions. They are not made to provide definite answers, as they will always lack some information. Lacking information can be: - more detailed business capability levels, - interdependencies that the concept does not consider, - information that were not captured for the analysis or have changed in the meantime, - and tacit knowledge from domain or solution architects that were not involved.

11. Decide on the Right Tool Based on the Target State and Operating Model

Get tool support to manage updates on the vast amount of data that you will have. There are different options, starting from Excel lists, SharePoint solutions, and all kinds of specialized EA tools, from lean to highly sophisticated. In the end, also the tool must fit to your purpose. However, be aware that developing business capabilities and mapping information to them, as well as using them and displaying the results is an iterative activity that typically takes much more time than initially expected. Therefore, think wisely from the start: How much data sets will you have to manage? How many persons should have access to view and edit data? What kind of visual representation do you expect? How often do you want to allow updates or new releases? What security level is needed for the data? Depending on your answers to those questions, you can derive a first impression of what kind of tool support you need.  

12. Understand the type of capabilities that you need

Today´s content forms the fifth of six parts of the series called “Who is still interested in Enterprise Architecture?”. In this series, I provide my view on the footprint of today´s Enterprise Architecture, the potential death of the role of an Enterprise Architect, the big players, such as TOGAF from The Open Group, AWS, or Azure, as well as the role of EA tool providers and other related certificates and developments on the market. In today´s part five, we consider the role of Enterprise Architecture tool providers in developing new best practices for their area. We also try to understand what that implies for the future. Regardless of whether you are reading this article or whether you are listening to the podcast version, make sure to also check out the other parts of the series as soon as they are available!

Who is still interested in Enterprise Architecture? – Part 5 of 6

Today´s content forms the fourth of six parts of the series called “Who is still interested in Enterprise Architecture?”. In this series, I provide my view on the footprint of today´s Enterprise Architecture, the potential death of the role of an Enterprise Architect, the big players, such as TOGAF from The Open Group, AWS, or Azure, as well as the role of EA tool providers and other related certificates and developments on the market. In today´s part four, I address that the trainings provided by different cloud organizations incorporate important IT and Enterprise Architecture aspects. In addition, modern, agile frameworks cover management aspects of Enterprise Architecture. Regardless of whether you are reading this article or whether you are listening to the podcast version, make sure to also check out the other parts of the series as soon as they are available!

Who is still interested in Enterprise Architecture? – Part 4 of 6

EA Best Practices are also Driven by Training Offers from Cloud Organizations

In the last part, we argued that IT and Enterprise Architecture has a high importance for modern cloud providers and cloud organizations. Consequently, the role of the cloud solution architect is one of the most important ones for AWS, Azure, and GCP. As a result, the curricula to gain the certificates for such roles focus not only on cloud and IT architecture aspects, but also incorporate Enterprise Architecture elements. Such elements include: - general subscription management, - cloud cost management, - hybrid- or multi-cloud management, - and data flows / interfaces with non-cloud systems.

Agile Frameworks Provide Best Practices for the Management Aspect of EAM

Today´s content forms the third of six parts of the series called “Who is still interested in Enterprise Architecture?”. In this series, I provide my view on the footprint of today´s Enterprise Architecture, the potential death of the role of an Enterprise Architect, the big players, such as TOGAF from The Open Group, AWS, or Azure, as well as the role of EA tool providers and other related certificates and developments on the market. In today´s part three, I take a broader look at organizations, frameworks, and models that are relevant for Enterprise Architecture. Specifically, we consider the cloud area, and conclude that a significant part of today´s EA best practices are developed by cloud organizations and providers.  Regardless of whether you are reading this article or whether you are listening to the podcast version, make sure to also check out the other parts of the series as soon as they are available!

Who is still interested in Enterprise Architecture? – Part 3 of 6

There are two different types of organizations that are relevant for Enterprise Architecture. - Some organizations, such as The Open Group and Bizzdesign have a full focus on that topic. - In addition, there are new market players that also develop Enterprise Architecture frameworks, but do not purely focus on this topic.

The Cloud Native Computing Foundation (CNCF) is an Important Player

An example for the second category is the Cloud Native Computing Foundation (CNCF). It´s founding companies include Google, Docker, Red Hat, Twitter, and IBM. It has the objective to be a vendor-neutral home for many of the fastest-growing open-source projects, fostering collaboration between developers, end users, and vendors. Hence, their main goal is to provide a platform for open-source projects to collaborate and develop further. As part of this, however, they also continuously develop a suitable ecosystem. Nowadays, CNCF also offers trainings and certifications for tools and technologies that help to manage whole landscapes of cloud native applications (e.g., microservices) easily and effectively (e.g., Service Mesh, Kubernetes). While there is no doubt that such solutions are a suitable expansion of their portfolio, they are located at the core of what Enterprise Architecture is about.

Hyperscalers such as AWS, Azure, and GCP are also Developing Best Practices

Today´s content forms the second of six parts of the series called “Who is still interested in Enterprise Architecture in 2021?”. In this series, I provide my view on the footprint of today´s Enterprise Architecture, the potential death of the role of an Enterprise Architect, the big players, such as TOGAF from The Open Group, AWS, or Azure, as well as the role of EA tool providers and other related certificates and developments on the market. In today´s part two, I take a deeper look at the Google Trends analysis from part one and I also investigate a bit deeper on the certification landscape of The Open Group. Both confirms that, although many Enterprise Architecture terms become less important, the actual content stays up to date. Regardless of whether you are reading this article or whether you are listening to the podcast version on my website, make sure to also check out the other parts of the series as soon as they are available!

Who is still interested in Enterprise Architecture in 2021? – Part 2 of 6

Part one of this series ended with some questions of whether EA is dead – based on a couple of different findings. Part two is opposing this opinion. One main argument came from the results from Google Trends, which show a clearly decreasing interest for some key EA search terms. To put this in context, it is vital to understand that there has been a shift of Google searches away from general terms. The general management of architecture layers are an example of such generic terms. Nowadays, more specific topics and concepts of Enterprise and IT Architecture are of interest.

High Demand for Particular Enterprise Architecture Terms

Figure 2 shows again the amount of search requests for the term “Enterprise Architecture” in blue. This time, it is compared to the terms “Master data”, “Scaled agile framework”, “Cloud Native Computing Foundation”, and “Microservices”. While those key words are clearly associated with the area of EA as well, they show strongly growing search volumes over the past years. Interestingly, the more specific subtopics are, the more they outperform the more general terms. For instance, “Microservices”, which is a subset of the application landscape, has a higher search volume. Also, “Master data”, which is a subset of data management, outperforms the search volume of “Enterprise Architecture” in general.

Figure 2 In other words, the insights from Google Trends suggest the following: Generic EA terms decrease in interest, while more specific search terms - also at the heart of EA - increase in interest.

The New TOGAF Strategy

Today´s content forms the first of six parts of the series called “Who is still interested in Enterprise Architecture in 2021?”. In this series, I provide my view on - the footprint of today´s Enterprise Architecture, - the potential death of the role of an Enterprise Architect, - the big players, such as TOGAF from The Open Group, AWS, or Azure, - as well as the role of EA tool providers and - other related certificates and developments on the market. In today´s part one, I analyze the search term attention for common Enterprise Architecture terms on Google Trends. I highlight the origins of today´s most important EA frameworks, TOGAF and Zachman, and share my results on job searches. I deduce that Enterprise Architecture might be a dead practice.   Regardless of whether you are reading this article or whether you are listening to the podcast version, make sure to also check out the other parts of the series as soon as they are available!

Who is still interested in Enterprise Architecture in 2021? – Part 1 of 6

It seems that, especially in modern tech companies, the importance of the Enterprise Architecture (EA) practice is decreasing. Some organizations might even consider it an irrelevant practice. In the following, we analyze where such opinions emerge from. In the later parts of this series, we will provide arguments against that reasoning and provide an analysis, which underpins that this is not the end of Enterprise Architecture as a practice. However, Enterprise Architecture will go through a transformation towards an adapted set of activities, new priorities, and new required skills.

Traditional Enterprise Architecture Terms, Roles, and Frameworks Become Irrelevant

The attention for EA seems to steadily decrease: According to figure 1, which shows an extract from Google Trends, the number of search requests for the topic cluster “Enterprise Architecture” has declined by more than 50% since 2016 and by over 75% since 2004. In addition, figure 1 shows the relative amount of search requests for related EA terms, such as “Business Architecture”, “Application Lifecycle Management”, “Data Management”, and “Technology Management” in the years 2004 to 2021. All of them show a decreasing attention over time.  

Figure 1 In addition, there are much less EA blogs and websites compared to a few decades ago. Due to the lack of updates, a lot of outdated EA content on best practices is still relatively high ranked by search engines.

TOGAF and Zachman Became Outdated

Further evidence comes from the most important industry standard frameworks, such as TOGAF and Zachman. TOGAF has first been published in 1995. It was developed by several member firms of The Open Group, including major players such as IBM or Oracle. The TOGAF Standard is updated every few years with the latest release being version 9.2 in April 2018. Although the latest version aims at better targeting the topic of Digital Transformation, the overall content has not changed much. In addition, certified practitioners do not need to update their certification between minor releases and the current main release went live in 2011. In the era of continuous Digital disruptions, a decade old content cannot be fully relevant anymore. The second most important framework is the Zachman framework. With the initial release in 1987 and the latest major release in 2011, it has the same age as TOGAF. As a result, we can say that the most important Enterprise Architecture frameworks have not received any major updates in the last decade and are therefore - at least in parts - outdated.

Many Big Tech Companies Don´t Search For Enterprise Architects

According to a recent publication from Threat.Technology, digitalroadmap.management is proudly ranked as one of the top 20 enterprise architecture podcast websites, among LeanIX and BiZZdesign.

As I started the digitalroadmap.management blog back in 2018 as a hobby, I wanted to share my insights and opinions on digitalization topics, IT architecture, and IT technologies. Since then, I have published more than 75 blog articles, and have an increasing number of followers and visitors every month. I am very pleased with the growth and development of the blog content areas, and am thankful for the attention and support digitalroadmap.management gets from the visitors and contributors to further shape up and grow.

As an attentive follower, you might have noticed that since the beginning of 2021, I started to produce short podcast episodes for the most popular blog articles, which are predominantly around the topic of enterprise architecture. As of today, there are 11 episodes of my podcast, and there will be new episodes coming in the future!

If you are interested in topics around digital, IT architecture or innovation, please subscribe to my podcast on Apple Podcasts, Listen Notes, or by using the RSS feed.