Enterprise Architecture vs alchemy enterprises. Key myths

Alchemists were moving about the same thing as modern scientists - they wanted to understand how the world works . They studied it as best they could. Later, the ancient Proto-science evolved to the current state of science.



This is true for the modern discipline "Enterprise Architecture", you only need to make two clarifications: "in the 21st century alchemists moved ..." and "... understand how the enterprise works."

')

On the pages of IT Internet, the subject of Enterprise Architecture (EA) is one of the most popular. It gives you the opportunity to talk about the "high" - about the "architectural" approach, dozens of the framework, to feel yourself as an Architect "with a capital letter."



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



Books, academic disciplines, consulting projects, groups, consortia, entire institutions with a specialization of EA (IFEAD, iEAi, etc.), global organizations (GEAO), eponymous magazines (Journal of Enterprise Architecture), international standards (ISO 15704, 42010, etc. .) and so on.



However, in the context of EA, there are questions: what is “architecture”, what is “enterprise” and what is “enterprise architecture”, as well as who is the main consumer of EA and why there are no specific examples of this EA itself.



Methods, reference models and architectural frameworks (usually with an ending on “AF”: FEAF, TEAF, DoDAF, etc.) - “like dirt”, but there’s no real results to see.



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



The architects say that this is NDA, the “big secret”, the particle board (maybe even “state-secret”). But how can “architecture” be secret in general? On that she and "architecture" to be recognizable: distinguishable and comparable. But “Alchemy of an enterprise” should be kept strictly secret.



As a “litmus test” - as confirmation or refutation of the conclusions made in the article, a competition is announced for a description of its “household architecture”, see the end of the article. Why undertake the solution of complex problems, if there is no possibility to solve a simple task - give 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 is still not clear what is just “Enterprise Architecture” (like “analog”?), And outside the window they are already trumpeting “about a supernova”: “Digital Enterprise Architecture”, Digital Enterprise Architecture.

1 Myths of Enterprise Architecture

1.1 Framework for information systems architecture

Let's start with the most popular myth. This is when the substitution of “enterprise architecture” is made on “architecture of enterprise information systems”. An EA is not an IT architecture at all, and if you see large squares with SOA inscriptions or similar horror stories from the IT world on the page entitled “Furniture Factory Architecture”, then you should know: this is either “an absurd misunderstanding” (misconception) or “classical” conscious fraud .



The picture looks funny when the director of the company receives pictures (schemes) with the title “Enterprise Architecture”, where more than 90% of the objects are names from IT.



