George Colony's Blog:

This blog, written by Forrester CEO George Colony, contains ideas, observations, and analyses to help drive the success of other CEOs. George’s goal is to assist today’s company leaders in forming unique approaches to the challenges they face.George’s bio | George on Twitter

Do you want your strategies to succeed? You'll need the gentleman on the left.

He designs your business. As Dave Baker of PwC notes, "A business without a design is one that is likely to be overly complex, expensive, inefficient and unaligned." Or as Raja Musunuru, from Gaylord Entertainment Company, says, "It's the difference between the roads in Boston and the roads in Toronto."

Who is this designer? He's an obscure executive called an Enterprise Architect (EA) and he works for your CIO. The role has gained traction over the last 10 years -- if he's not in your employ, challenge your CIO to hire him. Because you don't want your strategies following spaghetti roads -- you want them moving through your company on logical, straight highways...

Why does he work for the CIO? Because the roads in your company are paved with technology -- so the best way to ensure that they are straight is to build and control the tech. There are two other reasons:

1) EAs bring agility. You know this cliche: Markets change fast, your business has to keep up. If you've got frozen technology, your company won't pace with your customers. A good EA will design the business and the tech for quick adaptation.

2) EAs know when and when not to use new technology. Story: The insurance company USAA had a big problem. It was a hassle for customers to deposit checks -- it involved paper, stamps, forms, etc. Then came the iPhone. Because USAA's enterprise architects had designed adaptable systems, it could offer Deposit@Mobile -- take a picture of a check with an iPhone, and it's deposited. The company expected 22 million uses of the app in 2011 -- the actual number ended up at 120 million.

Techies invariably screw up the business; business guys screw up the tech. For years (actually, decades) we've looked for someone to span both -- and that's what Enterprise Architects do. David Torre, EA at Sony, sums it up: "An EA is an internal, trusted advisor who marries the best interests of the business with long-term technology strategy." If you're so inclined, check out here how a bunch of EAs describe their job.

Comments

1. While most Enterprise Architects (EA) report into the Office of the CIO, this trend potentially could be misleading to the business-side since in their mind it becomes "just another technology-related activity" which defeats the purpose of having EAs within the organizations anyways. While EAs certainly leverage technology to help the organizations but they also apply best practices in process optimization (which my or may not entail technology) to achieve strategic objectives which takes me the second point...

2. Currently most organizations are interested in "going" to the cloud bandwagon however without cloud adoption feasibility studies which entail process optimization across the organization, the organizations would be doing a disservice to themselves.

I've been navigating my way through the several interconnected mazes surrounding EA for many years, which followed hands-on operations and consulting for many years.

My take is perhaps a bit different due to recent experiences that reveal challenges on both sides of the issue. In one recent case for example, a very strong EA in a large public entity left after a CIO was hired that had a few years of software engineering experience primarily at one large company, and at least from my perspective appeared to have been hired for the wrong reasons-- to adopt that vendor's products, which is substantially located in and around the public entity.

To me this is just another version of corruption in the enterprise rather than the truly very important requirement that this public entity adopt a strategic path that will help the region become more globally competitive, not commoditized, which is clearly the result of the new hire--in this case perhaps justified in part internally by cost containment. The problem with that strategy is that the region has among the highest fixed costs in the world now, so by adopting low cost commodities used worldwide to include competing nations and regions operating at a fraction of the cost, and winning big over fools who attempt to compete on cost; it's simply suicidal strategic thinking.

However, what I've also run into are large numbers of individuals either holding the title of EA or seeking it who have their own serious conflicts, such as creating their own silos and turf at the expense of the strategic interests of the enterprise-- no different than external SIs or the CIO misalignment so often discussed in recent years. So I would caution boards-and have, that an EA alone is not necessarily a solution to their challenges--even good ones, although it can be a good move if the rest of the organization is ready and able to work with a strong EA. The important issue is to farm the IT market in such a way that it can begin to produce a competitive harvest again, meaning a competitive advantage to include those who lack budgets that can compete directly with large SW vendors in custom development-very few.

The ignorance of BoDs surrounding enterprise IT in recent years surely reached a level of exploitation that surpassed all previous contenders as measured by product and service costs alone, but more importantly at cost to competitiveness to the enterprise that is rarely reflected in the P&L even after the results of commoditization erodes the financial condition--usually in my experience management isn't even aware of what sameness of IT has done to their orgs.

