Why Nobody is Doing Enterprise Architecture

I’m sure it comes as no surprise that I belong to a number of enterprise architecture-related forums and discussion groups. Sometimes, however, I wonder if it’s worth the trouble. After a while, the babble coming from these groups begins to repeat itself, devolving into argument after argument on what enterprise architecture really is.

In our Licensed ZapThink Architect (LZA) course, we love to point out that the collective term for architect is an argument. As in a flock of seagulls, a pride of lions, or an argument of architects. Put enough architects together in a room, and sure enough, an argument ensues. Furthermore, architects love nothing more than to argue about the definitions of terms—since after all, definitions are simply a matter of convention. Bring up the question as to what “enterprise architecture” means, well, you might as well go home. No more work will be done today!

It doesn’t help matters that many techies have co-opted the term enterprise architecture to mean some kind of technology-centric architecture or other. Look up enterprise architect on a job board and chances are, four out of five positions that call themselves “enterprise architect” are entirely technology-focused. In spite of this confusion, if there’s one thing enterprise architects can agree on, it’s that enterprise architecture is not about technology. Sure, every enterprise these days has plenty of technology, but there’s more to the enterprise than its IT systems.

Unfortunately, there’s little else enterprise architects agree on. Some of them point to ontologies like the Zachman Framework, in the belief that if we could only define our terms well enough, we’d have an architecture. Others point to methodologies like TOGAF’s Architecture Development Method (ADM), figuring that if we follow the general best practice advice in the ADM, then at least we can call ourselves enterprise architects.

Hence, an argument of architects. If you’re an architect, you probably already disagree with something I’ve written. See? What did I tell you?

The problem is, neither Zachman nor TOGAF—or any other approach on the market, for that matter—is truly enterprise architecture. Why? Because nobody is doing enterprise architecture.

The truth of this bold statement is quite obvious when you think about it. Where does enterprise architecture take place today? In enterprises, of course. That is, existing enterprises. And you don’t architect things that already exist. Architecture comes before you build something!

Can you imagine hiring an architect after building a bridge or a building? I can hear that conversation now: “we built this bridge organically over time, and it has serious issues. So please architect it for us now.” Sorry, too late!

Most forms of technical architecture don’t fall into this trap. 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. Even if you take an Agile, iterative approach, none of your iterations have build before design in them.

Enterprise architecture, on the other hand, always begins with an existing enterprise. And after working with hundreds of existing enterprises around the world, both private and public sector, I can attest to the fact that every single one of them is completely screwed up. You may think that your company or government organization has a monopoly on internal politics, empire building, irrational decision making, and incompetence, but I can assure you, you’re not alone.

Enter the enterprise architect. 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.

If you’re able to improve your enterprise, that’s wonderful. You’re providing real value to your organization. But you’re not doing architecture. Architecture isn’t about fixing things, it’s about establishing a best practice approach to designing things.

OK, so if nobody is doing enterprise architecture, then who actually architects enterprises, and what are they actually doing?

The answer: nobody. Enterprises aren’t architected at all. They are grown.

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.

Does that mean there are no best practices for growing and nurturing a startup through all the twists and turns as it reaches the heights of enterprise-hood? Absolutely not. But most people don’t consider such best practices to fall into the category of architecture.

If you’ve been following ZapThink, you can probably guess what the difference is. “Traditional” enterprise architecture—that is, take your massively screwed organization and establish a best practice approach for improving it—follows a traditional systems approach: here’s the desired final state, so take certain actions to achieve that final state.

Growing a business, however, 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.

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? As a matter of fact, we do just that in our LZA course. 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. Have an opinion on the matter? Let the arguments begin!

You are making some excellent points about complex systems and 'growing' vs. 'archtitecting' the enterprise. I would argue, however, that no human system is either all complex or all 'simple': it's always a mixture of both. Which means, in my experience, that there a bits you do architect, and bits you shouldn't. The art lies in knowing what to structure and design, and what to leave open for emergence and growth.