The director says: “I have been managing the company for 15 years, but I don’t understand more than 90% of the names you mentioned (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 a question about EA consumers.



Most of the well-known descriptions of the structures, "frameworks", approaches to the description, principles, framework methodologies (frameworks) were created specifically for the description of the IT architecture, information systems architecture. Initially, in 1984, in 1987, in 1992, they had exactly such names, for example, JA Zachman

Zachman87 (5x3)

Zachman92 (5x6)

More precisely, the name ISA framework (information systems architecture) is used.



After a while, through the understanding that “other scales are needed”, the IT giants, including IBM (J. Zahman worked there), became “easy” (replaced by the structure of the enterprise architecture) from the “light” hand of IT giants. With the help of this “magic”, there was a “qualitative transition” from the discussion of IT elements (artifacts, entities) to the discussion of “enterprise-structure”.



This is a different scale, different price lists and budgets (EA is not cheap), a different status \ discipline.



It is one thing "IT modeling" and quite another - "business modeling \ enterprise modeling". Something like this, the “magical” substitution of concepts for the term BPM was shown in Business Processes: How Everything Is Launched and Confused. Chapter one



The legend from IT says: the approaches to building an IT architecture were subsequently summarized 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 how to distinguish between a real EA and an "enterprise information system architecture." These are "two big differences" (flies and cutlets). This EA - begins with the fact that it correctly applied both words in its name.



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



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



There is a substitution of values: instead of the original ones - the construction of a certain mathematical apparatus, a prototype of a new engineering discipline, and maybe a scientific direction, - there is a “roll” to a feast to monetize the ideas of EA and approaches to its description, which remained at the level of alchemy. This is a key critique of the Enterprise Architecture.

1.2 The second myth - “architectural”

Many “smart” approaches have been invented: process, project, system, integrated, program-target and other “correct” approaches. Someone would try to state that he relies on a non-system or non-complex approach.



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



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



When people pronounce the word "architecture" - they most often mean the architecture of buildings and structures, i.e. applied to architecture.



But the term “architecture” has a broader concept, a deeper meaning. But not the way it is meant (by alchemists) in EA.



For some reason, in the interpretation of “IT-oriented trendsetters in EA” (including IT architects and CIO), the name EA is a certain field in IT and that the concept of “architecture” in EA has a special meaning (not common to the term “architecture” ) only on the basis of the principle: “who first got up, that and sneakers”. Why are the IT objects mostly drawn on pictures that supposedly represent EA? Is it referring to IT strategy, etc.?



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



Enterprise Architecture (EA) is the discipline for proactive and holistic management of an enterprise 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

Vika 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 an enterprise using an integrated approach in order to successfully develop and implement a strategy.



There are so many different definitions of EA that it makes no sense to talk about EA - as something unequivocal.



What is EA?

What is Architecture?

1.2.1 SubMif “details”

Sometimes a description of the “architecture” means a detailed description of the specific elements of the object under consideration (the enterprise and its components), up to the specification of the type specification, the working draft / working documentation (applied to GOST in construction or the ACS). Architecture is not a detailed description.



The term architecture carries a conceptual expression, the description of an architecture is a description of a concept, a conceptual model, common “architectural elements” of an enterprise type construction (description of a framework, a skeleton).



There may be sub-architectures, micro-architectures, nano-architectures, but anyway - these are certain concepts, common models, general principles of construction, styles. Moreover, this rule (at least, the rule of the Russian language) “works” for the architecture of the building (architecture), processor architecture (architecture x86, micro-architecture) and many other correct uses of the term “architecture”.



Examples



With reference to architecture: style and type of architecture are synonyms:

Ancient Greek architecture, Ancient Rome architecture, etc.



The architecture of ancient Rome is used exactly as well as the architectural style of ancient Rome.

The fundamental point: enterprises must be "different", but their architecture is not! In any case, the statement: “each enterprise has its own unique architecture” is not true. In order and coined the term "architecture".



Architecture is a kind of framework (some elements of the type edge, arch, column, arranged in a certain order, defining a certain type of framework), general approaches to the construction of a building or enterprise. There are many different buildings, but just architectures are few.



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

• difference in scale: both “large” and “small” may have the same architecture;
• The difference in material production: the building with the architecture of the "pyramid" can be made of many variants of the material.

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



Let's look at the "processor architecture", we type in "architecture x86" in google.

All pictures are about the same: data bus, address bus, control bus, etc. Completely different computers (from embedded to high-end servers) may have the same architecture (x86).



Why do businesses fail? With the "architectural approaches" in architecture and microelectronics (and other areas) - everything is clear. But with EA - no, in it the notion of “architecture” implies a different, special meaning (marketing). What for?



As applied to EA, “architecture” is a high-level view (generalized structure of objects and processes, enterprise concept), which describes in a structured form the key components and activity of an 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 an 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



The EA science should include not only “skeletons” - frameworks, certain techniques and manuals on the description of the 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 approaches to the description and notation: what squares and circles in the diagram to denote objects EA.



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



The level of abstraction of architecture is limited, since "Conceptual" and "detailed" - mutual exclusion. The allegations that all “enterprises are unique, therefore their EA are specific (unique), i.e. EA is always unique ”is the same as the statements“ all buildings of one architecture are unique ”. Yes, the buildings are unique, but their architecture is not (with rare exceptions).



For a detailed consideration of an enterprise, the approach of considering an “enterprise as a product” with a full set of drawings “how the enterprise is arranged” up to “each screw” can be applied.



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



Issuing architecture - for describing specific algorithms, interconnecting objects (some elements with others) - this means trying to make another type (class) of design documentation from an architectural representation.



Those. The description of the architecture is not design (working) documentation (how is it arranged?), non-operational documentation (how to operate it?) and non-technological documentation (how to produce it?) in the usual way of GOST or similar Western standardization systems (except for BPM alchemy & Ea).



An EA description is not a detailed consideration, but only an attempt to identify architectural features (through abstractions) and compare them with other architectures, find the common and different for correlating an enterprise's architecture with any type (style, variety, concept).



If we are talking about a detailed description of the work of the enterprise, all its business processes, 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 on the enterprise and the process is the development of a set of design documentation for it.



If this is just the case, then you shouldn’t do “out of the molehill” and organize “EA-euphoria”. It is enough to take as a basis the principles of the description of the "product": that "an engineer shovel" or "submarine", that an automated process control system or an "automated control system for strategic nuclear forces" - there is no fundamental difference. They put you on the table a set of documentation "spade" or "enterprise" and you can give it to the factory - they will make exactly the same for you.



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



Many gurus are for the detailed description of EA, but many consultants object: a detailed description of EA is a dispersion of resources on the description of all elements of the architecture, and this is not necessary, but only describe the “architecture”, and specifically and in detail, but “not all”.

However, the border is where the details are, and where the “architecture” is already is apparently a gift “issued” only to the consultants. This is, as a rule, the “flexibility” of the tool or framework, the “adaptation” of the general method (method) to the specifics of the enterprise, the “competent” application of the “Best Practices”, i.e. complete heresy that justifies the ineffectiveness of the approaches used and masks alchemy.



I look at the architecture shown in dragon1



The concept is defined as an approach that is abstracted from its implementation. An example of the architectural concept of the “amphitheater” and its implementation — the Colosseum — is presented, as a combination of the principles of building a stadium and a theater into a building typical of Rome - an amphitheater.



Surprisingly, on the covers of many books and articles on EA, images of ancient architecture architecture are emphasized, hinting at the adoption of the approach, but later on the classical architectural approach is distorted in the EA by switching to implementation details and to the IT plane (the magic “digital transformation” ).



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



“In popular EA books, frameworks, such as TOGAF or IAF, and even in academic articles, it is proposed that EA provide comprehensive descriptions of current and future state of the organization, as well as a roadmap of the transition between them.



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



EA's well-known guru Jaap Schekkerman argues that EA is "the full expression (description) of an enterprise." Accordingly, the main approaches to EA, such as TOGAF ADM, show that EA, as a comprehensive book, is developed in stages, chapters, and then used as a planning tool. ”



The relationship between enterprise architecture artifacts

Eight significant enterprise architecture artifacts



Those. A comprehensive description of the entire enterprise up to the "screw" and each "process"? Yes, even in "as is" + "to be" + "roadmap"? In most cases, all three components will become obsolete until crowds of architects come to the finish line (finish their EA-poem).

1.2.2 SubMif “uniqueness”

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



Each enterprise has its own unique architecture - this is a “management fad”, imposed by consultants (advantageous position for increasing sales). None of them claims: 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, a 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 development, costs and risks, because most often this entails the rejection of the standard, unified, standardized, tested. Even if we are talking only about the integration (assembly) of a new architecture from borrowed blocks from other standard architectures (EA).



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



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



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

1.3 Myth "naked king"

There are cases when some phenomenon or object is not visible to the naked eye. However, they are taken on faith, because according to them there are scientific substantiations of their existence, which can be either indirectly verified or there is a consistent strict theory.



In contrast to this approach, there is a widespread in the business (PR component) and the “naked king” effect sung in the fairy tale.

With regard to EA, I tend to have this effect, because enterprises - “a dime a dozen” - and even the smallest have architecture (I hope this is not disputed), the architects themselves divorced - “like @”, books, courses, trainings, common approaches , frameworks - frameworks - gigabytes-tons of electronic waste paper.

But there is not a single example of this most mysterious EA. Why?



The legend of the favorites of the “naked king” says: EA exists! It is unique for each company. 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! An EA is the biggest commercial secret of an enterprise, and it must be kept secret, as is the size of the salaries of the enterprise’s management.



Therefore, the specifics of the EA nobody publish, protect the NDA, etc.

The more incredible nonsense - the easier it is to believe in it. To begin with, EA is a conceptual level (by definition) and there are no IP addresses there. There is nothing secret about it, except that it is often trash with a very serious cost (these are really two big secrets).

Therefore, for consultants - NDA, and in the companies themselves - this is the "chipboard", up to "information of particular importance."



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

1.3.1 Mysticism. Elusive Enterprise Architecture example

Why the button in Google: "Enterprise Architecture example" does not work? Where are the examples? Specific and detailed.



It was not even possible to find options for filling in for a specific Russian enterprise a simple table named “Zachman Framework” for modeling architecture ... (architecture of what? EA or ISA).



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



On the street, they also sometimes come up to me, “put the saucepans on” and tell them about the same way competently (actually, EA consultants are ready) and the same stories as with EA: “look - it shines, it's very cool, just buy it”. We compare with the outdated and new spells of EA and BPM - from reengineering to digitalization. Plus an obligatory phrase from a typical script of BPM \ EA sellers: “understand the main thing - you have the same specifics! Only an exclusive will suit you, you need a saucepan (EA) unique and inimitable ":







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



Where to see a full-fledged EA in any framework or without it? At least on one A4 according to Zakhman or a plump stack of books on Shekkerman? Although the EA bakery, even the EA "national wealth" (Gazprom and etc.). At least "one eye"?

1.3.2 Exposing the King’s Tailors

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



How to start a fight with alchemy? You can start with the "smallest" - small businesses. They EA should be simpler than corporates. Let's return to the question, what is an enterprise in the context of EA?

These are small businesses and holdings, even households and the state itself. Why are consultants and system integrators interested only in “complex EA”, holdings, industrial clusters, big business? It is better to start with simple examples.



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



Why shouldn't every “architect” who juggles the notions of EA compose the architecture of his own household? Why no one describes the EA boutique, bakery, kindergarten?



The second approach. Why do integrators and consultants happily describe the architecture of others, “convincingly proving” that “this is a competitive advantage”, etc., but not only they do not publish, but also do not describe, their architecture (their company).

Or consulting companies have no EA? How do NDA they are justified?



We need to introduce a 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 research itself (EA description) and the competencies of the consultant in this subject. Conclusion: description of the third-party EA - you need to license, without a license, you can make a description of the EA of only your enterprise



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



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



There are objections: “EA is the same IP. Who will be giving it away for free? ” Intellectual Property, intellectual property, a certain secret success story.



We will look at this very “IP” - from us, ordinary citizens - taxpayers. One company developed EA for state-owned company No. 1. We (the taxpayers) paid. Further, the same or another company has developed EA for state company No. 2 too. And, perhaps, exactly the same. We (the people) paid again.

Then again, for state-owned company No. 3, we did the same EA, and we (because funds from the budget) were robbed again.



Do we need "such IP"? If for the same (same EA) we pay our own money, budget, which is from our own pocket?

Thus, not only people are robbed, but they also wind up the GDP: supplying “the same” and taking “development” (read reuse) in full “as it should be” and “improving” the statistics (completed volumes).



I’m talking about unification, replication, publicity (transparency, publishing not only the fact of purchase, but also the result), reuse (borrowing), efficient use of previously paid budgetary funds (including mine), optimization of PEOPLE'S investments.



Fourth. For commercial companies, the government (state) may announce a competition for a more “correct EA”, in parallel creating a “common EA repository”. Or “make it easier”, as well as for state-owned companies to oblige by law (as in the “Third”): I passed an accounting report, attach my own EA.



A good example of popularization of open discussion of examples of EA is an analogue of the nationwide competition “BPM - project of the year”: bpmaward.ru

What is the national competition “EA - project of the year”, worse “BPM - project of the year”? Or maybe it’s all the same?



The fifth. Reading these lines "happy to have a fresh EA" may think: the consultants did to my enterprise EA, it would be good to check: is this exactly EA? Have they done a good job? I did not overpay?



Rejecting the prejudices about the “competitive advantages of non-EA publications”, such an EA holder will decide to publish a description of this EA with a question: is it a general EA? What mistakes made in its preparation? How much should such a project cost (red price for the project)?



I would not be surprised that after the publication of the “cool EA”, naturally, for the “astronomical price” someone will exclaim, bravo: this is “Malevich's Square, only a special“ connoisseur ”can see in this daub the outlines of architecture, and even enterprises”.



The sixth. It would be nice if simple rules were established for books about EA, descriptions of new methodologies and frameworks: the presence of a complex example of at least a small enterprise.

Remember, there was a book: Jordain R. - Programmer's Reference. It was first said “what to do,” and then three solutions are shown in detail: at the top level (BASIC), medium and low. I would like to find something similar for EA: an example of one enterprise in the implementation of several methodologies / frameworks EA!

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 be mistaken). Why make porridge? Because the descriptions will be "who is in the forest, who is for firewood," because The basis of such descriptions is still alchemy, not engineering.