Not only are most of their sources seriously conflicted, which is a bit easier to discuss here than most -- not just by services arms of vendors and auditors that turned into software and service distribution channels, but often internally by staff that have far more alignment with SW vendors than employers. After all the average duration of even a CIO is only a few years while enterprise decisions typically impact half the ave life of the corporation, and consultants who perform most of the work in enterprise software today owe their allegiance almost entirely to the software vendor ecosystem that they specialize in-- many don't even consider the orgs paying the bills to be the customer.

While a few fortunate organizations with sufficient market power and/or legal monopolies can well afford commoditization of the enterprise with ever-rising costs, it's clear at the macro level that the majority cannot, especially those in hyper-competitive industries in higher cost locations -- flattened indeed has been the result. So I look at the entire sector as somewhat similar to a large unsustainable bubble-- certainly the trajectory has been.

This is why for many years we've been working @kyield on adaptive computing that can be tailored to the specific needs of each entity free of lock-in and high maintenance costs. As one might imagine with a good view into the enterprise maze, it has not been a trivial task, but I think we have succeeded-- now into the pilot phase.

I'm sorry, but I have to say that this is almost exactly what _not_ to do with enterprise-architecture. Enterprise-architecture literally means 'the architecture of the enterprise': even in the most information-centric of industries, EA _must_ have a broader scope than IT, or even information, and for that reason it _must not_ be placed under the CIO or anywhere that will be perceived as 'an IT role'.

If you _do_ place EA under the CIO, you _will_ guarantee rampant IT-centrism on one side, and almost certain rejection on the other - not useful for anyone.

To answer your question "where do you think the EA should fit in a company", the preferred positioning would be similar to a strategic unit reporting direct to the executive, but otherwise as part of a major-change unit such as a Portfolio Management Office.

And associated blog post. George didn't say that the CIO was the head of IT, as your objection implies. When the CIO becomes the CBTO this all makes sense. Thinking of CIO as Chief Infrastructure Officer is a 2005 idea.

Under the executive (Officer), but should be an autonomous group. IMO the EA core should be formed by a matrix style, and multi-disciplinary team and led by an experienced Enterprise Architect. EA has too much importance to sit on the lap of a single executive.

Forgive my stepping in here. This reminds me of the debate under other acronyms in organizational consulting in the past. While I am sympathetic personally to the great many like the one I cited above who have a CIO that is either corrupt or incompetent for the task at hand-- there have been a great many of those, it's also true that many very strong organizational managers hold the title of CIO. This did not come about easily frankly-- required many years of education that has yet to reach some organizations, in part due to the conflicts in the ecosystem, and there is somewhat of a natural conflict in the manner in which the IT industry has evolved, but it's a mistake for any discipline to make broad statements and/or to focus more on reporting structures than more important issues-- like physics, culture, individual competency and leadership. I've worked with some holding the title CIO that even the strongest EAs would be fortunate to report to.

Tom - thanks for replying. The thing that I think you and Pallab are regrettably missing is that BT is not IT renamed. That's easy to say and hard to do. Almost any firm that retags IT to BT will initially have an IT shop, calling itself BT and still acting like IT. But the that's the beginning of evolution.
Our CIO group has been doing some research on what a BT org might look like, but the fact is that most of our clients have IT/CIOs and we need to keep our feet on the ground helping them with problems they have today. As Gene points out, only a small fraction of firms we survey have EAs reporting outside the business, so opining that should be otherwise provide little practical value as the CEO and the board are not ready for it in most cases.

Brian: "The thing that I think you and Pallab are regrettably missing is that BT is not IT renamed" - sorry, that's not at all what we're missing (though to be blunt, I suspect that in practice that kind of 'rebadging' is all that it will be...)

The thing that I think you and George and Gene are all missing is that _it's not about the technology_: if you start from the technology, or centre it around the technology, you _guarantee_ failure of the EA. Sure, to use Andrew McAfee's phrase about his 'Enterprise 2.0', it's equally true that "it's not not about the technology" - but that's not the same at all.

You're still stuck on the classic term-hijack, pushing one minor technology-oriented subset of possible business-strategy as if it's the whole thing. And that's very, very wrong, and _not_ just in terms of idealised theory - which, I'm well aware, is how a fair few people would prefer to dismiss me on this. Sure, 'silver-bullet'-style technology-centrism is great for technology-vendors, and great for consultants too - but as the long, long history of disastrously-misconceived technology-implementations shows all too well ('business-process reengineering', anyone?), it does _not_ help the end-client. To me there are some really important issues that you-plural just don't seem to be facing here, in terms of very high levels of potential business-damage to your clients, and hence of business-ethics in promoting such a _known_ anti-pattern as 'a good idea'.

