Enterprise Architecture vs Alchemy Enterprise. Key myths

Алхимиками двигало примерно то же, что и современными учёными — им хотелось понять, как устроен мир. Они изучали это как могли. Позже древние протонауки эволюционировали до современного состояния наук.

Это справедливо и для современной дисциплины «Архитектура предприятия», нужно лишь сделать два уточнения: «алхимиками в 21 веке двигало …» и «… понять, как устроено предприятие».

На страницах ИТ-интернета тема Enterprise Architecture (ЕА) — одна из популярнейших. Она дает возможность поговорить о «высоком», — об «архитектурном» подходе, десятках framework, почувствовать себя Архитектором «с большой буквы».

Many write and write a lot. Readers of the articles "Enterprise Architecture" nod approvingly, admiring ... "the king’s dress." On the "fertile ground" EA divorced all kinds of "architects".

Books, academic disciplines, consulting projects, groups, consortia, entire institutes with specialization in EA (IFEAD, iEAi, etc.), global organizations (GEAO), journals of the same name (Journal of Enterprise Architecture), international standards (ISO 15704, 42010, etc. .) and so on - so on.

Nevertheless, in the context of EA, questions remain: what is “architecture”, what is “enterprise” and what is “enterprise architecture”, also who is the main consumer of EA and why are there no concrete examples of this EA.

Methods, reference models, and architectural frameworks (usually with the ending in "AF": FEAF, TEAF, DoDAF, etc.) - "like dirt", but there is nowhere to see real results.

Yes, a key feature of this area: there is not a single concrete complete example of this same mysterious enterprise architecture in the public domain.

Architects say that it is the NDA, the "big secret", chipboard (perhaps even "state secret"). But how can "architecture" be secret? That's why it is “architecture” in order to be recognizable: distinguishable and comparable. But "Alchemy of the enterprise" - just should be kept in strict confidence.

As a “litmus test” - as a confirmation or refutation of the conclusions made in the article, a competition is announced for the description of their “household architecture”, see the end of the article. Why undertake the solution of complex problems if it is not possible to solve a simple problem - provide a description of the architecture of your household on the same framework as EA?

We are trying to understand the fashionable and at the same time fabulous Enterprise Architecture.
Surprisingly: it’s still not clear what exactly is “Enterprise Architecture” (such as “analog”?), But outside the window they are trumpeting “about a supernova”: “Digital Enterprise Architecture”, Digital Enterprise Architecture.

1 Myths of Enterprise Architecture

1.1 A framework for information systems architecture

Let's start with the most popular myth. This is when replacing the "enterprise architecture" with the "architecture of enterprise information systems." EA is not IT architecture at all, and if you see big squares with the inscriptions SOA or similar horror stories from the IT world on the sheet with the title “Furniture Factory Architecture”, then you should know: this is either an “absurd misunderstanding” (delusion) or a “classic” conscious fraud .

The picture looks funny when the director of the enterprise is brought pictures (schemes) with the heading "Enterprise Architecture", where more than 90% of the objects are names from IT.

To this, the director says: “I have been running the enterprise for 15 years, but I don’t understand more than 90% of the names you indicated (for the first time I see“ SOA, corporate clouds ”, etc.), you want to say that I don’t know the architecture of my enterprise ? ”This is to the question of consumers of EA.

Most of the well-known descriptions of structures, frameworks, approaches to description, principles, framework methodologies (frameworks) were created specifically for the description of IT architecture, architecture of information systems. Initially, 1984th, that in 1987th, that in 1992th, they had just such names, for example, “A framework for information systems architecture” JA Zachman
Zachman87 (5x3)
Zachman92 (5x6) The
name ISA framework is used more precisely (information systems architecture).

After a while, through the understanding "that a different scale is needed", from the "light" hand of IT giants, including IBM (J. Zahman worked there), the "structure of the architecture of information systems" began to be called (replaced) by the "structure of the architecture of the enterprise." With the help of such “magic” a “qualitative transition” took place from the discussion of IT elements (artifacts, entities) to the discussion of “enterprise-building”.

This is a different scale, different price tags and budgets (EA does not happen cheaply), a different status of direction / discipline.

One thing is “IT modeling” and quite another is “business modeling / enterprise modeling”. Something similar, the “magical” substitution of concepts by the term BPM was shown in Business Processes: How Everything Is Launched and Confused. Chapter one

The legend from IT says: approaches to building an IT architecture were subsequently generalized to consider not only IT systems, but also to describe the enterprise as a whole. But this is a controversial statement, because there are still no convincing examples (detailed examples of EA in the public domain).

So, you need to learn to distinguish between real EA and the "architecture of enterprise information systems." These are “two big differences” (flies and meatballs). Real EA - begins with the fact that both words in its name are correctly applied in it.

Sometimes the term “enterprise system architecture” is used, which is synonymous with “enterprise information system architecture”, “IT architecture”. At the same time, it is often clarified (prefix) that this is precisely a "system" or "IT" architecture - they omit and say, as if "about the real" EA, but in terms of IT. Plus, the term is dependent on the era: “digitalization”, “automation”, “informatization”.