“Approbation” of approaches is only in the imagination of the architects themselves, after the completion of the next project of EA, pasting the next star on its cardboard framework. There is still no objective confirmation (not met).

I recall that we are talking primarily about the description of the EA, and not the IT architecture, and the “description” means not promotional products (presentations). Although the work of Solution \ System (SA) and Infrastructure (IA) architects, it would also be interesting to contemplate in the public domain (full-format examples, not excerpts).



Architectural porridge of newly-minted architects will either “run away” or even be distributed into “plates” (areas) “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 imposed, the marketing heresy will be dropped, the main question clarified - what will remain on the sheet with the heading "Enterprise Architecture", i.e. “Just an enterprise architecture,” which none other than Enterprise Architect paints.



Any discussion of an 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 (micro-architecture).



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



The EA publications will reveal an important detail: it will be clear in which cases, targeted para-scientific fabrications of the consultants took place in order to “earn extra money on alchemy”, and in which conscientious delusions. The first will be less willing to print their "masterpieces" of EA (and advise their customers not to do this).



Perhaps someday modern approaches to building enterprise architecture will be called “ancient science on enterprise architecture” (alchemy is called “ancient chemistry”), but for now this modern alchemy is experiencing its “golden age”. We were previously warned about this, for example:

"The rush fashion" on architecture "can lead to the fact that the necessary approach for IT will drop a couple of years into the darkness of pseudoscientific articles ." www.osp.ru/os/2006/03/1156580 Deadly