To give you some idea of the contrast between our perspectives, one client I worked with recently had a reputation-crash so severe that their own front-line employees had started telling family and friends that, honest, they'd changed jobs and were no longer working for the company any more. The drivers for that crash - and the sources of options to repair it - were in a complex mix of business-strategy, cultural-translation, poor internal communications, some technology-related and other issues from a still-incomplete merger, and a few other less-significant technology and other issues as well. Overall, this was, _literally_, about the architecture of the enterprise; yet a 'classic' so-called 'EA' such as you're still promoting here would have blinkered-off most of the significant issues or the interactions and interdependencies between them, and would have made it all but impossible to make sense of what was actually going on and what to do about it.

That's why I'm so upset about this: I almost don't care when it's myopic idiots on LinkedIn, but all of you are people I know and deeply respect - so what's going on here?

... regarding your question #2, perhaps it's because Forrester's 2011 survey data based on 543 responses from enterprise architects shows that 56% of EA teams report to the CIO or CTO, and another 19% report to a head of planning/strategy/governance that reports to the CIO. That's 75% of EA teams reporting to CIO/CTO or a head of tech planning. Of the rest all but 7% report into other IT directors. So that's a pretty solid connection for 93% of today's EA teams.

Sorry to get all pedantic, countering ideology with boring old data, but what's that Einstein quote? -- “In theory, theory and practice are the same. In practice, they are not.” We're rather fond of metaphors in EA, right? Here's the deal: If you got in your car and drove in a straight line to where ever you want to go, most of the time you'd end up somewhere you didn't want to be. Like in a ditch. We all need to be optimistic and keep our eyes on the prize, which is more business engagement and improved business outcomes. But you can't just wave a magic wand and get there; it's more complicated than that.

Gene, the numbers are interesting. But the point you missed is that typically such surveys are EAs (overly IT-centric already) and are primarily EITAs. In that light, the numbers make perfect sense.

I like your example about taking a car into the ditch - that's precisely where EA is now. It's time to pull back, reflect and move in the right direction. There is no magic wand here - just plain compelling logic. A correction is long overdue. Simply because statistics that show most are in the ditch does not make being in the ditch the right thing.

And finally, as thought leaders we are expected lead (rather than follow) the crowd, not use statistics to propagate the faulty mental model.

You can't really make assumptions about the validity of survey data by just deciding it must be sourced in a skewed fashion if it doesn't produce the results you'd like to see. But rather than get into the nuts and bolts of this particular survey's distribution, let's just talk about leaving the EITA past behind and getting into the real architect-the-enterprise EA that we'd all like to see.

