//Does Academic Sloppiness Hurt EA?

Does Academic Sloppiness Hurt EA?

There are surprisingly few researchers publishing articles about Enterprise Architecture from universities.  Even well considered programs like Penn State and MIT may only publish four or five papers a year.  Therefore, when a single researcher (a doctoral candidate at a well regarded university) publishes no fewer than fourteen separate papers on Enterprise Architecture over the course of three years, a few directly through the British Computer Society website, folks like me notice.

Unfortunately, as this article will show, this researcher appears to be building a body of sloppy work that he promotes widely, potentially harming both the profession of Enterprise Architecture and the reputation of the British Computer Society for promoting him.

Who is this prolific researcher?  His name is Svyatoslav Kotusev and he is a doctoral student studying Enterprise Architecture.  I don’t know his background before he began those studies, unfortunately.  His visible history is thin.  I reached out to Mr. Kotusev on LinkedIn to ask for his bio and if he sends it, I’ll include it here.

I have both positive and negative things to say about Mr. Kotusev’s research.  On the positive side, many of his observations completely align with my experience.  In his paper titled “The Relationship Between Enterprise Architecture Artifacts“, published on the BCS website, Mr. Kotusev remarks:

“Unsurprisingly, my analysis shows that the EA documentation in successful EA practices neither can be represented as two separate descriptions of the current and future states, nor can be easily split into distinct chapters (e.g. business, data, applications, etc.). Instead, individual EA artefacts, which often describe multiple domains simultaneously, can describe various points in time and can even be essentially timeless. Moreover, EA, in general, cannot be described as a comprehensive ‘book’, which is developed and then used, but rather as a set of diverse EA artefacts with different stakeholders, lifecycles, usage and complex interrelationships.” (Svyatoslav Kotusev)

I absolutely agree.  It is refreshing to see this in print and I am of the opinion that Mr. Kotusev will add a great deal of value to the field in the future… if only he can refrain from being what I’ll call “academically sloppy”.  I’ve read six of Mr. Kotusev’s articles now.  All suffer from the same failing: he creates incomplete or erroneous logical arguments to make a point that is not worth making and detracts from the findings of his research.

Allow me to illustrate my criticism.  In the exact same paper cited above, Mr. Kotusev argues that “mainstream” EA frameworks insist on a comprehensive waterfall approach to developing a large book of artifacts to be used in planning (link):

“Accordingly, mainstream approaches to EA, e.g. TOGAF ADM, suggest that EA, as a comprehensive book, is developed step-by-step, chapter by chapter and then used as an instrument for planning.

However, all these approaches are based on the false belief widely promoted by John Zachman that organisations can be planned in detail like buildings or any other engineering objects. These approaches represent typical management fads and cannot be successfully implemented, while successful EA practices do not resemble these approaches in any real sense.” (Svyatoslav Kotusev)

First off, the TOGAF ADM does not suggest that EA is a comprehensive book developed in the manner described.  The following is an excerpt from TOGAF 9.1. Ch 5.1.1 (link):

“Architecture development is a continuous, cyclical process, and in executing the ADM repeatedly over time, the architect gradually adds more and more content to the organization’s Architecture Repository. Although the primary focus of the ADM is on the development of the enterprise-specific architecture, in this wider context the ADM can also be viewed as the process of populating the enterprise’s own Architecture Repository with relevant re-usable building blocks taken from the “left”, more generic side of the Enterprise Continuum.” (TOGAF 9.1)

In addition, Mr. Kotusev’s slam on John Zachman is rather unfair considering Mr. Zachman’s own words.  At no time have I heard John Zachman suggest that EA allows an organization to be planned in detail.  On the contrary, he has suggested that the elements of an organization’s architecture exist, independent of their use.  According to Zachman, understanding those elements can be useful knowledge for planning for change, or for mass customization, or for coping with complexity.  If it is value you seek, completely engineering every detail is not necessary (although Mr. Zachman, to be fair, believes it is a useful exercise, a point where this author disagrees with Mr. Zachman).  The following is an excerpt from an interview conducted by Roger Sessions for Perspectives of the IASA (April 2007) (link).  The text cited is on page 8:

“Here’s another piece of advice … you don’t have to have the entire Enterprise engineered […] before you can derive benefit or before you can implement anything.  […] You just have to do enough engineering to mitigate the downstream costs of scrap and rework and assume some risks that the incurred scrap and rework costs will not exceed the value of the investment.” (John Zachman)