If a system is comprised of complex elements and simple elements, then it is by definition a complex system. There's no such concept as a partially-complex system. As such, a complex system needs to be designed using complex system approaches, even if it comprises in part non-complex elements.

Absolutely true. But the non-complex elements require a different approach than the complex system they are part of, and you need to be able to recognize the nature of the system or sub-system you are dealing with to choose the right approach.

For instance: in nature self-organization is seems to be the only organizing principle, and all behavior we witness is emergent behavior. In human systems, we have 'directed' behavior as well as emergent behavior. 'Directed' behavior is when we consciously influence (either by force or by persuasion) other people's behavior. The balance is a delicate one: we have come to realize that human organizations can never be completely controlled or directed - that level of control is a dangerous delusion leading to all sorts of badness. But we can also not leave things purely to emergence. Even if we want to, that's not how humans interact: we make conscious as well as unconscious decisions, we influence, direct, respond; we formalize, organize, and structure things.

Without writing a book about it, what I'm trying to point out is that in human systems (such as organizations) you need to be aware of what is makeable and what is not - and choose your approach carefully.

By the way: isn't there an inherent paradox in your statement "a complex system needs to be designed"? Do you design it, or seed it and watch it grow?

Thanks very much for this article! Regarding complex systems (like human beings) and the structure of them: Do you happen to know the Viable System Model by Stafford Beer. It proposes an invariant structure for all complex systems. Not an easy one, but a brilliant one!

My Goodness!. Here we go. One more jargon to learn - Complex Systems. Pls let us not complicate!.

Well, am not going to argue what EA is and what it is not. One can find enough discussions in linkedin forums. :-)

Trust me, Business or even Senior IT leadership doesn't really care what we call it - be it systems thinking or complex systems or emergent systems, etc. What really matters is - What is the value EA can solve?. If EA cannot help solving any hard-pressing business issues, its useless!. Period!. How much ever beautiful theory lies behind those concepts.

Why nobody is doing EA?

1. EA has its roots in technical / engineering practice. And its being sold to Management community. Management community or MBAs dont study EA and its usefulness in their curriculum or in the industry by word of mouth. So, the entry barrier is huge for selling EA to top management.

2. As I mentioned in one of your previous blog posts, let's start using EA as a 'process' for guiding the strategy execution. Any enterprise in the world will use some process or the other in executing their strategic plans. Instead, if they use EA as the process, how would it be different?. Can they achieve more benefits?. Am not trivializing, its like using a SWOT framework for analysing a company's strengths and weaknesses. If we can't position as a process, trust me, we can't take it any further in the enterprise.

Overall a great analysis. However, most enterprise architects would hold that city planning is a much better metaphor for enterprise architecture than the design of a single building. One characteristic of city planning is that it's always a redesign of something already existing.

Regarding TOGAF, I see TOGAF 8 having the problem you mention in that it seems to view a very comprehensive target state for the overall enterprise. In TOGAF 9 there is a capability-driven approach, which divides the total architecture into segments and further into capabilities. I feel this lends itself to a much more organic look at the overall enterprise.

The reason a system, even a complex one, already exists is no reason not to apply architecture to its growth path. And after all, I do think we can agree that an enterprise can be seen as a complex system.

Let me explain this by telling about my own experience. Somewhere around 1995, I started working on an SMSC (Short Message Service Center). The first assignment was to test its functionalities to get to known the system. Along the path of developer, I grew into the function where I was one of the three architects of the SMSC.

At that time, the SMSC was already a fairly complex system with a rich set of functions. However, with the growth of the market, the demands of our customers also grew. They wanted new functionality to be added to the system. One of the main responsibilities of the architects was to ensure that a new function would be designed in such a way it fitted in with the already existing fuctions and at the same time would be flexible enough to enable future developments.