How do we get there, exactly? Stage EA sit-ins outside the CEOs office (I'm showing my age -- do people do sit-ins anymore?). Just who are we supposed to convince that CEOs should care about EA? Is there something more radical that can be done rather than gradually gaining credibility and influence and keeping a sharp eye out for opportunities to jump into business transformation initiatives?

The leadership the EA team here at Forrester is trying to provide is by showing how to have more business impact in very specific ways, enabling EA (the practice) and EAs (the individuals) to gain credibility and influence in IT and in the business and help move the organization to the next level of maturity. It seems like the right thing to me. I suppose we could grab a lot of headlines by saying more dramatic things like maybe "EA is Dead" but that sort of thing is just marketing and not research.

Gene: "How do we get there, exactly?" - yes, I'm well aware it's a huge challenge. Yet whilst we're still struggling to find patterns that do work, there are a known number of anti-patterns that definitely don't. And that's what we're on about here.

The big shift - and, if you like, you could put that in capitals, as some people do - is simply a shift in perspective: start from outside-in rather than inside-out. (For more on this, see my post 'Inside-in, inside-out, outside-in, outside-out' http://weblog.tetradian.com/2012/06/06/inside-in-inside-out-outside-in-o... ). It's not 'rocket-science', and it's not even a new idea: for example, see the contrast between classic 'push-marketing' and the approach described in Hagel, Brown and Davison's 'The Power of Pull' http://www.amazon.com/The-Power-Pull-Smartly-Things/dp/0465019358 . Look at any of the work on customer-journey, or customer-experience, and then translate that to how the organisation works internally as well. Look at what Tony Hsieh did with Zappos: sure, there's a lot of technology, but it _starts_ from people.

Almost by definition, the architecture of 'enterprise' is first and foremost about people: the technology is _only_ there to support that. If we ever get this the wrong way round - as most so-called 'EA' still does, with its inside-out perspective - then yes, that style of EA will drive the company straight into the ditch. So however we might rebadge it, it's _not_ a good idea to promote any kind of technology-oriented 'EA' as 'a good idea'.

Instead, shift the perspective to 'outside-in'. Start from straightforward strategic questions such as 'What business is this business in, anyway?' - because when you ask those questions from an outside-in perspective, you get _very_ different answers from the usual 'inside-out' perspective, which straight away become core drivers for any whole-context enterprise-architecture. To use your own terminology, it's 'counterintuitive' - but it's what works.

And you're Forrester: you guys _know_ how to present and deliver supposedly 'counterintuitive' ideas that work. So why continue to promote the same old myopically-flawed ideas about EA, when you know they don't work?

In which case, why the heck did you _not_ use that type of approach here? Because very clearly you haven't. Why not???

Another well-known way to describe this: start with why. (See Simon Sinek's book of the same name: http://www.startwithwhy.com ). By definition, starting with technology is 'start with how' or 'start with with-what': it's the wrong way round.

Your choice, of course. But best I drop out of this conversation for now, I guess: you know where to find me if you need me. Thanks, anyway.

1. By first understanding ourselves why are we not there, exactly.
2. By then explaining it to others, and convincing them.
3. By refraining from making dramatic comments "EAs should report to CIOs" etc.
4. By shifting the anchor of EA reasoning from IT/BT to complexity. Tackling complexity is clear business impact.
5. By propagating the thinking "all leaders must think like architects".
6. By communicating, communicating and communicating.

I agree it is not easy. But this is a great opportunity for Forrester - and this isn't the time to be cynical.

"Just who are we supposed to convince that CEOs should care about EA?"

I think Gene's point is - what is the most practical approach for the 93% of of our clients that have EA practices whose epicenter is IT? Do we advise them that their EA rolled up to CIO model is hopelessly broken and there is nothing they can do until they fix that (which is a board level decision that many businesses aren't even remotely ready for)? Heck no...that position is untenable. Do we advise them to have a conversation w/ their boss (usually the CIO) about the future of 'architecting the enterprise' and business technology? Sure, but that doesn't help them with the problems they have now, it only influences toward a notional future that is still not totally proven.
I repeatedly hear from clients that they come to Forrester because we provide practical answers to immediate pressing problems - so while I think you guys have a point and an idealistic vision about what should be, let's be good architects and address both the practical, tactical now while keeping the aspirational future square in our sights.

Brian: "Do we advise them that their EA rolled up to CIO model is hopelessly broken?". Short answer: yes.

You _know_ it's broken. _Everyone_ knows it's broken. All we're suggesting is that there's a need to be honest about that, and instead tackle it in ways that _do_ work?

If it's broken, and you know it's broken, _don't_ sell them something that you know is broken. _Don't_ sell them something that you _know_ is not fit-for-purpose. Apart from anything else, there are serious ethical and legal issues around selling something that you know is broken without advising the client that it's broken....

And whilst I do believe, strongly, that we shouldn't do it any more, it's not true that "there is nothing they can do until they fix that": all they need do is shift perspective, and start doing it properly instead of wrongly. And that's not "a board-level decision": it's just a matter of shifting the mindset, from technology-centric to everywhere-centric, and inside-out to outside-in. It's not hard to do that shift: but the first requirement is that we have to stop pretending that the old approaches aren't broken.

We've talked about this in person: you've seen and read my work - you _know_ how to do this. You guys present yourselves as thought-leaders for the EA-discipline: so please, please, stop promoting those old, failed technology-centric methods and tactics that you know are broken and that you know don't and can't work. That's all we're asking here.

1) Yes I do equate design and architecture. How could you conjure the plans (architecture) for Versailles or iPhone check deposit without designing their structure and process?
2) Remember that the intent of my post was to educate CEOs about the importance of EAs. So when I said that EAs report to CIOs, I was was simply stating fact, as reflected in Forrester's data.