darkness over the EA does not pass for decades and even today there is no clarification:

2 Criticism of Enterprise Architecture

2.1 Criticism of EA from 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 of the initiatives of EA failed. I assume that more than 90% have never led to anything useful ”;

- Erasmus University Rotterdam IDS Scheer: two thirds of the EA projects could not improve the “alignment” of business and IT.



“Business and IT alignment” - some words that were invented. The term was introduced, apparently, to at least somehow “justify” the introduction of expensive IT systems that do not provide adequate (or at least some) return on IT investments: such as the reason is in the ignorance of business, which “lags far behind advanced IT” (i.e. very expensive IT).

The automation itself is “white and fluffy,” but the “dark” business did not understand their “deep intent”, therefore the failures on the EA projects (it is not customary to talk about failures either).



Sometimes EA is used (disguised) - as a “bridge” - as the CIO’s desire to “steer business” or at least stand on the bridge bridge as equals, and not present IT - only as one of the supporting departments of the company;

- Stanley B. Gaver: the federal EA program as a whole has failed.



In favor of the arguments of Gaber, we can say that if something like this (FEA \ FEAF or other EA) really worked and the USA also, as ARPANET would transfer the technology to the world community, then today we would have a new TCP \ IP at the business level i.e. "Business net". Hubs of business, switches, business protocols, absolute standardization, standard “business stack” would appear, and “business routers”, etc., would be sold in electronics stores.