I agree that, although complex, an SMSC is not as complex as an entire enterprise might be. On the other hand, I strongly believe that there are definitely certain architecture principles which can help an enterprise grow.

And, as stated in an earlier comment, it is the skill of a good Enterprise Architect which can make a difference...

I disagree with you. First if you transform an old house and you want to break walls you'd better talk to an architect.

Second, I design everyday AS-IS and TO-BE architectures. Even if those are ICT architectures, they are a piece of the entreprise architecture because hopefully our new developements will positively impact the entreprise business model and processes.

Third, an Entreprise Architect doesn't exist because one doesn't want that someone has a complete business overview that would make power games much more complex to play.

Ict and hr departments are obliged to have some view of the current entreprise architecture because they need to deliver services everywhere. Hr knows the organigram, ict knows most of locatiobs

Finally, an entreprise architect is difficult to find because he or she should be in state of understanding most of the critical business processes which is a lot for one man.

But it's not because it's hard to find that it doesn't exist.

I'm starting a businesss now and I'm an architect, so I hope I can play the role of Entreprise Architect of myvown business as long as possible. Call me in 2020 and I can showcase that Entreprise Architecture exists.

I'll throw another log on the fire and suggest that we don't 'architect' the enterprise: our job is to understand the nature or 'architecture' of the enterprise that our organisation works within, and then design as required around that architecture.

We don't don't design that architecture: it already exists. It always does. But we can adapt to fit in well (or not, of course) with how it works, what its drivers are, and so on.

Hence it's kind of the opposite way round to what you suggest. Yes, the enterprise has been 'architected', in a sense - but that wasn't the work of an enterprise-architect. Instead, we work for organisations to help them find the best ways to work with that architecture.

The point here is that 'organisation' and enterprise' are radically different. The organisation determines the 'How' of the work; the enterprise defines the 'Why'. An organisation is usually some form of legal structure, bounded by rules, roles and responsibilities; an enterprise is much more about feelings, bounded by vision, values and commitments. There are a few contexts in which the two sets of boundaries can coincide, but in most EA contexts the enterprise in scope is about three steps larger than the organisation - i.e. organisation plus supply-web plus market plus social-context.

Once we properly grasp that difference between organisation and enterprise, a lot of enterprise-architecture suddenly starts to make sense. Until then, as you suggest, it often doesn't. :-)

Thank you for tackling this subject. I'm increasingly frustrated with those who talk of Enterprise Architecture, or any other kind of Architecture, and yet the meaning they give to the term 'Architecture' is just so completely removed from its origins as to lead to profound confusion in the 'Enterprise'. However, there is one area where I'd disagree with your article as some others have commented above. Just as an architect may be consulting when planning major renovations to a building, then in the same manner an enterprise can be 'architected' to correct flaws or make changes.

Jason Bloomberg’s article “Why Nobody is Doing Enterprise Architecture” is a “the emperor has no clothes” glimpse of truth. His reference to complex systems thinking is spot on. Perhaps it would help us to think of enterprises as “holons”.

As Ervin Laszlo points out in his book “Introduction to Systems Philosophy: Toward a New Paradigm of Contemporary Thought”, the term “holon” was coined by Arthur Koestler and its etymology comes from the Greek word holos, which mean “whole” with the ending “on” which implies a particle or part (think of “neuron” or “proton”).

As the story goes, the concept of holons came from a parable about two watchmakers.

There once were two watchmakers, named Hora and Tempus, who made very fine watches. The phones in their workshops rang frequently; new customers were constantly calling them. However, Hora prospered while Tempus became poorer and poorer. In the end, Tempus lost his shop. What was the reason behind this?

The watches consisted of about 1000 parts each. The watches that Tempus made were designed such that, when he had to put down a partly assembled watch (for instance, to answer the phone), it immediately fell into pieces and had to be reassembled from the basic elements.