So in the course of introducing his ideas, Mr. Svyatoslav Kotusev makes an argument against an approach that he feels is being promoted by TOGAF and Zachman when that approach is not being promoted by either the Open Group or Mr. Zachman.  It’s a strawman argument and an outright sloppy set of statements.  What’s worse is that this silliness is not necessary.  The paper in question was published for the purpose of presenting a novel bit of analysis that groups together EA artifacts into generalized artifact types and illustrating the relationship between these types.

While I believe he missed a key set of types in his generalizations, the material that Mr. Kotusev did collect, and the relationships that he illustrated, are interesting and useful.  They form a good taxonomy of most well known EA artifacts, and gaps aside, his work is solid.  If not for the extra argumentativeness at the start of the paper, I’d recommend it.

Unfortunately, this kind of sloppiness shows up over and over.  In addition to the article above, I’ve included a sampling of a few of his most widely read papers (judging from the view count on academia.com) and the logical flaws visible in each.

  • The History of Enterprise Architecture: An Evidence-Based Review — In this paper, Kotusev asserts that “many authors argue that the Zachman Framework inspired all other subsequent EA frameworks and methodologies.”  This claim has no citations.  There is no list of these “many authors”.  Thus having set up a strawman, Kotusev proceeds to knock it down by presenting a reasonably cogent argument that Enterprise Architecture methodologies arise out of the IBM’s BSP methodology.  At no time does Kotusev acknowledge that Zachman’s framework is not a methodology, or that few of the authors that he cites made the claim that he is attempting to refute.
  • Enterprise Architecture Frameworks: The Fad of the Century — in this paper, published on the BCS website, Kotusev asserts “My broad historical analysis of the EA literature shows that all popular EA frameworks, including Zachman, TOGAF and FEAF, are nothing more than typical management fads aggressively promoted by consulting companies and gurus. They are useless at best, and harmful at worst.”  He then proceeds to make an argument based primarily on his perception that the Federal EA Framework was a failure.  Therefore, he reasons, since they all stem from BSP, they are all failures.  His conclusions are a non-sequitur.  They do not follow from the evidence provided.
  • Investigating the Usage of Enterprise Architecture Artifacts — this paper, presented to a conference in Europe, is better than most.  Perhaps because of the influence of the two co-authors or better peer review from the conference editors, the paper holds up except for one of the most egregious initial conclusions: that EA ignores strategy.  The paper, after examining a series of frameworks including a 2011 version of TOGAF, declares: “Therefore, most existing EA methodologies recommend documenting a current state, developing a future state, analyzing the gaps between them, developing transition plans and implementing them.”  While this method may have been described in TAFIM, it is certainly not reflective of ANY of the modern forms of TOGAF, the Guild’s Bizbok, the Federation’s Perspective paper, or the various other descriptions of EA widely available.  Starting from this rather disconnected start, the paper is hopelessly unmoored from reality.  It is, in effect, an analysis of a strawman.

In all honesty, I stopped there.  Partly because I know that my post may draw attention to a series of articles that I view as potentially harmful to the profession, and partly because I don’t want to pull my hair out at such obvious mistakes, I have too much respect for the lining of my stomach to continue.

I’d like to see research done in the field of EA.  I certainly would benefit as would most other practitioners.  In my conference talks, I routinely posit research questions hoping that some members of the audience will pick one up and run with it.  Unfortunately, when a student runs off without any supervision, and is promoted by associations like the BCS without editing, both the profession and the reputation of the BCS can be harmed.

(note: this article has been edited to remove the name of Mr. Kotusev’s university at his request.  His articles represent his opinion alone).

 

 

 

By |2017-03-30T18:10:10+00:00March 28th, 2017|Enterprise Architecture|2 Comments

About the Author:

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

2 Comments

  1. R Singers March 30, 2017 at 10:15 pm - Reply

    The few papers I’ve stumbled across seem to comprise mostly of how to use Archimate for something the author only has an academic understanding of. It’s hard enough to make Archimate work for what it was apparently designed for, let alone something it wasn’t.

  2. D Aerts September 22, 2017 at 2:19 pm - Reply

    Please check the ee-institute.org website (http://www.ee-institute.org/en). Some strong professors there (Jan Dietz, Jan Hoogervorst, Martin Op’t Land) that teach courses at the Antwerp Management School – Master of Enterprise & ICT architecture.

Leave A Comment

1 × 1 =