Fragment from wiki already in framework en.wikipedia.org/wiki/Enterprise_architecture_framework

• A historical analysis of EA's publications shows that the “EA frameworks” are “nothing more than typical managerial quirks aggressively promoted by consulting companies and gurus”.
• About managerial fads: en.wikipedia.org/wiki/Management_fad
• , «EA frameworks» .
• , : «EA frameworks» — «, ».
• , «EA frameworks» , . «EA frameworks» — — (, , ), 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. Distinguishing where BPM ends and EA starts is very difficult. Therefore, their myths are identical, alchemy is the same.



Law 1



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



Law 7



A properly made BPM is 50% Enterprise Architecture (EA).



Apparently true and vice versa: Properly done by 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 the organizational structure, without inputs and outputs of processes?



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



Especially difficult to understand are found in one place: Management "enterprise architecture" and business process management (BPM) enterprises. Type "architecture management" and "process management", with the "data architecture" and other "sub - architectures" can be arbitrarily packaged simultaneously in both of these containers.



Law 8



BPM (EA) problems arise from 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. I wonder what then?



The most accurate conclusion is given in Law 14:

Corollary 1 BPM (EA) community is a group of alchemists.

He cited only some of the examples (laws), the rest are following the link to A. Samarin's blog.

2.3 Enterprise Architecture is ... DEAD!