Hora had designed his watches so that he could put together subassemblies of about ten components each. Ten of these subassemblies could be put together to make a larger sub- assembly. Finally, ten of the larger subassemblies constituted the whole watch. Each subassembly could be put down without falling apart.

As Laszlo states, Koestler made two observations:

The first observation, coming from the parable of the two watchmakers, was “that complex systems will evolve from simple systems much more rapidly if there are stable intermediate forms than if there are not; the resulting complex systems in the former case will be hierarchic.”

The second observation, made “while analyzing hierarchies and stable intermediate forms in living organisms and social organization, is that, although it is easy to identify sub-wholes or parts, wholes' and 'parts' in an absolute sense do not exist anywhere. This made Koestler propose the word holon to describe the hybrid nature of sub-wholes/parts in real-life systems; holons simultaneously are self-contained wholes to their subordinated parts, and dependent parts when seen from the inverse direction. “

Holons (think SOA here) are “ autonomous, self-reliant units, which have a degree of independence and handle contingencies without asking higher authorities for instructions. Simultaneously, holons are subject to control from (multiple) higher authorities. The first property ensures that holons are stable forms, which survive disturbances. The latter property signifies that they are intermediate forms, which provide the proper functionality for the bigger whole.”

Perhaps our analogy frame of reference should shift from “architect” to “holonist” – one who is able to understand, design and implement the macro level interactions of complex components required of an enterprise’s business strategy (the higher authority as it were), the intermediate level interactions/interplay of a component (technology, process, people, material, etc.) and the micro level interactions of a component’s elements . Anyone for “Service Oriented Holonogy?”

"Enter the enterprise architect. 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.

If you’re able to improve your enterprise, that’s wonderful. You’re providing real value to your organization. But you’re not doing architecture. Architecture isn’t about fixing things, it’s about establishing a best practice approach to designing things."

Nowhere does the article admonish not to do architecture. It admonishes what people are saying they are doing is architecture, when in reality, they are not doing it at all. And most organizations do little, if any architecture - they just fix stuff and forget about planning and designing altogether. They just let the mold grow.

See my comment on the above reply. I think you missed the same part of this article. Nowhere does it say not to do architecture. The point is that no one is really doing it. Quote the article in your response where you disagree.

It depends on how you look at "Enterprise Architecture" and the "Enterprise Architect".

A start-up business does not just go and buy stuff to do something random. A business case is more often than not conceived to secure funding and justification is required to demonstrate the viability of a proposed organisation's ability to perform the business function and to support that function.

Part of these considerations includes "architecting" the greenfields environment. This is "Enterprise Architecture", i.e. realising business objectives through technology. Whether the job title of the person making these decisions is "Enterprise Architect" or not is irrelevant, the "role" of Enterprie Architect is still being peformed.

Enterprise Architecture, like Construction Architecture, or any other architecture is based on prior learnings from the related industry, regardless of what your opinion is around its definition. Things may seem to grow organically, but what you find is that people just aren't formally recognising the roles.

If a builder makes a decision to change a structure and just goes ahead and builds it, then they're Architecting, Engineering and Building all at the same time. If the structure collapses, it's the person who filled the role that takes responsibility. Builders beware ... talk to an Architect, or Engineer :-).

My five cents. From Jason's point of view seems almost impossible to have a stable end-state in order to pinpoint our works. For sure, Business is always moving but I think we have to at least have a complete vision about the web of relations between the parts shaped the Business. This means we'll be able to look at the whole so we can keep it in balance. That doesn't mean plaster our Business on our "architecture works" but it means ensuring a business long life avoiding unforgivable choices.

As far as I can see, there isnt' a magic enterprise software able to do that. It needs of skillful Architect's minds. Is it that Enterprise Architecture? I don't know, it's not up to me. I belive that it's time to care of Architecture ilities!

I think this discussion is spot-on. What's the added value of EA in organizations, and what's the reponsibility of the EA?

