In his new post Jason Bloomberg is asking a question "Why Nobody is Doing Enterprise Architecture ?" He notes that:
A solution architect architects a solution before that solution is implemented. A Java architect or a .NET architect does their work before the coders do theirs. You don’t build and then design, you design and then build... Enterprise architecture, on the other hand, always begins with an existing enterprise... The role of today’s enterprise architect is essentially to take the current enterprise and fix it. OK, maybe not the whole thing, but to make some kind of improvement to it. Go from today’s sorry state to some future nirvana state where things are better somehow.
According to Bloomberg, although fixing existing enterprises is very important and noble proposition, this is not doing Enterprise Architecture:
Architecture isn’t about fixing things, it’s about establishing a best practice approach to designing things.
So, in his opinion, nobody really architects an enterprise. Enterprises just grow:
Every entrepreneur gets this fundamental point. When entrepreneurs first sit down to hammer out the business plan for a new venture, they would never dare to have the hubris to architect an organization large enough to be considered an enterprise. There are far too many unknowns. Instead, they establish a framework for growth. Plant the seeds. Water them. Do some weeding and fertilizing now and then. With a bit of luck, you’ll have a nice, healthy, growing enterprise on your hands a few years down the road. But chances are, it won’t look much like that original plan.
Bloomberg continues by saying that this is very different from enterprise architecture - defining and establishing a set of best practices in order to achieve a desired final state. The issue is that:
Growing a business... implies that there is no specific final state, just as there is no final state for a growing organism. An acorn knows it’s supposed to turn into an oak tree, but there’s no specific plan for the oak tree it will become. Rather, the DNA in the acorn provide the basic parameters for growth, and the rest is left up to emergence. Such emergence is the defining characteristic of complex systems : systems with emergent properties of the system as a whole that aren’t properties of any part of the system. Just as growth of living organisms requires emergence, so too does the growth of organizations.
Bloomberg considers that it makes sense not to repurpose enterprise architecture, but rather introduce a new discipline:
Perhaps it makes sense to call the establishment of best practices for emergence architecture. After all, if we can architect traditional systems, why can’t we architect complex ones?... If we have any hope of figuring out how to actually architect enterprises, after all, we’ll need to take a complex systems approach to enterprise architecture. It remains to be seen, however, if it’s possible to architect enterprises that way.
Commenting Bloomberg’s post, JP Morgenthal says that it is not the principles of Enterprise Architecture, but rather a terminology that creates a problem:
... perhaps a better name for enterprise architecture might be multi-dimensional architecture. This latter terminology better captures the essence of the activity and doesn’t tie it to a particular scope - it can be as large or as small as it needs to be to accomplish the mission. I believe that businesses engage in multi-dimensional architecture all the time. They design solutions that contain business processes, workflows, applications, user experiences, network connectivity, failover/recovery, etc. What’s more they consider the impact of any one particular aspect of the system on the rest of the system as a whole. To me that is what was designated by the term enterprise architecture when it was first, poorly, coined.
We can argue whether Enterprise Architecture is a good or bad term, but changing it now, when it finally got accepted does not sound as a good idea. It will only lead to more confusion and arguments. According to IEEE Standard 1471-2000, the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems
Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
Nothing in this definition talks about final state - it is about principles that one applies to evolve and grow the system, which comes very close to definitions proposed by both Bloomberg and Morgenthal. Moreover, according to this definition, fixing and evolving an enterprise in order for it to adhere to the proper architectural principles is ARCHITECTURE.