But beyond my post, it looks like Forrester should back up and outline the future of EA -- and include in that analysis possible organizational changes. My observation is that true Chief Business Technology Officers are far more conducive to working with EAs -- it's the old CIOs that don't get the importance of the function. That's because EAs (and CBTOs) are far more "B" than "T."

Hey Gang -- In our annual State of EA survey, we ask respondents where EA reports. It's interesting that in recent years the percentage of EA teams reporting into the business has gone from 4% to 7%, and it makes one wonder if that data is showing the beginning of a meaningful trend. But those numbers are very low, and with over 500 respondents the margin of error for the surveys is pretty low. So the assertion of EA not really being EA unless it reports to the business, especially to the CEO, is interesting but a tad academic at this point. IMO, one of the chief causes of failure of EA programs is the lack of perception of value caused by the EA team's tilting at windmills. Don't forget, Jeanne Ross et al intended the very popular 2006 book Enterprise Architecture As Strategy for CEOs -- but Dr. Ross will tell you CEOs DIDN'T READ IT.

Now, I agree that the best place for EA report is high into the business, to an exec charged with strategy. But that will only be viable when the organization is ready for it. The traction business architecture is getting seems to have business execs more interested in detailed views of strategy than ever before, and I believe this is key to a surge of interest in EA. But it's really early days yet and the vast majority of organizations are not ready for EA reporting to a business exec. Pushing the envelope can be a very good thing but it can also lead to failure.

One way or another, an enterprise architect needs to take technology into account when designing a business. To whom he reports into depends on the organizational context like maturity of business and IT change, maturity of (enterprise) architecture, the role and budget of CIO versus CEO etcetera.

Another thing is that the overall maturity of the enterprise architecture profession doesn't justify the claim that he should report directly into the CEO. We are still very immature! What I see in the Netherlands is that senior management finally starts to recognize that something like EA is necessary. This is a good thing because it will help to increase the competencies and skills of enterprise architects and bring them to the level that is needed to get access to the boardroom. At this point in time I guess that only one of ten people who call themselves enterprise architect are able to have a meaningful conversation with senior management.
The most important move we must make as an enterprise architecture community is to increase competencies and skills. This requires our joint efforts!

There is some great discussion here and, at the risk of throwing more fuel on the fire, I'd like to chime in with a slightly different perspective.

A great number of comments are centered on the "correct" role for EA to report into. This is not unlike many of the arguments around the reporting role of the CIO. The reality is that for many successful organizations the role of the CIO goes way beyond simply overseeing “technology”. This is not something new – good CIOs have always seen their role as a change agent, helping the organization transform around people, process and technology. Good CIOs are executive leaders first and IT leaders second (whether you call their teams IT, BT or anything else). Successful CIOs lead their teams to help develop and refine business strategy (see the Forrester playbook on "BT Strategic Planning"). In these successful organizations, Enterprise Architects and Business Architects play a central role in planning and steering the future organizational roadmap of people, process and technology – working alongside business-unit managers in many cases as partners. I suspect the notion that EA should report to the CEO (or anyone but the CIO) stems from the frustration many enterprise architects experience when working in a dysfunctional IT/BT group where IT is not seen as a true business partner.

On the question of IT vs. BT – the transformation from an IT organization toward a business technology organization reflects the understanding that the role of CIO is first and foremost as a business leader, albeit one with a responsibility for technology too. A BT organization is perceived by executives across the organization as a trusted partner in driving toward shared business goals.

Here is an experpt from an article I wrote for CIO magazine, quoting Jeanne Ross, director at MIT's CISR program. Seems pretty relevant to this discussion?

Myth: CIOs should own enterprise architecture.

Not so fast. CIOs often wind up accountable for the entire enterprise architecture, despite not typically having the authority or vantage point needed to create one that provides what the organization needs. This leads to a disconnect. "When the CIO owns enterprise architecture, it's a bad fit," says Jeanne Ross. "IT is being asked to do something the organization isn't committed to."

In reality, companies need to acknowledge that "architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO," says Ross. "If the CEO doesn't accept that role, there really can be no architecture."

Yes Martha, I am aware of that article. It came out after my discussion on LinkedIn "Six Reasons why EA should NOT be Assigned to the IT Department" went viral. Jeanne Ross rightly echoes the views that me and Tom have been saying for a long time. The same has been mentioned by The Open Group also (Len Fehskens).

Check out the HBR article in June 2012 issue. It is titled "How Managers become Leaders?".