From my experiences and from observing the dwellings of EA's in organizations, my current view on this is as follows: - Changes in large organizations have the characteristics of so-called wicked problems (Rittel and Weber, 1973). Stated popularly, many entities, influencing each other back and forth. The only sensible approach found so far to deal with these types of problems is creating a multi-disciplinary common view of the 'battlefield' and, - using this view to collaborately identify the steps to make the change (e.g. by identifying any risks involved and finding ways to avoid these risks)

I believe EA could be, and sometimes is the discipline that is responsible for creating the common view mentioned above and for identifying the steps to make the change. For that he/she has a set of tools, techniques and (social) skills available.

Looking forward to any comments on this, as the application of EA in organizations is a wicked problem in itself ;-).

If EA is positioned as panacea for all change management initiatives, let us face the fact that most of the issues in change management are organizational/political or social. It is hardly technical or architectural. But clearly, there is a need for orchestrating and navigating that change process successfully. And thats where EA has a place. It could help in creating a common view across various kinds of stakeholders. After all, creating views is a basic skill of an architect!

Good points. However, I would argue that if an designing from “nothing” as mentioned in the article, only qualifies one as being an architect, then using that logic, those that design buildings and bridges cannot be considered architects either, simply because there are already existing buildings and bridges that indirectly or even directly influence the designs when an architect is “designing” a building or bridge. For example, there are basic requirements that go into building a structure. The architect is required to know those basic requirements (A foundation, roofing, plumbing, HVAC, structural integrity, etc), which are almost always pre-existing. So in short, the article’s argument that an architect designs a building from “nothing”, is not entirely true, as an enterprise architect, like a building architect, creates based on pre-existing standards, ideas, designs, and processes. The same logic can be applied to an engineering and design team that builds a car. The basic design of a car (wheels, a power source, etc) is standard, and has not changed for over a hundred years. The appearance, and technology has changed/evolved, but the basic concept of an automobile has not really changed. And even over a hundred years ago, the basic design of a car can be traced to the even older carriage, to the point where early automobiles were called “horseless carriages”. Just like a building, car, bridge, or an enterprise architecture, no one truly designs these things from “nothing”. A decent enterprise architecture should not only be a decent improvement of current processes and functions, but it should be forward thinking enough to influence or at least facilitate future developments, functions, and processes. This goes beyond being simply a facilitator of already existing standards and processes.

Enterprise architects are more like politicians who are busy with influencing the decision-making than architects who are focused on creating things. That is why enterprise architects rather like to communicate with CxO's and hardly ever communicate (as in not just tell somebody how to do his work but also listen to somebody) with the real builders.

Actually, I listen mainly to the subject matter experts and engineers with often abstract guidance from higher management. These SME's and engineers often drive the architectures, not management. So it is not in my best interest to ignore the "builders" Most of my job IS listening, not influencing. So, that is a false statement that architects only communicate with management and not the "real builders". Maybe at your company... As for "creating", so you are telling me that an architect who designed a building "created" the building using no precedence? Find me a single building designed in the 20th century and beyond that was not built using already pre-existing standards and processes. Good luck with that.

My earlier point is correct, very few people really "create" anything anymore from nothing, including building architects and most engineers.

The Guggenheim Museum in Bilbao was designed and built using new technologies and processes and did set new standards (now called BIM and IPD) for the real architecture profession. The Sydney Opera House is another example.

Theo Jansen's STRANDBEEST is a nice non-architectural example.

But I really don't understand your point about "very few people really “create” anything anymore from nothing" because I never stated that real architects create things from nothing which would be impossible anyway. I said that real architects must design that are or should be 100% makeable. I made that statement because real architects do have a professional liability. If you want to have the same status as real architects you should at least take the same professional liability risks.

"If EA cannot help solving any hard-pressing business issues, its useless!. Period!. How much ever beautiful theory lies behind those concepts."

I agree in part to this, but I think it's important to keep in mind that the job of an enterprise architect is also about preventing/foreseing problems before they become business issues! This is at least as importans as creating direct value from solving existing issues.