Thus, consciously or not, but there is a substitution of concepts, the initial understanding of the purpose of the introduced terms.

There is a substitution of values: instead of the initial ones — the construction of a certain mathematical apparatus, the prototype of a new engineering discipline, and maybe a scientific direction — there is a “rolling down” to a feast with the goal of monetizing the ideas of EA and approaches to its description, which remained at the level of alchemy. This is a key criticism of Enterprise Architecture.

1.2 The second myth - "architectural"

Many “smart” approaches have been invented: process, design, system, integrated, program-targeted and other “correct” approaches. I would try someone to say that he relies on an unsystematic approach or an incomplete one.

In most cases, instead of a “beautiful” mention of the “right approach”, it is better to give specifics, for example, in the case of a “systemic” one, give a diagram of this very system.

It would be logical to assume that when considering the direction of "Enterprise Architecture" an architectural approach was used. What it is? Another “right” approach?

When people pronounce the word “architecture”, they most often mean the architecture of buildings and structures, i.e. in relation to architecture.

But the term "architecture" has a broader concept, a deeper meaning. But not as it is customary to mean (by alchemists) in EA.

For some reason, in the interpretation of “IT-oriented trendsetters in EA” (including IT architects and CIOs), the name EA is a certain area in IT and that the concept of “architecture” in EA has a special meaning (not commonly used for the term “architecture” ) only on the basis of the principle: "whoever got up first, that and slippers." Why is it that IT objects are mainly drawn in the pictures that supposedly display EA? Is there a reference to an IT strategy, etc.?

And all this, despite the fact that the wiki gives a completely objective name (generally without mentioning IT):

Enterprise Architecture (EA) is the discipline for proactive and holistic enterprise management by responding to destructive forces by identifying and analyzing the necessary changes in the direction of the desired business vision and consequences.
www.gartner.com/it-glossary/enterprise-architecture-ea
Wika gives an equally vague answer: en.wikipedia.org/wiki/Enterprise_architecture

Enterprise architecture (EA) is a clearly defined practice of constant (eternal!) analysis, design , planning and implementation of the enterprise using an integrated approach in order to successfully develop and implement a strategy.

There are so many definitions of EA that are so different that talking about EA - as something unambiguous - is pointless.

What is EA?
What is architecture?

1.2.1 SubMyth of "detail"

Sometimes a description of “architecture” is understood to mean a detailed description of the specific elements of the object in question (the enterprise and its components), up to the specification type specification, working draft \ working documentation (as applied to GOST for construction or ACS). Architecture is not a detailed description.

The term architecture - is a conceptual expression, a description of architecture is a description of a concept, conceptual model, general "architectural elements" of an enterprise-type structure (description of a frame, skeleton).

There may be sub-architectures, microarchitectures, nanoarchitectures, but all the same, these are some concepts, general models, general principles of construction, styles. Moreover, this rule (at least, the rule of the Russian language) “works” for building architecture (architecture), processor architecture (x86 architecture, microarchitecture) and many other correct uses of the term “architecture”.

Examples

With regard to architecture: the style and variety of architecture are synonyms:
ancient Greek architecture, architecture of ancient Rome , etc.

The architecture of Ancient Rome is used in exactly the same way as the Architectural style of Ancient Rome.
Fundamental point: enterprises should be "different", but their architecture - no! In any case, the statement: “each enterprise has its own unique architecture” is not true. For this, the term "architecture" was coined.

Architecture is a certain framework (certain elements such as a rib, arch, column, built in a certain order that defines a certain type of framework), general approaches to building a building or enterprise. There are many different buildings, but it is architectures that are few.

For example, outside the term architecture, the following approaches:

• difference in scale: both “large” and “small” can have the same architecture;
• the difference in the material of manufacture: a building with the architecture of the "pyramid" can be made of many material options.

A microprocessor of the same architecture can be manufactured using different technologies (topology).

Let's look at the "processor architecture", type in google "architecture x86".
All pictures are approximately the same: data bus, address bus, control bus, etc. Completely different computers (from embedded to high-end servers) can have the same architecture (x86).

Why can't enterprises do this? With the "architectural approaches" in architecture and microelectronics (and other fields) - everything is clear. But with EA - no, in it in the concept of "architecture" - they put a different, special meaning (marketing). What for?

In relation to EA, “architecture” is a high-level representation (generalized structure of objects and processes, enterprise concept) that describes in a structured form the key components and activities of the enterprise, regardless of the specific organizational structure or IT system.

A model, but not a specific model of a particular enterprise, but a conceptual high-level complete (of its various components and not necessarily IT component) model of a certain class of enterprises. There was a discussion on this topic, see comments from "bipiem" habrahabr.ru/company/technoserv/blog/343350

EA science should include not only “skeletons” - frameworks, certain techniques and manuals for describing architecture, but, above all, reference (reference) models of typical enterprise architectures. It should focus on standards and the free exchange of architectures. Secondary are the description and notation approaches: which squares and circles in the diagram indicate EA objects.

Every enterprise has an architecture (a conceptual high-level model), just like every building and processor has an architecture. It may be typical or unique, but it is always a concept.

