Image interview Svyatoslav Kotusev

What is an Enterprise Architecture? And why is TOGAF® so popular among enterprise architects? And finally: Which aspect of Enterprise Architecture Management (EAM) is the most important?

Certainly, 10 years ago, these three questions would fill the program of an entire EAM conference. Heated debates, endless talks, philosophical answers. But todays times are different. Fast, pragmatic, digital. So we posed these questions to a pragmatist, who is scientifically grounded: Svyatoslav Kotusev. Designer of EA on a page, author and researcher in Australia, Kotusev provided us sound and exciting answers.

Mr. Svyatoslav Kotusev, why not starting off this interview with an obvious but oftentimes also challenging question: What is an Enterprise Architecture (EA)?

The term ‘enterprise architecture’ has been very hot for the last couple of decades and virtually countless definitions of EA can be found. Many of these definitions are purely philosophical and offer little in a practical sense (e.g. EA is some fundamental structure of an organization), while some of them are simply unrealistic (e.g. EA is a comprehensive description of an entire organization).

I prefer to define EA in a straightforward and practical manner:

“EA is a collection of special documents (artifacts) describing various aspects of an organization from an integrated business and IT perspective intended to bridge the communication gap between business and IT stakeholders, facilitate information systems planning and thereby improve business and IT alignment”.

However, Enterprise Architecture Management, often abbreviated with EAM, isn’t a new topic. In a global, digital and agile business world – what makes this discipline still important today?

The problem of coordinating plans and changes between business and IT is a natural problem, which emerged very long time ago along with the widespread use of early IT systems in business back in the 1960s. Since then various forms of information systems plans, then information architecture and now enterprise architecture have been employed in organizations to address this problem.

Fundamentally, the recent trends like globalization and digitization don’t eliminate or alleviate this problem. The problem of effective coordination of organizational changes still stays with us and is not going to go away in the future. Moreover, the constantly increasing interdependence between business and IT demands better mutual coordination than ever before.

Therefore, EAM (though in various forms and under different titles) was relevant decades ago, is relevant now and will become only more relevant in the future regardless of the latest business fashions.

Decision support, enabling, communication, governance,… EAM is a discipline with many facets. What is the most important and why?

Indeed, EAM is a very multi-faceted organizational practice including such diverse aspects as documents, processes, governance committees and software tools. However, in my view, the single most important facet of EAM is communication since ultimately it is the problem of enabling effective communication between very diverse stakeholders that EAM is trying to solve.

In fact, all other facets of EAM, e.g. artifacts, processes and governance, are only the means to a common end: involve all relevant business and IT stakeholders in a dialog with each other to improve the quality of decision-making.

For example, EA artifacts help stakeholders discuss and document respective planning decisions, structured processes help make these decisions at appropriate time moments, while formal governance arrangements help ensure that all important decisions are approved by everyone.

In the recent years, you interacted with more than 27 organizations researching on EA artifacts being used for architectural work. You synthesized your results on EA on a Page, a one pager classifying popular and lesser-used viewpoints. What was your biggest surprise?

My biggest surprise was that in these organizations I unexpectedly discovered a set of remarkably consistent EAM best practices that were intuitively understood and widely applied by experienced architects, but these practices were not described anywhere and spread verbally from architects to architects mostly through collaboration.

In order to document the ‘collective wisdom’ existing in industry, I decided to write my book The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment and also condensed the most essential findings regarding EA artifacts into EA on a Page poster.

From our experience, it’s not the artifact but the underlying data which is hard to come by. The problem: those needing the EA data are not the ones who can provide it. Do you have any advice?

This is true, EA artifacts are only formal means for capturing various planning decisions and motivation behind them. In order to avoid the problem of unavailable data, all EA artifacts must be developed collaboratively by all their stakeholders, rather than by architects alone on behalf of other stakeholders. In other words, data providers must be involved in the process of creating EA artifacts and approve these artifacts.

For example, investment roadmaps should be developed by architects and senior business executives together, while solution overviews should be developed collectively by architects and solution sponsors from the business side.

This year you published your book The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment. Against the background of existing EAM literature: Who should read this book and why?

I read more than 70 books on EA, essentially all the books that I was able find on the subject, and my impression is that, with a few notable exceptions, these books are hopelessly disconnected from the world of practice, confusing and not worth reading. They either promote approaches that cannot work in real organizations, or are simply too vague and obscure to provide any specific advice. And certainly none of the existing books on EAM offers an evidence-based, systematic and complete discussion of all key aspects of EAM, e.g. documents, processes, roles, tools, etc.