Often on unsuccessful projects on BPM and EA it is concluded: 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 "- the words of wisdom in IT. Thus, a hint is made that if you did not succeed in the project on our “ingenious” TOGAF and Zakhman tablets and another 50+ similar “Best Practice”, then you do not need to tell about it - that is, Expose yourself and your partner - a fool (vendor, integrator, consultant, customer). Here is such a convenient "proverb". Comfortable, exclusively for alchemists and their victims.



The same author (Jason Bloomberg) states that

, « » () 1987 «IBM Systems Journal», EA ().

… EA EA, .

Is Enterprise Architecture Completely Broken?



“Unfortunately, EA is often synonymous with the practice of documenting one person’s views on the IT of their company,” complains Grishy.

I emphasize: it is in IT, it is in documenting, and it is only the subjectivity of the architect. Such an approach in general was supposed to die initially.



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 - like alchemy” - should have come to an end long ago, but today it is a very good business segment, where the main thing is not the result (where is it?), But “the process itself” (the classical BPM slogan). IT Wizards with the tag "EA-consulting", learned from virtually nothing to mine gold: a highly profitable consulting business EA. Classical alchemists to such a "skill" was far away.



Therefore, the article uses negative color for such consulting: most often, professional architects know (suspect) about the pseudoscience of the approaches used, but, like magicians, “do their job” and keep the statistics of unsuccessfulness and the tricks themselves: non-classical frameworks (they are published), how much is the art of manipulating them and the mind of the customer.



Consequently, one more definition can be given: EA is basically a modern approach to alchemy, sanctioning and methodically guaranteeing income from virtually nothing, using old and modernized EA & BPM spells, a magical framework (of the last century and very fresh) Abstract wording, such as:



“ The enterprise architecture sets the way for the organization to achieve its 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): reengineering business processes and optimizing costs, reducing costs and risks, now these are “enhanced spells”: an adequate response to changing market challenges, implementing a business strategy through digital transformation, digitalization of business and enterprise, leveling 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 frank and "pounding" criticism of EA:

“ ... all 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,” scientifically 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 Zachman, the “father” of EA, who previously promoted the erroneous BSP methodology during his previous 26-year marketing career at IBM, recently acquired the Institute of Federal Corporate Architecture Certification (FEAC) and is now actively selling certificates and training in the FEAF, EA framework which is largely responsible for the billion dollars spent by taxpayers invested in the FEA program.



The members of the FEAC Institute continue to promote certification programs in the same EA structures that represent erroneous “best practices”. The insanity here is that the EA community of experts still does not recognize the EA frameworks as another management fad, and many EA experts still want to get certified on some of these EA frameworks.



The fact that counselors have been able to sell the same worst practices, called “best practices” for several decades, even when reliable information is publicly available, clearly demonstrates the unlimited power of endless marketing promises and complete weakness of common sense based on evidence. This situation vividly illustrates another notorious statement: “a lie told a thousand times becomes the truth.”



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



Management fad - a management concept that has a beautiful name and offers a new way to improve efficiency; It is usually developed by a management theorist or consulting company, then becomes popular among a wide circle of theorists and management practitioners, and causes a large amount of research, publications, seminars, etc.,

after which its popularity gradually decreases, and it gives way to new fashionable concepts; Since the creation of a successful popular concept is a very profitable business for consultants and theorists, the latter pay special attention to its effective formulation and promotion, sometimes while 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 has to say that “the king is naked.”

Praising the transparent “dress of the king” and worshiping alchemy is an even easier and convenient way for many. To build something new, you need to "clear the place", expose the myths of previous approaches.