The level of architecture abstraction is limited, because “Conceptual” and “detailed” are mutually exclusive. Claims that all “enterprises are unique, therefore their EA are specific (unique), i.e. EA is always unique ”- this is the same as the statement“ all buildings of the same architecture are unique ”. Yes, the buildings are unique, but their architecture is not (with rare exceptions).

For a detailed review of the enterprise, the “enterprise-as-a-product” approach can be applied with a full set of “how the enterprise works” drawings, up to “every screw”.

Such a set begins with the Scheme for dividing the product into components and continues with a description of each software, including software (see GOSTs on ACS 24.xxx or 34.xxx, PB 15.xxx). This presentation ends with the answer to the question: how to make (a developed component) or buy (a purchased product) any element (screw) of the system called "Enterprise". But this is not an architectural representation.

Provide architecture - for the description of specific algorithms, the relationship of objects (some elements with others) - this means trying to make another type (class) of design documentation from the architectural representation.

Those. architecture description is not design (working) documentation (how is this arranged?), not operational documentation (how to operate it?) and not technological documentation (how to make it?) in the usual representation of GOST or similar western standardization systems (with the exception of BPM alchemy & EA).

Description EA - this is not a detailed consideration, but only an attempt to identify architectural features (through abstractions) and compare them with other architectures, to find common and different to correlate the architecture of the enterprise to any kind (style, variety, concept).

If we are talking about a detailed description of the enterprise’s work, all its business processes, the interdependencies between business objects and IT objects, formalization of the logical structures of the enterprise and its individual devices (components), then this should be called: complete (absolute) documentation for the enterprise , and the process is the development of a set of design documentation for it.

If this is only the case, then there is no need to make “out of an elephant's fly” and arrange “EA euphoria”. It is enough to take as a basis the principles for describing a “product”: that there is “a sapper shovel” or “submarine”, that an automated process control system or “automatic control system by strategic nuclear forces” - there is no fundamental difference. They put a set of documentation "shovel" or "enterprise" on your table and you can give it to the factory - they will make exactly the same for you.

According to the technical specifications (TU), you can check the conformity of the manufactured enterprise (product) with the documentation set and know about “every screw of the enterprise”, up to its specification code and sheet number where it is shown.

Many gurus for a detailed description of EA, but many consultants object: a detailed description of EA is a scattering of resources to describe all the elements of architecture, and this does not need to be done, but only a description of the "architecture", specifically and in detail, but not all.
However, the border - where there are still details, and where the "architecture" is already - is apparently a gift, "given out" only to consultants. This, as a rule, is the “flexibility” of the tool or framework, the “adaptation” of the general method (technique) to the specifics of the enterprise, the “competent” application of “Best Practices”, i.e. complete heresy, which justifies the inefficiency of the approaches used and disguises alchemy.

I have a close view of the architecture shown in dragon1. A

concept is defined as an approach abstracted from its implementation. An example of the architectural concept of the "amphitheater" and its implementation, the Colosseum, as a combination of the principles of building a stadium and a theater into a typical building in Rome, an amphitheater, is given.

Surprisingly, on the covers of many books and articles on EA, images of ancient architecture architectures are emphasized, thereby hinting at a borrowed approach, but in the future the classical architectural approach is distorted in EA by the transition to implementation details and the IT plane (magical “digital transformation” )

How many A4 pages do you need to show architecture? If according to Zachman - then one landscape format (30 cells) should be enough?

“Popular EA books, frameworks such as TOGAF or IAF, and even academic articles, suggest that EA provide comprehensive descriptions of the organization’s current and future conditions, as well as a roadmap for transition between them.

Essentially, EA core literature typically describes EA as a thick “book” full of various diagrams with four different “chapters”: business architecture, data architecture, application architecture, and technology architecture.

Well-known EA guru Jaap Schekkerman claims that EA is "the complete expression (description) of the enterprise." Accordingly, core approaches to EA, such as TOGAF ADM, show that EA, as a comprehensive book, is developed step-by-step, chapter by chapter, and then used as a planning tool. ”

Relationship between enterprise architecture artifacts
Eight essential enterprise architecture artifacts

Those. a comprehensive description of the entire enterprise down to the "screw" and each "process"? Moreover, in “as is” + “to be” + “roadmap”? In most cases, all three components will become obsolete until crowds of architects come to the finish line (they finish their EA poem).

1.2.2 SubMyth of “uniqueness”

Following the approach shown above: “architecture” does not imply a detailed description of objects and artifacts of an enterprise, including the IT landscape, the structure of specific IT objects, and IT artifacts. “Architectures” - as some concepts that should be comparable (this is the purpose of the approach) and abstract from the “concrete”.

Each enterprise has its own unique architecture - it is a “management fad” implanted by consultants (an advantageous position for increasing sales). None of them claim: each processor has its own unique architecture, each building has its own unique one.

In some cases, it is possible to develop unique enterprise architectures, but this is comparable to the development of a new processor architecture, computational process architecture, a new architectural style in architecture, etc., including the “discovery of a new star”.