In my book I tried to close this gap and provide a concrete, realistic and comprehensive discussion of EAM based on my own findings from multiple real organizations having some experience with EA. In its coverage and empirical basis my book arguably has no comparable analogs on the bookshelf today. Certainly being biased as an author, I would still dare to say that for people new to EA currently there are no other easy ways to understand how EAM actually works except for reading my book. The book is intended for a broad audience including practicing architects, architecture managers, EA students, lecturers and researchers, essentially for all people seriously interested in EA.

Since its major release in 2009, we witnessed the rise of The Open Group Architecture Framework®. Speaking from a practical point: to which extent does TOGAF® helps you in your EAM endeavors?

It is important to understand that TOGAF gained prominence mostly because it was very effectively advertised at the right time, but certainly not because it was particularly helpful for EA practitioners. The key problem with TOGAF is that the formal, documentation-oriented and step-by-step planning approach advocated by TOGAF (Architecture Development Method, ADM cycle) is fundamentally unsuitable for enterprise-wide planning. It has nothing to do with the actual EAM best practices accumulated in industry that work in leading organizations.

Essentially, TOGAF promotes proven worst practices since closely following TOGAF prescriptions will certainly ruin all your EAM endeavors. From this perspective, TOGAF is harmful and worse than useless. However, some people still find it useful for other purposes, for instance, consider it as a dictionary where some EA-related terms can be found or get TOGAF-certified to improve their CVs and then land into EA jobs.

Generally, I would not recommend EA practitioners to study TOGAF, or at least to treat its advice seriously, since TOGAF is simply confusing and misleading. It barely overlaps with genuine EAM best practices and does not reflect adequately even the overall meaning of EAM activities. After being studied, it has to be ‘unlearned’ in order to be able to work successfully as an architect. In short, I don’t believe TOGAF can help anyone involved in EAM endeavors, while the harm from it can be very considerable.

Suppose I am an enterprise architect who is said to be stuck in his ivory tower, only hindering projects in making progress. What should I do?

It’s hard to offer a specific answer to this general question without having a more detailed understanding of what exactly is going on. However, if there can be any generic advice for getting out of the ‘ivory tower’, then this advice would be the following one: communicate, i.e. before producing any architectural plans go to their stakeholders, obtain their buy-in, understand their concerns, propose the most optimal way forward, get it endorsed and necessary follow-up actions agreed. Discussing architectural plans with their stakeholders should cause a sobering effect on architects lost in their ‘ivory towers’.

Final question: during an EA conference here in Germany, a speaker claimed that agile and EAM do not fit together. The former is focused on decentralization and self-organization, while the latter prefers centralization and strict rules. What do you think?

Firstly, I believe it’s a misconception that EAM is necessarily about centralization and strict rules. The goal of EAM is to enable effective decision-making at the appropriate places and levels of the organizational hierarchy, rather than to centralize all decision-making. For instance, if your business is decentralized, then your EAM should be decentralized accordingly.

Regarding strict rules, EAM is not about zealously following some set of rules, but rather is about making informed decisions regarding what rules are desirable, when they should be enforced and in which cases deviations from these rules are acceptable. There is always a certain degree of flexibility in decision-making. Again, the goal of EAM is to make most optimal decisions, rather than decisions that follow some strict rules.

Secondly, I believe the term ‘agile’ itself is currently heavily abused and it’s rather hard to say what exactly a particular speaker means under ‘agile’. Moreover, it is also a big question to what extent the ideals of decentralization and self-organization promoted by agile thinkers are applicable to real organizations. In my observation, most companies today are still rather centralized, hierarchical and do not look especially self-organizing.

 

Many thanks for your time!

The interview was held on 3rd of October 2018 via E-Mail between Christopher Schulz and Svyatoslav Kotusev.

Svyatoslav Kotusev

Svyatoslav Kotusev

Svyatoslav Kotusev is a researcher at RMIT University, Melbourne, Australia. Since 2013 he focuses on studying enterprise architecture practices in organizations. He is the author of the book The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment and many articles on enterprise architecture that appeared in various outlets (visit kotusev.com for more information). Prior to his academic career he held various software development and architecture positions in industry. He can be reached at kotusev@kotusev.com.