Jason Bloomberg once asked in a blog: "Why is no one doing Enterprise Architecture?" He said:
The solution architect should complete the architectural design of the solution before implementing the solution. Java architects and .NET architects should do things before programmers. You can't implement the architecture and then design the architecture, you can only design and then implement... However, enterprise architecture (Enterprise Architecture) often starts with the existing enterprise... Today's role of the enterprise architect is mainly to face the current enterprise and fix the problems. . Well, maybe not all of it, but it needs to be improved to some extent. Reverse the enterprise architecture from its current "bad" state to a "perfect" state where things get better.
Bloomberg argues that while solving existing enterprise problems is important and noble, it is not the job of enterprise architecture:
Architecture is not about solving problems, but establishing a set of best practices for design activities.
So, in his view, no one is really doing enterprise architecture. Businesses are growing,
Every entrepreneur knows this basic truth. When a business first sits down to develop a plan for a new business venture, if the organization is large enough to be called an enterprise, they may never dare to fully architect it because there are so many unknown stuff. Instead, they like to build an ever-growing framework. Sow seeds, water, weed and fertilize them. If you're lucky, go down this path and you might reap a nice, healthy, and growing enterprise architecture. But the final architecture may look far from what was originally envisioned.
Bloomberg went on to say that this is very different from the concept of Enterprise Architecture, which defines and establishes a set of best practices through which to achieve the desired end goal of the enterprise. The issue is:
Growing a business...means that it, like the growth of any living organism, has no definite end state. It's certain that an acorn will eventually grow into an oak tree, but it's really impossible to plan what the oak tree will look like. On the contrary, the DNA of the acorn determines the basic attribute of the oak tree, but other things depend on the changes of the day after tomorrow. Such changes characterize complex systems: systems have varying properties that, taken together, are different from those of any part. Just as the organism of the biological world depends on change, the development of the enterprise also depends on it.
Bloomberg argues that there is no point in changing the goals of enterprise architecture, instead introducing some new principles:
Perhaps, it's time to identify best practices for architectural changes. After all, if we can architect traditional systems, why can't we do complex systems? ...can we ever find a way to actually do enterprise architecture? After all, enterprise architecture requires a complex, systems approach. In the end, it's up to you to see if you can do that with Enterprise Architecture.
In a comment to this post, JP Morgenthal said that the problem is not with the principles of enterprise architecture, but with the word Enterprise Architecture itself:
...the term enterprise architecture might be better if it was replaced by multi-dimension architecture. The latter better captures the essence of the activity and doesn't confine it to a specific scope - the scope depends on the size of the task. I have always believed that business and multi-dimensional architecture remain closely linked. People design solutions that include business processes, workflows, applications, user experience, network connectivity, disaster recovery/recovery, and more; but what else is there when thinking about the impact any one part of a system might have on other parts? To me, that's where the poor term Enterprise Architecture was originally coined.
We can comment on whether the term enterprise architecture is good or bad, but changing it now when people have accepted the term is clearly not a good suggestion. The result can only be more confusion and controversy. According to IEEE Standard 1471-2000 for the description of software-intensive system architectures, the IEEE recommends:
Architecture is the basic organization of a system, its internal components, the relationships between components, its relationship to the external environment, and the principles that guide its design and development.
This definition says nothing about the final state - it is concerned with the principles by which people improve and develop the system, which is very close to the definition proposed by Bloomberg and Morgenthal. However, according to this definition, the careful tinkering and improvement of an enterprise in order to conform to the appropriate architectural principles is architecture .