That is, this is an exceptional case, requiring a completely different level of study, costs and risks, because most often this entails the rejection of a standard, unified, standardized, approved. Even if we are only talking about integrating (assembling) a new architecture from borrowed blocks from other standard architectures (EA).

Enterprise architectures should be classified and standardized. There should not be many. They can not be many, because these are “concepts”, “frames”, “supporting structures of the enterprise” (beams and skeletons). But for this (comparison and classification) you need to see them (publish).

In any case, from the position of EA, two enterprises can have an identical architecture even if in one of them “everything is on Microsoft”, and in the other “all on Linux” or in one “all on IT” (high level of automation), and in the other no computers at all (zero level of automation). IT architectures may be different, but EA - the architecture is identical.

The picture about “uniqueness of EA” and “publicity of EA” is shown in the next paragraph.

1.3 The myth of the “naked king”

There are times when a phenomenon or object is not visible to the naked eye. However, they are accepted on faith, as according to them there are scientific justifications for their existence, which can either be indirectly verified or there is a consistent rigorous theory.

In contrast to this approach, there is a “naked king” effect that is widespread in business (a PR component) and is sung in a fairy tale.
In relation to EA, I am inclined to such an effect, because enterprises are “dime a dozen” - and even the smallest one has architecture (I hope this is not in dispute), the architects divorced themselves - “like @ ...”, books, courses, trainings, general approaches , frames - frameworks - gig-tons of electronic waste paper.
But there is not a single example of this very mysterious EA. Why?

The legend of the “naked king” favorites is: EA exists! It is unique to every enterprise. Publish it in the public domain - it is impossible, because This is a competitive advantage over enemies (competitors). Description EA will reduce competitive advantage, because the enemy will understand what your (wonderful) architecture is! EA is the biggest trade secret of the enterprise, and it must be kept secret, as well as the salaries of the enterprise management.

Therefore, nobody publishes EA specifics, protects the NDA, etc.
The more incredible stupidity - the easier it is to believe in it. To begin with, EA is a conceptual layer (by definition) and there are no IP addresses there. There is nothing secret in it, except that it is most often waste paper with a very serious cost (these are really two big secrets).
Therefore, for consultants - NDA, and in the companies themselves - this is “Particle Board”, up to “information of special importance”.

As soon as real EAs begin to publish, an “awkward pause” is formed - why was so much money spent “on this”? I would like to make a mistake. In any case, the myth will be dispelled: it will become obvious to everyone and everything, for example, that “the king is naked” or vice versa - “what style is EA on him” and that investments in this very EA were justified.

1.3.1 Mysticism. Elusive Enterprise Architecture example

Why does the button in google: “Enterprise Architecture example” not work? Where are the examples? Specific and detailed.

It was not even possible to find options for filling a simple table with the name "Zachman Framework" for a specific Russian company to model the architecture ... (architecture of what? EA or ISA).

Attempts to "Look at a specific example of EA" are all one (two): either "buy a project on EA" or (the cheapest) "take our paid course, we will show you TAM (and then" for a very big secret ")."

On the street they also sometimes come up to me, “cook pots” and tell about the same thing correctly (actually ready-made EA consultants) and the same stories as with EA: “look - it’s shiny, it’s very cool, you just buy it.” Compare with outdated and new EA and BPM spells - from reengineering to digitalization. Plus an obligatory phrase from a typical script of BPM \ EA sellers: “the main thing is to understand - you have specifics! Only an exclusive is suitable for you, you need a saucepan (EA) unique and inimitable ”:



Awareness of the benefits of a typical approach, publicity and the exchange of practical experience (not mantras), publication of EA descriptions (BPM) are a crushing blow to alchemy. However, the situation so far is as in the figure: “business uniqueness”, “a special path along the path of digital transformation”, NDA - the key to the failure of EA projects, inefficiency and the eternal invention of bicycles.

Where can I see a full-fledged holistic EA on or without any framework? At least on one A4 according to Zachman or a chubby pile of books on Shekkerman? Although EA is a bakery, even EA is a “public domain” (Gazprom, etc.). At least "one eye"?

1.3.2 Exposing the King's Tailors

There are simple ways to either prove that “And the king is naked!” Or show that “everything is fine! The king’s outfits are correct, and EA is not an alchemy at all, but a real science. ”To do this, you just need to start publishing these very descriptions of EA.

How to start the fight against alchemy? You can start with the“ smallest ”- small enterprises. They have EA should be simpler than that of corporations. Let us return to the question of what kind of enterprise is in the context of EA?
These are both small business enterprises and holdings, even households and the state itself. Why are consultants and system integrators interested only in complex EAs, holdings, industrial clusters large business c? It's better to start with simple examples.

Interest exclusively in corporations is due only to the fact that they are “rich Pinocchio” and therefore the project “description of EA” is measured in “round sums”. But the approaches to the description of this EA itself are exactly the same as to the description of the “EA household” .

Why don't each “architect,” juggling EA concepts, design an architecture for his own household? Why no one describes EA boutique, bakery, kindergarten?