The “poor” Togaf also got from Svyatoslav:

The critical scrutiny of TOGAF

Excerpts:

" ... I want to note that TOGAF appeared in 1995, and its main elements, such as ADM, have remained almost unchanged since. 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 as unsuccessful, because EA projects required a huge investment of time and money, as a result, the architecture was often outdated before the project was completed, and business customers usually could not understand them. If TOGAF is based on TAFIM, and TAFIM has failed, how can TOGAF be based on best practice?



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



For example, there are currently more than 52,000 TOGAF certified people worldwide. This means that the Open Group has earned at least $ 23 million only on TOGAF certificates.

If you add various trainings, courses, books, conferences, consultations and other profitable TOGAF services provided by The Open Group, this number is likely to be much higher. If you were The Open Group, wouldn't you say that TOGAF represents the best practice?



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



... the situation looks hopeless, since probably none of the influential players in 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 provide an objective analysis of the situation in the EA discipline ... In this atmosphere of ignorance, numerous myths, legends and superstitions related to EA spread very quickly ... academic EA researchers are usually obsessed with producing “scientific” theories instead of answering real practical issues.

The fact that TOGAF is now being taught at a prestigious university clearly demonstrates the surrender of the army of academics to marketing aggressors . "



Right on target. The direction of "Business Informatics" in domestic universities with a specialization in EA actually turned into a manual on alchemy. So, science in the country is in the pen, and here also the alchemists dig in "in the rear."



From Enterprise architecture is not TOGAF

" ... the EA community should take a sober realistic look at the existing EA literature, critically reconsider and rethink its idealistic ideas, which are currently very far from the real EA practice in organizations.

Evidence-based new sources of information about EA are urgently needed as a replacement for mostly useless, but actively promoted, EA frameworks. "



To fans of TOGAF, I propose to take part in the competition for the description of the “household architecture” (third paragraph of this article)

2.5 Soft criticism

The Internet has long and a lot of “soft” criticism (see Google) of modern and not at all modern approaches to EA, only the “boiling point” has not yet arrived, possibly because “very many were in the share / share”.



Much of what has been said above is repeated in the blogs of Western critics, although in softer 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 the Western experience, in Russia most of the EA projects are successful (surprisingly to all of us and the envy of the bourgeoisie) or about the level of maturity of the national education in EA. I bow to the second option.



If we are not talking about alchemy, then the principle should be adopted: "the existence of only our thinking self is unquestionable, but the existence of everything else should be questioned."

3 Competition for the description of "household architecture"

I propose to beginner and venerable architects of any EA-denominations to compile a description of the architecture of their household: “household architecture”. This will be the best confirmation that the “Enterprise architecture” in their understanding has the right to exist.



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



The conditions of participation are simple: architects show their “household architecture” in detail, tell how they built it and give references to the framework used. However, one can cite any other “simple architecture” of a “simple enterprise”: kindergarten, ice cream kiosk, etc.



It will be even better if:

A) architects will bring several architectures of NA, pointing out their architectural differences;

B) the description of the same ON will be shown on different approaches, description methodologies, frameworks.



Links to the descriptions of AT give in the comments to this or the next chapter (article). In her, in turn, will publish his vision of ON. Voting will determine the most "correct", the most "architectural" architecture of the household. Notify familiar architects (including EA, SA, IA and other xA), give them the opportunity to make a feasible contribution to the development of EA \ HA.Month for us - architects enough for this? The task is not arch-complex.



So, writers of articles about EA, especially living on habre, - send your ON \ . It is not necessary to be modest: think, draw, “architecture”. Why talk about complex EA, let's talk about a simple ON.

'Non-alchemysts' aller länder, vereinigt euch!



Imagine how annoying many alchemists will be when:

• it will be shown in plain language what is EA and is confirmed by concrete examples in clear manuals;
• the understanding will come that mere mortals can create a description of the architecture without the help of the magic of the alchemists;
• it turns out that in most cases you don’t need to reinvent the wheel at all, but only need to borrow a standard (typical) architecture. Or maybe even the entire design solution that meets the desired architecture.

Your, bipiem