I'm not disagreeing with the central idea that EA is about architecting the enterprise, nor am I disagreeing that buried in classic "IT" is not the way to do it. So, please stop implying that that is what we are saying.
The central disagreement is the "how" - we can and should gently push int the right direction; one skill I learned as an EA is how to influence without over pushing. That's how we get labeled as "ivory tower", thinking high thoughts about what should be versus how to deal with what is. I feel that is what we are doing here.
The fact is that most enterprise architects live in IT, and telling them that they are not really doing EA is 1) a bit pretentious, and 2) does them (who are our clients) absolutely no good.
Our "how" involves changing the lexicon, and slowly mixing a balance of practical now and future aspirational advice. And it involves a whole lot of dialog with the CIO, who must lead her peers to this gently over time.
Every CIO I've talked to and almost every EA has said that the CIO has the mandate from the CEO to lead digital business transformation - so let's not fight that, let's leverage it.

EA is 90% of why, and 10% of how, that being said, today's EA spends most of time to figure out "HOW' (business efficiency), with ignorance of Bigger WHY (business effectiveness). I like what folks pointed out, IT and EA face the same opportunity and risks at modern business today; On one hand, IT becomes competitive differentiator for business growth and competency; That's why EA also turns to be more crucial to bridge strategy and execution, be a glue to connect business and IT; on the other hand, both IT and EA are at lower level of maturity, over-focus on HOW, not asking enough WHY, not innovative enough to deliver business value.

Today's social computing also provides better opportunity for EAs to have cross-functional communication & collaboration, EA does need have enterprise level influence, however, the physical reporting hierarchy won't make EA from glue to guru overnight, the point is still: EA need focus on how to deliver the best value, from shelf-ware to shareware, to win some loyal customers first. thanks.

You know, if your an EA, you've probably been working for between 15-20 years already. When you started, chances are the only C-suite Exec who was comfortable with tech was the CTO. We all know thats different today. Bottom line - the old cliche of "business & tech" is coming true by default. QED, the Enterprise Architect needs to keep away from Ops folks (in terms of reporting line) or they will be seen as just another 'mad' techie.

As an EA, I'd want to report either to the CIO or CMO - the two roles that address strategic leveraging of Digital Technology. However, I'd take this further and say that we are trending toward a new C-suite role, the Chief Digital Officer and that this person is likely to encompass the information flows that move around the current CIO/CMO entities. I'd work for that person!

Recurring themes between this discussion and others over the years stand out to me so thought I would share some thoughts in case it helps.

1) The original intent of the post by George was on target -- it truly is astounding to witness the level of consistent ignorance on the part of CEOs and boards surrounding modern architecture, which despite what many EAs would apparently prefer, absolutely must include information technology in the super majority of organizations that expect to survive.

2) By far the most significant trend in our era impacting enterprise environments has been the emergence and evolution of information technology, and the impact on the global economy, competitive landscape, levels of debt and equity, type of transactions, decision making, and on and on. Anyone who denies this, whether under the title of EA, KMer, or CEO certainly in the majority of organizations impacted, to include national governments and every major industry cluster in the world, instantly loses credibility with the best and brightest in the world, simply due to the facts. The best estimates I've seen by leading researchers is that over half the global economy today is conducted over or through neural networks, aka the neural network economy. Not only is the trend continuing but importantly it is shifting strongly from transactions that are easily measured to influencing all manner of decisions, from consumer to politics to natural resources to factories to transportation and finance- it's clear that not only do many CEOs need to increase the incline of their learning curve, so do quite a few EAs-- obviously.

The irony that impacts almost all of us humans at times, certainly to include myself, is that our egos, hubris, and related emotions prevent us from practicing what we preach. I am reminded of this every time I ride my mountain bike through the former Anasazi villages near my current home that relied on faith alone to protect them from changing climates and aggressive competitors. No doubt the many years of peaceful existence and apparent security acclimatized them to a future that no longer existed, so they either adapted to a sustainable culture -- difficult to do especially without water, moved to more welcoming environments, and/or simply perished. Of the large number of villages that existed in our region only a couple survived and they happened to be adjacent to the streams sourced from the highest mountains- the fortunate few.

A couple of recent blog posts of mine are offered despite any evidence that it does me or my company any good, with considerable evidence that we primarily educate competitors--but perhaps it may help a bit anyway (post denial - educated addict?). Pretty basic, although I can confirm that quite a few of the more advanced CIOs, CTOs and CEOs are consuming the far more detailed versions in our confidential presentations underway.