Second approach. Why integrators and consultants gladly describe the architecture of others, “convincingly proving” that “this is a competitive advantage”, etc., but they don’t publish their architecture (of their company), but they also don’t describe it.
Or do consultant companies have no EA? What NDA do they justify?

You need to introduce the rule: “if you want to describe the EA of others” - “start with yourself”, first “describe yourself” and publish your EA. This will at least say something about the subject of the study itself (description of EA) and the competencies of the consultant in this subject. Conclusion: the description of the EA of a third-party enterprise - you need to license, without a license you can make a description of EA only of your enterprise.

I would extend this rule to the publication of books on EA, where in the preface there will be a mandatory url link to a full-length description of a particular EA.

The third.State-owned companies. Issue a decree or decree: all companies where there is at least a penny of capital participation by the state structure (i.e., a company with state participation) must publish their EA. On what methodology the EA description will be built - it does not matter, you can choose any known Best Practice (or limit them to a list) or develop your own.

There are objections: “EA is IP. Who will hand out such a gift? ” This refers to Intellectual Property, intellectual property, a kind of secret success story.

Let's look at this same “IP” - from us, ordinary citizens - taxpayers. One company developed EA for state-owned company No. 1. We (taxpayers) paid. Further, the same company or another company also developed EA for state-owned company No. 2. And, possibly, exactly the same. We (the people) paid again.
Then again, for state-owned company No. 3, they made the same EA, and we (since funds from the budget) were again robbed.

Do we need such an IP? If for the same thing (the same EA) we pay our own money, budgetary, which are from our own pocket?
Thus, not only the people are robbed, but also the GDP is being boosted: by supplying “the same” and taking “development” (read reuse) in full “as it should” and “improving” statistics (completed volumes).

I'm talking about unification, duplication, publicity (transparency, publication of not only the fact of the purchase, but also the result), reuse (borrowing), the effective development of previously paid budget funds (including mine), optimization of PEOPLE'S investments.

Fourth. For commercial companies, the government (state) can announce a competition for a more “correct EA”, while creating a “common EA repository”. Or “make it easier”, just as for state-owned companies to oblige by law (as in “Third”): I handed over the accounting report, also attach your EA.

A good example of popularizing an open discussion of EA examples is the counterpart to the nationwide contest “BPM - Project of the Year”: bpmaward.ru
What is the national competition "EA - project of the year" worse than "BPM - project of the year"? Or maybe this is one and the same thing?

Fifth. A reader of these lines, “happy to have a fresh little EA” might think: the consultants made EA for my enterprise, it would be nice to check: is this exactly EA? Did they do the job well? I did not overpay?

Discarding the prejudices about the "competitive advantages of not publishing an EA", such an EA holder will decide to publish a description of this EA with the question: is it EA at all? What mistakes were made in its preparation? How much should such a project cost (red price to the project)?

I won’t be surprised that after the publication of “cool EA”, of course, someone will exclaim bravely for the “astronomical price”: bravery: it’s “Malevich’s Square, only a special“ connoisseur ”can see the outlines of architecture, and even the enterprise.”

Sixth. It would be nice if simple rules were established for books about EA, descriptions of new methodologies and frameworks: a comprehensive example of at least a small enterprise.
Remember, there was a book: Jordain R. - Programmer's Guide. It initially said “what to do,” and then three options for the solution are shown in detail: at the upper level (basic), medium and low. I would like to find something similar for EA: an example of one enterprise in implementation according to several EA methodologies / frameworks!

1.3.3 Total, Open EA

After the publication of specific EA (real companies), we will observe a complete mess of ideas about EA (I would like to make a mistake). Why is porridge? Because in the descriptions there will be “someone into the forest, some by firewood”, because at the heart of such descriptions - is still alchemy, not engineering.

“Approbation” of the approaches is only in the imagination of the architects themselves, upon completion of the next EA project, sticking another star on their cardboard framework. There is still no objective confirmation (have not met).
I remind you that we are talking primarily about the description of EA, not IT architecture, and “description” means not advertising products (presentations). Although the creativity of Solution \ System (SA) and Infrastructure (IA) architects would also be interesting to see in the public domain (full-size examples, not fragments).

The architectural porridge of newly made architects will either “run away” or be distributed among the “plates” (directions) of “IT architecture” (IT plate, ie SA, IA, etc.), “business architecture”, etc. Then it will be clear: flies separately, cutlets separately.
An elementary order will be put in place, the marketing heresy will be dropped, the main question will be clarified - what will remain on the sheet with the heading "Enterprise Architecture", i.e. "Just Enterprise Architecture", which is drawn by none other than Enterprise Architect.

Any discussion of EA, like any other architecture, will begin with a comparison of other architectures also published, i.e. from a comparative analysis: both the architectures themselves and the correlation of a particular enterprise (as in the case of a building, processor) to a specific type (style) of architecture (microarchitecture).

I’m sure that during mass publications EA will be partially undertaken a maneuver of type “feint with ears”, for example, “whip up” filling 30 cells of the Zahman table with the following statement: “this is ALL our EA”! But such hyper-simplification will simply show the competency level of “local architects”.