Some of us have decided to stop wasting our energy trying to describe what enterprise architecture is and how it would benefit an organization if the organization adopted it. That smacks of asking for permission to do our jobs. Instead, we actively demonstrate it through direct application. Enterprise Architecture is very easy to understand when you see it in action.

So for disagreement's sake, I will simply observe that those who argue are not doing Enterprise Architecture. Those who are doing it are quiet because they're pretty busy applying it.

Hey, I agree with everything you said – well, until the paragraph that begins with “The truth of this bold statement is …” By the way, Architecture has been defined for us technical and not-so-technical people.

Definition of Architecture vis-à-vis IEEE 1471 standard. 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. Wikipedia entry @ http://en.wikipedia.org/wiki/IEEE_1471 summarizes very nicely the purpose of the IEEE 1471 standard; an architectural description, which is what an architect really “architects.”

The purpose of an architecture description: According to IEEE 1471 an architecture description can be used for the following: ▪ Expression of the system and its evolution ▪ Communication among the system stakeholders ▪ Evaluation and comparison of architectures in a consistent manner ▪ Planning, managing, and executing the activities of system development ▪ Expression of the persistent characteristics and supporting principles of a system to guide acceptable change ▪ Verification of a system implementation’s compliance with an architectural description ▪ Recording contributions to the body of knowledge of software-intensive systems architecture

While IEEE’s principle concern here is clearly related to software, it does not require a giant leap to conclude that the meaning of system does, and should, extend to an organization of systems and even to an enterprise or, in today’s environment to cross enterprise systems. Note that nowhere in architecture does the requirement for a system to be new in order to have or to create an architectural description. In fact, if you don’t have a description for a complex system or organization that needs to be better understood, you better do one before you start to tear down the walls – or you may find yourself tearing into pipes or electrical conduit!

To say “… you don’t architect things that already exist” is just not correct.

In fact, the technical architectures, which you suggest are done from scratch, are rarely (if ever) done tabula rasa; and are much improved by first understanding and clearly defining the current state. And yes, even a non-existing system has a state to document, namely: Purpose, principles, governance framework, etc. Nor, would any architect suggest such nonsense as defining a “Final State” architecture any more than anyone would describe a system as having a final state.

Yes, I would hire an architect to redesign an existing bridge that was going to undergo a significant change; e.g. replacing a wooden bridge with a suspension bridge with 6 lanes of heavy traffic.

How can any executive officer effectively ‘steer’ their organization (government or large corporation) through today’s chaotic business and technical environments without an intimate knowledge of the enterprise and the component inputs, activities, products and objectives?

You suggest emerging. That is what happens today. Typically, in response to change drivers, the emerging enterprise will “REORGANIZE!” Merge, Spin-off, create new agencies, hire/fire managers. Whether unit, office, bureau, agency, or enterprise: they cycle and recycle through the reorganizing mantra of: split, combine, outsource, insource, and– every ten years or so they do it all over again. And all with the same justification: “to gain efficiencies, make cost savings and to better serve our customers.”

What they really mean is: we don’t know what buttons to push to get the changes we need. They don’t know the architecture of the structure they’re trying to change; and they don’t have an architectural blueprint that shows the capabilities of their various units and what these components are doing to improve their own effectiveness and agility.

The structure of an enterprise is not even as visible as the structure of a building whose walls hide many things. The enterprise has a soft structure; built of processes, policies, standards, principles, strategic objectives, assets that need to be managed to cohere with both the needs of other strategic activities and other plans, and of course a governance framework.

An existing enterprise has an architecture, it just isn’t well described. And it needs to be in today’s environment. Please rethink. It is not logical to say you need to architect an application, but not the system to which it belongs or the domain in which it operates.