Hope more business executives and Tech leaders get to read this post and the comments above. Long-term technology strategy for business competitiveness & survival is a must.

Based on your experience with working with several corporations, is it possible for the CEO and CIO (and their teams) to work together; improve their communication, teamwork & collaboration skills; so they as the Executive Management team can do the work of the 'Enterprise Architect' themselves?

(For different technologies and business trends, both the CIO & CEO can recruit different internal & external experts to their team.)

What are the disadvantages of this structure vs. creating a separate Enterprise Architect team? This would also remove the obstacle EA's face of not getting any approval or backing from either the CEO or CIO.

Yes, I know it’s tragic but not so unexpected – the EA has been ill for quite some time. This is very well described in the comments to George’s blog post.
When I was Chief Architect and Head of EA & Strategy for the largest Insurance Company in Sweden I stopped using the words EA, Architecture and Technology altogether. I went on a business road trip talking to all the business executives about what matters the most to them regarding meeting their long term goals and finally began talking about business models.

Business models describing the actual large granular value flow based on Capabilities/Business objects (no organizational aspect what so ever) with corresponding KPIs. I and my Business EA modeled some 60 different value flows based on three different Business models with all the BU Management teams and with the Group Management team – this was a great eye opener for all involved.

Yes I have to admit I had three EAs running the classic Business, Application & Technology views and corresponding Solutions (Architect) teams, but my key POV here is: It doesn’t matter who does the Business modeling and who (s)he reports to as long as it is someone with a business clout and an enterprise focal point.

Some of the discussions here around what EA is, and where it should report to, remind me a lot of a phenomenon I noticed since I moved from Europe to the US. Since EA is a fairly new topic, and not a lot of research had been established, it was interpreted differently across the ocean. This is a little exaggeration, but the focus of EA in the US is IT, whereas in Europe it is Strategy. Look for an Enterprise Architecture job description in the US, and you'll find tons of requirements that demand deep knowledge of technologies, in many cases even programming languages. Whereas a thesis on EA I wrote for a Swedish truck manufacturer (Scania) back in 2009 is a lot more focused on Business Strategy. Then Process. And then, once this vertical link has been established, we talk information. Whatever happens on the Application and Technology level is really the tail end of EA, driven by the layers above.

Another part of EA that is highly undervalued is the human/political aspect of it. Before EA can do anything in a company, you need to sell it to a) the executives who will sponsor/back up the EA initiatives, and b) those who are impacted by it (IT). Without a clear and concise message around the vaule EA brings to a company, it is doomed to fail.

Here's a link to the thesis, it's a good read. It also contains the only definition of the difference between "Enterprise Architecture" and "The Enterprise Architecture" (definite and indefinite form) I've seen so far.

Thanks! In some of your comments in this thread, you talk about a shift to complexity, and a necessity to convince and communicate. Could not agree more.

Complexity:
EA is about complexity - we are dealing with the architecture of what just so happens to be a very complex entity - the Enterprise. And the term Enterprise is everything but limited to IT, while "architecting" is a top-down approach, and hence should start with the spearhead of each Enterprise - it's business strategy.

Communicate and Convince:
I also believe that many failed efforts are not due to the reporting line. It's much more a problem of taking human and political factors into account - EA needs to be sold within the company (or Enterprise)! It cannot be yet another instance that is trying to gain control and power within an Enterprise from the top down (i.e. by reporting to the CEO). Much rather, people need to understand the value and benefits EA brings, not only to the overall Enterprise, but also to those affected by it (and that can, in the end, be IT Architects). If that level of communication and conviction is achieved, people will follow, no matter who EA is reporting to. Back to what has been said here before, it's a pull strategy, not a push strategy. And that's why I believe EA needs visionary, innovative and smart people that can communicate, and not necessarily people with 15+yrs of experience in Java, C++, .net frameworks and so on. In that sense, as you mentioned, Forrester has a great opportunity to be a thought leader, because the status quo in EA is still very IT centric.

We have assumed that enterprise architecture must be "within" a department - the usual suspects being Strategy and IT.

1. Is it time view of enterprise architecture as an extra-departmental (or a supra-departmental) activity and function?

2. Aren't departments / lines of business / divisions (or any other such structural entity) an outcome of the architecture process? Isn't defining the form and function of such structural entities a core part of the architecture process?