EA publications will reveal an important detail: it will be clear in what cases, there were deliberate para-scientific fabrications of consultants in order to "earn extra money on alchemy", and in which - bona fide misconceptions. The former will be less willing to print their "masterpieces" in EA (and advise their customers not to do this).

Perhaps someday modern approaches to building enterprise architecture will be called “ancient science of enterprise architecture” (alchemy is also called “ancient chemistry”), but so far this modern alchemy is undergoing its “golden age”. We were previously warned about this, for example:
"The rush fashion" for architecture "can lead to the fact that the approach necessary for IT will take a couple of years into the darkness of pseudoscientific articles ." www.osp.ru/os/2006/03/1156580 The total
darkness over EA has not passed for decades and even today there is no clearness:

2 Criticism of Enterprise Architecture

2.1 EA criticism from the wiki

Critics of approaches to the description of EA are not many, I think because this is such a vague concept that it is not entirely clear what to criticize.
However, there is criticism, for example, EA Criticism
- Ivar Jacobson: Most EA initiatives have failed. I assume that more than 90% never led to anything useful ”;
- Erasmus University Rotterdam IDS Scheer: two-thirds of EA projects have failed to improve the alignment of business and IT.

“Business and IT alignment” - some words were invented. The term was introduced, apparently, to at least somehow "justify" the introduction of expensive IT systems that do not provide adequate (or rather, at least some) return on investment in IT: such as the reason - the ignorance of the business, which is much "behind the advanced IT" (i.e. very expensive IT).
The Automators themselves are “white and fluffy”, but the “dark” business did not understand their “deep intent”, therefore, failures on EA projects (it is also not customary to talk about failures).

Sometimes EA is used (disguised) - as a “bridge” - as the CIO’s desire to “steer the business” or at least stand on the captain’s bridge on an equal footing, and not present IT — just as one of the supporting divisions of the company;
- Stanley B. Gaver: The EA federal program as a whole failed.

In favor of Haver’s arguments, it could be said that if something like this (FEA \ FEAF or other EA) would really work and USA as well as ARPANET would transfer the technology to the world community, today we would have a new TCP \ IP at the business level , i.e. "Business net". Business hubs, switches, business protocols, absolute standardization, a standard “business stack” would appear, and “business routers”, etc., would be sold in electronics stores.
Fragment from wiki already according to framework en.wikipedia.org/wiki/Enterprise_architecture_framework

• Historical analysis of EA publications shows that “EA frameworks” are “nothing more than typical managerial quirks aggressively promoted by consulting companies and gurus.”
• About management quirks: en.wikipedia.org/wiki/Management_fad
• Studies show that EA frameworks seem theorized and impossible to implement.
• Vivek Kundra, US Federal Director of Information Technology: “EA frameworks” - “worse than useless.”
• Jason Bloomberg reports that EA frameworks are wasting architects' time instead of solving real-world problems. “EA frameworks is cocaine for executives - they give them huge rush (buzz, excitement, aspiration), and then they move on to the next frameworks.”

2.2 Laws of #BPM (Business Process Management)

improving-bpm-systems.blogspot.ru/2015/07/laws-of-bpm-business-process-management.html
Related areas of alchemy are intertwined in places. It is very difficult to distinguish where BPM ends and EA begins. Therefore, their myths are identical, but alchemy.

Law 1

Each BPM (EA) provider, each BPM (EA) consultant, each “body-of-knowledge” BPM (EA), each methodology and framework, and each BPM (EA) client understands BPM ( EA) in different ways. This is a distinctive feature of any alchemy.

Law 7

Properly made BPM is 50% Enterprise Architecture (EA).

Apparently true and vice versa: Properly made EA is 50% BPM.
In general, it is strange that does not take into account BPM compared to EA? What can be considered BPM without organizational structure, without inputs and outputs of processes?

Any "dynamics" in EA is already a process, i.e. BPM And in BPM they ask and describe everything related to the process. In fact, any life cycle of any object or artifact is a connection of its states through processes, i.e. directions of transitions (from one state to another).

Particularly difficult to understand are those who meet in one place: Managing the "enterprise architecture" and enterprise business process management (BPM). Such as "architecture management" and "process management", while the "data architecture" and other "sub - architectures" can be arbitrarily packed immediately in both of these containers.

Act 8

BPM problems (EA) arise due to the fact that his theory is not completed and not confirmed. In other words, if it is not alchemy, then it is not a scientific or engineering discipline. Interesting, and then what?

The most accurate conclusion is specified in Law 14:
Corollary 1 BPM (EA) community is a group of alchemists.
He cited only a part of examples (laws), the rest we look at the link to the blog of A. Samarin.

2.3 Enterprise Architecture is ... DEAD!

Often, on unsuccessful BPM and EA projects, the conclusion is: A fool with a tool is still a fool.
Enterprise Architecture: Don’t Be a Fool with a Tool
www.forbes.com/sites/jasonbloomberg/2014/08/07/enterprise-architecture-dont-be-a-fool-with-a-tool