The initial architect of the Empire State Building asked his client what he wanted to build. The client picked-up a pencil, stood it on the eraser and said that’s what I want. (that’s the agile part). The real architecture, is in the months of architecting and reuse of previous architectural designs, principles, governance framework and consistent use of standardization that allowed this empire state building to be built in 16 months – in the middle of NYC.

Yes, enterprises are grown. If they are allowed to “emerge” they will go feral, and instead of a well tended garden, you will have weeds and no tomatoes. Our enterprises are like weeds.

I do believe that you are very correct in asserting that Enterprise Architecture is not being done, and that it is certainly being confused with ‘Enterprise-wide’ services, inventory, standards and infrastructures.

However, your description of a start-up is not really very well described. First, most (by a long-shot) fail! The ones that don’t, usually have managed to squeak through by the skin of their teeth. The successful startup will have (as you said) a business plan. This is the first version of the Enterprise Architecture. Governance Framework, Stakeholders, target consumers, Resource management, objectives, Strategic Plans, Key Measurement indicators, etc.. You know how much effort it is to do this, especially for “idea people.”

Problem is, the growth, change from external sources, regulators, market shifts, competition… if you just throw out seeds without clear objectives and a plan, and see what you get with occasional weeding… you won’t succeed. Maybe if you’re lucky and get too big to (allow to) fail, someone will bail you out – and take over.

The idea of "setting an order which will allow specialists to build a solution" is great if you have the power & knowledge to do so. But every solution will be the start of a whole new set of problems because of the rapid changing world and the increasing interconnectedness of everything. The ability to predict how the world will look in the future is decreasing at the same rate by which the social networks are growing...

I only can hope that your architects will be using some mighty good crystal balls :-) Otherwise they should use complex adaptive system modeling, prototyping and simulation as a good alternative! Because static diagrams, documents and models won't do the trick anymore.

That is why architects in the real (construction/building) world are transforming their work process from static drawings and blueprints to BIM and IPD.

"Architecture isn’t about fixing things, it’s about establishing a best practice approach to designing things.”

I suggest that "... establishing a best practice approach" is a process itself and is separate from the architectural process. The best practice SHOULD be used by the Architects and the results would provide feedback to the best practice process.

Architecture is really about describing things; not about establishing a best practice. -- of course there is "good" architecture and "bad" architecture, which is determined in part by governance and employing best practices, etc..

Sometimes describing things results in an abstract design or model, sometimes it produces detailed implementable designs or blueprints. Sometimes it just describes how things work. The architectural description should have a purpose and viewpoints.

I still believe that the ANSI/IEEE definition of architecture rocks, and works for Enterprise Architecture as well as Victorian Architecture.

"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."

In my opinion, the best quote of this article is ""Enter the enterprise architect. The role of today’s enterprise architect is essentially to take the current enterprise and fix it."

As a management school, we provide programs on Enterprise IT Architect and every participant agress that the market needs more of these profiles. Yet, they are very hard to find!

Perhaps organisations could start thinking in the long term and shape their own architects. There are several advantages of such an approach. For instance, internal employees already know how the organisation operates. They can reflect the course content to their every day work life and business processes. Second, we provide a 2 year (part-time) management program on this topic because it takes al lot of time before one can become a great architect. A so-called T-shape profile understand to broader context of the organisation such as business strategies, strategic alignment, business processes, IT governance and so on, as well as specific and deepening knowledge on enterprise architecture, business process architecture and software architecture. As a researcher I am writing a PhD on IT value management. Strategic and discretionary IT enabled investments will only deliver business value if they are executed by business and IT.