“Fool with the tool all still a fool ”- words of wisdom in IT. Thus, a hint is made that if you didn’t succeed in the project on our “ingenious” TOGAF and Zahman tablets and 50+ similar “Best Practices”, then you don’t need to talk about it - i.e. expose yourself and your partner as a fool (vendor, integrator, consultant, customer). Here is such a convenient "folk wisdom." Convenient, exclusively for alchemists and their victims.

The same author (Jason Bloomberg) claims that

over the years since John Zahman founded the new direction of enterprise architecture (EA) in a 1987 article in the IBM Systems Journal, EA has achieved a surprisingly negligible level of development (success).
... The stories of abandoned or failed EA initiatives far outperform real-life EA business examples.

Is Enterprise Architecture Completely Broken?

“Unfortunately, EA is often synonymous with documenting the views of one person on their company's IT,” Grisi complains.
I emphasize: it’s on IT, it’s on documentation and just the subjectivity of the architect. This approach was supposed to die in the beginning.

However, the second slide: Enterprise Architecture is ... DEAD! - too optimistic.
www.opengroup.org/public/member/proceedings/Johannesburg-2015-03/Presentations/The%20State%20of%20Enterprise%20Architecture%20Globally%20-%20James%20Thomas.pdf

In a good way, “EA is like alchemy” - the end should have come a long time ago, but today it is a very good segment of the business where the main thing is not the result (where is it?), But the “process” (the classic slogan of BPM). IT Wizards with the EA Consulting tag have learned from practically nothing to mine gold: EA’s highly profitable consulting business. Classical alchemists were far from such "mastery".

Therefore, the article used a negative connotation to such consulting: most often, professional architects know (suspect) of the pseudoscience of the approaches used, but, like magicians, "do their job" and keep secret the failure statistics and the "tricks" themselves: not classic frameworks (they are published) how much is the art of manipulating them and the mind of the customer.

Therefore, one more definition can be given, EA is basically a modern approach to alchemy, authorizing and methodically guaranteeing income from practically nothing, using the old and modernized EA & BPM spells, magical framework (last century and very fresh) , abstract formulations, such as:

“ Enterprise architecture sets the path to achieving the organization’s mission through the optimal functioning of its key business processes within an effective IT environment .” Jaab Schekkerman, Institute For Ente rprise Architecture Development (IFEAD).

If it was a wound (old spells): business process reengineering and cost optimization, cost and risk reduction, now these are “improved spells”: an adequate response to changing market challenges, implementation of a business strategy through digital transformation, digitalization of business and enterprise, alignment business and IT and other mantras.

2.4 Enterprise Architecture Frameworks: The Fad of the Century

The Fad of the Century
One of the few examples of open and sharp criticism of EA:
“ ... all the popular EA frameworks and their conceptual predecessors are obvious marketing-oriented management tricks (fantasies) without presenting examples of successful implementation. Although numerous marketing publications have consistently positioned EA frameworks as “best practices,” evidence-based research has consistently demonstrated opposite conclusions.

Various consultants and gurus make their money by selling what can be effectively sold, regardless of whether it works or not.
For example, John Zahman, the “father” of EA, who previously promoted the BSP erroneous methodology during his previous 26-year marketing career at IBM, recently acquired the Federal Corporate Architecture Certification Institute (FEAC) and is now actively selling certificates and training at the FEAF, EA framework which is largely responsible for the billion dollars spent by taxpayers invested in the FEA program.

FEAC members continue to promote certification programs in the same EA structures that are erroneous "best practices." The madness here is that the EA expert community still does not recognize EA frameworks as another management fad, and many EA experts still want to get certified for some of these EA frameworks.

The fact that consultants can sell the same worst-selling methods called “best practices” for several decades, even when reliable information is publicly available, demonstrates the unlimited power of endless marketing promises and the complete impotence of evidence-based common sense. This situation clearly illustrates another notorious statement: "a lie told a thousand times becomes the truth."

... there are no practical ways to populate 30 or even 15 Zachman Framework cells. ... There are no practical ways to develop all or even half of the documents recommended by TOGAF ... "

Management fad- management concept, which has a beautiful name and offers a new way to increase efficiency; usually developed by a management theorist or consulting company, then becomes popular with a wide range of management theorists and practitioners, provokes a large number of studies, publications, seminars, etc.,
after which its popularity gradually falls, and it gives way to new fashionable concepts ; since creating a successful popular concept is a very profitable business for consultants and theoreticians, the latter pay special attention to its effective formulation and promotion, sometimes the external side greatly outweighs the real content.
slovar-vocab.com/english-russian/new-management-work-economics-vocab/management-fad-1127771.html

I agree with Svyatoslav Kotusev: EA is a scam of the century. Of course, criticizing EA and “throwing stones” at its frameworks is easier than offering something more constructive, but someone should say that “the king is naked”.
Praising the transparent “King's dress” and worshiping alchemy is an even easier and more convenient way for many. To build something new, you need to "clear the place", expose the myths of previous approaches.

Svyatoslav also inherited the “poor” Togaf:
The critical scrutiny of TOGAF
Excerpts:
“ ... I want to note that TOGAF appeared in 1995, and its main elements, such as ADM, have remained practically unchanged since then. How can it be that“ the best practice ”, developed more than 20 years ago, still cannot be implemented anywhere ...