And if one cannot find any framework that focuses on enterprise architecture, I would like to invite you to take a look at DEMO (http://www.demo.nl/). This is a framework build to investigate and orchestrate an enterprise together with its business processes. Interesting presentation and publication are forehand on their website.

If you're interested in the 2 year Executive Master of Enterprise IT Architecture, please visit www.antwerpmanagementschool.be/MITarchitecture

I also totally disagree with this article. Do solutions architects really create something that does not exist, or translate something that exists, like a human process, into an automated one? How many solutions architects have truly created something new? And how many applications reach a nirvana state with the first design? Agile development anyone?

I have witnessed excellent examples of corporations designing systems of people, technology and processes to create something new in the context of the enterprise (can new be defined without context?), without deluding themselves that the work is done or new problems won't "emerge".

By the way, the legal movement is moving hard to avoid jargon, legalese and other obstacles to clear and concise communication.

Perhaps someday our technology writers will focus more on solving problems than inventing new words to describe old ones.

Too bad I didn't read this post when it came out. As an architect - naturally - I must disagree here and there (I don't have to, it's just that you don't think I am not one;) I have posted similar thoughts some time ago as well discussing why I thing there's no architecture in EA (http://ondrejgalik.wordpress.com/2011/05/20/there-aint-no-architecture-in-ea/) and also questioning the famous notion of target architecture (http://ondrejgalik.wordpress.com/2011/05/20/target-architecture-is-a-myth/), you might be on the same page there. I used a slightly different analogy of raising up children.

ea is a toolbox which you bring to resolve issues. use what you must, be glad for that speciality tool you don't use much of because for this project it just happened to come in handy. get the job done and move on to the next job (project, program, business, organization, segment, et al.).

I read it - and I can certainly sympathise. Especially with the collective noun and the endless chest beating over definitions. It's genuinely appalling. (To my mind too many people in the game don't know how to think, or write, or model, or communicate - they know tech - but they don't take the design skill seriously enough to actually go off and learn them.) I am starting to develop a physical aversion to all the roll-your-own frameworks that keep popping up in the blogosphere like mushrooms after a heavy rain.

But the central premise is incorrect - and an argument from analogy. Not good. Analogies are for illustration and explanation - they don't establish anything.

But ironically, as an argument, it's the wrong analogy. And the analogy actually provides a better counter-'argument' to your thesis.

Architects do actually get involved with buildings after they are built. Whenever a large or structurally complex building needs to be remodelled and repurposed they call in an architect.

So that part of the analogy actually supports EA - The enterprise architect (should) understand the structures of the enterprise and be able to design and plan smooth transformations. And all that A2 scale analysis they do - if done right - and I will concede that is too rare - provides the 'structural-engineering' parameters of the organisation within which all restructuring must work.

One EA I met - who certainly was doing EA - was employed by a billion dollar mining and resource company solely to plan the rationalisation of technology and business processes every time they acquired another company. Which occurred several times a year. He had a decent sized team and there was no doubt at all he was providing a necessary skill set within the business, saving them large amounts of money and probably averting quite a few dangerous accidents.

EA provides a crucial skill set for large scale change. That it becomes less relevant as projects become smaller (true), and is not practiced correctly in many places (also true) dose not establish its lack of worth. It is a bit like observing a drunk driver attempting to get to work in a bulldozer (it has happened) and arguing that drivers and indeed bulldozers are a waste of time and money.

That a tool or theory is miss-applied, or poorly applied does not imply the tool or theory has no application, or is unfit. It does prove there are actually idiots using it. Hardly a surprising revelation.

The solutions architecture approach you advocate, has in this state led to over a billion dollars in failed IT projects in the last three years. The auditors finding in a nutshell - nothing translated governance into implementation.

I think it highly unlikely that all the professional technology experts and project managers working on those projects were idiots. More likely their perfectly valid management and design approaches couldn't scale from a twenty million dollar single company approach to four hundred million dollar, three million plus end-user, multi-organisational IT projects. That one four hundred million dollar project came in years late and at around 1.2 billion dollars.

Ancient debate. Enterprise architects don't function like they would as part of a typical architect discipline, rather as part of a planning discipline - a city planner. However true this might be, the reality is the enterprise planning discipline has become known as enterprise architecture after information planning became flawed. We can live with that, can't we? After all, it's just a label.