... TOGAF is based on TAFIM, but TAFIM was confirmed to be unsuccessful because EA projects required huge investments of time and money, as a result of architecture they often became outdated before the project was completed, and business customers usually could not understand them. If TOGAF is based on TAFIM and TAFIM is unsuccessful, how can TOGAF be based on best practices?

In the light of these observations, it becomes clear that TOGAF does not reflect real practice ... At the same time, The Open Group's promise that TOGAF "provides the best practice can only be seen as typical meaningless marketing statements aimed at promoting sales ...

For example, there are currently more than 52 thousand TOGAF certified people worldwide. This means that the Open Group has earned at least $ 23 million in TOGAF certificates alone.
If you add various training, courses, books, conferences, consultations and other profitable TOGAF services provided by The Open Group, then this number is likely to be much larger. If you were The Open Group, wouldn't you say that TOGAF represents best practice?

Numerous gurus, trainers, instructors, experts, consultants, certification authorities, etc. associate their fate with the “sale” of TOGAF. Not surprisingly, they are all interested in promoting TOGAF and avoid any criticism of it.

... the situation seems hopeless, since probably not one of the influential players on the EA market is motivated to offer any alternatives to TOGAF: if people are willing to pay for TOGAF, then why invent something else?

The third factor is the shameful (or even criminal) inertia of the EA research community, to which I belong. Unfortunately, EA researchers usually do not give an objective analysis of the situation in the discipline of EA ... In this atmosphere of ignorance, numerous myths, legends and superstitions related to EA spread very quickly ... EA academic researchers are usually obsessed with producing “scientific” theories instead of answering real practical questions.
The fact that TOGAF is now being taught at a prestigious university clearly demonstrates the surrender of the army of academics to marketing aggressors . "

It’s exactly the goal. The direction of Business Informatics in domestic universities specializing in EA has actually turned into a manual on alchemy. So, science in the country is the corral, and here also the alchemists dug in. “

From the Enterprise architecture is not TOGAF
" ... the EA community should take a sober realistic look at the existing EA literature, critically review and rethink their idealistic ideas, which are currently very far from real EA practices in organizations.
Evidence-based new sources of information about EA are essential as a replacement for the mostly useless, but actively promoted EA frameworks. "To the

admirers of TOGAF - I propose to take part in the competition for the description of" household architecture "(third paragraph of this article).

2.5 Soft criticism

There has been a lot of “soft” criticism (see google) of modern and not at all modern approaches to EA on the Internet for a long time, only a “boiling point” has not yet arrived, possibly because “so many have turned out to be in the share”.

A lot of what was said above is repeated in the blogs of Western critics, though in softened formulations, perhaps because they earn their bread from this very EA.

filipebartolomeu.weebly.com/blog/tackling-enterprise-architecture-criticism
searchcio.techtarget.com/blog/TotalCIO/Two-IT-gurus-face-off-on-value-of-enterprise-architecture-frameworks

It is strange that I did not find such criticism in Runet. This suggests either that, unlike Western experience, in Russia most of the EA projects are successful (to the surprise of all of us and the envy of the bourgeoisie) or the level of maturity of Russian education in EA. I bow to the second option.

If we are not talking about alchemy, then the principle should be taken into account: "the existence of only our thinking self is certain, the existence of everything else must be questioned."

3 Competition for the description of "household architecture"

I offer beginners and venerable architects of any EA denominations to write a description of their household’s architecture: “household architecture”. This will be the best confirmation that the "Enterprise architecture" in their understanding has a right to exist.

I hope that architects will agree that the household has an architecture and that “household architecture” (HA) can be represented on the basis of well-known approaches to describing EA. I also hope that when describing their HA, no one will need an NDA for a spouse.

The conditions for participation are simple: architects show their “household architecture” in detail, tell how they built it and provide links to the framework used. However, you can bring any other "simple architecture" of the "simple enterprise": kindergarten, kiosk "ice cream", etc.

It will be even better if:
A) architects will cite several HA architectures, indicating their architectural differences;
B) the description of the same ON will be shown on different approaches, description methodologies, frameworks.

We give links to the descriptions of NA in the comments on this or the next chapter (article). In it, in turn, I will publish my vision of NA. By voting we will determine the most “correct”, most “architectural” household architecture. Notify familiar architects (including EA, SA, IA and other хА), give them the opportunity to make a feasible contribution to the development of EA \ NA. Is it enough for us architects to do this? The task is not archi-difficult.

So, writers of articles about EA, especially those living on a hub, - send your NA \ EA. You do not need to be shy: think, draw, "architecture." Why talk about complex EA, let's talk about simple NA.
'Non-alchemysts' aller Länder, vereinigt euch!

Imagine the chagrin of many alchemists when:

• in simple language it will be shown what EA is and is confirmed by concrete examples in understandable manuals;
• understanding will come that ordinary mortals can draw up a description of architecture without the help of the magic of alchemists;
• it turns out that in most cases it’s not necessary to reinvent the wheel at all, but only to borrow the standard (typical) architecture. Or maybe even a whole design solution that meets the desired architecture.

Yours, bipiem