We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

What Should We Call Enterprise Architecture?

Vote 0 Votes
In last week's Forum, What is the Key to Effective Enterprise Architecture? Tarak Modi raised the point (seconded by Peter Brand) that, as he said, "The key to success - Don't call it Enterprise Architecture!" So if we don't call it Enterprise Architecture, what should we call it?

15 Replies

| Add a Reply
  • "Some smart people in the room"

  • What about single enterprise view...?

  • It's not clear to me why the term 'Enterprise Architecture' is a problem. At the end of the day, if people believe projects are failing because of words we use rather than how a project is executed, I would question how serious they are in this belief.

    • Hi John

      My undestanding of Tarak is that business-oriented clients try to get rid of those self-proclaimed 'Enterprise-Architects', who - in fact - are technology-confined IT-Architects taking the high ground by asking enterprise leaders to re-organize in the stratum of organizational automation (Governance vs. Self-Organization) just like in the stratum of functional automation (Logistics) - not even aware that these two strata are to be distinguished.

      Business-people behave so to avoid foreseeable project failure due to ignorant IT-Architects alias Enterprise Architects, you name it. And to possibly achieve better alignment between Business and IT by properly distinguishing their respective domains.

      Enterprise Architects, deserving this entitlement (thus, being respected by business people), are the human-oriented counterparts of technology-oriented IT-Architects. Business-IT alignment requires that both kinds of architects play their role without trying go beyond their respective domains.

      If Enterprise Architects pay attention primarily to volition-execution flow and IT-Architects primarily to thread flow, there will be a good chance to achieve alignment of the two resulting architectures, since we can build on the correspondence between
      (a) volition-utterance and programming,
      (b) volition-execution and thread start.

      You may want to have at look at the detailed descriptions of the roles of both, Enterprise and IT-Architects on my Website: www.mastering-it.com > Portal Basics > Menu 'Basics' > Entry 'Alignment Strategy'


  • How about "Enterprise Architecture?" If you break down the name into its parts, both are still relevant and appropriate. Enterprise deals with an entire organizational ecosystem, not just a single product or service. Architecture deals with compositional constructs and their interrelationships. The behavior of putting them both together would seem to be the kind of outcome one would want if certainty were the point of the activity.

  • It doesnt exist in the real world

  • The term Enterprise Architecture(EA)is relevant and should stay since it conveys the concept of the Enterprise blueprint that would enable faster change, increased agility and better strategic planning of the Enterprise.

    Still EA has been defined in too many ways. There is no agreement on scope and purpose of doing it. Worst of all, existing frameworks help little since they are either high level or process oriented alone. As such, EA fails to deliver usefulness repeatedly to the dismay of everybody.

    EA is currently IT focused while the great promotional benefits promised at the Enterprise level never materialised. Management and Business are dissapointed because the expectations were high initially.

    Many IT people have jumped too easily the EA wagon since the EA architect title seems to convey status. Is a Java Enterprise Edition architect an EA architect? EA has nothing to do with software.

    What do these EA architects do? A few applications and infrastructure diagrams with no business meaning, IT assets inventories and sometimes roadmapping. Then solution architecture reviews that antagonize people because they have no foundation since there is no EA.

    Other people attracted to the hype become self proclaimed EA architects of the old before the EA has been hijacked by IT. They claim they do strategic thinking confusing us and the term one again. Even worse some claim the EA should occupy a CXO position.

    With such a little relevant body of knowledge it is no wonder that there so many Enterprise Architects but so few Enterprise Architectures.

  • How about "That Vision Thing"?

  • It seems like a reasonable set of terms to me, BUT, having played in this world for decades I am used to having someone create marketing terms to try and appease the money man while allowing the technologist to maintain our sanity. Underlining all these terms over the many years are real world scientifically based concepts, and patterns to help organizations achieve results with automated solutions. Of course, this can only be done when we are given the opportunity and all the road blocks are removed - tough challenge isn't it? Mostly political and structurally overloaded at the top.

    For fun, how about "A software/hardware manufacturers handbook to value-added success". For short you could just call it "My Automated Blueprint", or maybe "When your really ready to do it the right way - call me!", or "Its your money - how do you want me to spend it?", or "Just for fun let's create you something based on patterns and standards?", or "When are you going to pick up a book and read rather than depend on some bullet-ed slide deck, or worse some article in SkyMiles?", or "I give up what do you want to call it?", or "How much money can you waste before you go out of business?"

    I would like to pose another question. Is it easier for technical folks to understand the "business" or for business folks to understand the "technology"?

    My challenge is for technologist to become more business savvy and remove the top obstacles to the problem.

  • How about "Actualised Corporate Business Strategy"

  • One of our client consultancies recently raised an issue about using the name “Enterprise Architectâ€?. Many of their clients, particularly on the business side, didn’t understand the title unless a lot of context was included to help explain it. While I think most IT types have had enough exposure to EA to understand what it is all about, this isn’t true on the business side. Even though the name might be the industry standard, and reflect (to some extent) what we do, if it takes explaining then maybe it isn’t the best name.

    Additionally, when I work with new EA programs, I frequently find that they are in their second, third, and sometimes fourth or fifth iteration of building an EA practice. Often there is a negative connotation around the EA term built up from past failures. These clients also would like to use a different label for enterprise architects.

    Forrester sees EA as primarily a strategy function. It can be focused on business strategy, technology strategy, or both depending on the organizational approach. In a recent client session we brainstormed a number of different names for the enterprise architect including: IT Strategist, Business Technology Strategist, Enterprise Strategist, Corporate IT Strategist, Corporate Business Technology Strategist, and Enterprise Strategy Consultants. We also came up with a similar series of names replacing strategist with advisor.

    I like the Business Technology Strategist term best as it seems to align well with what EA teams are doing (or aspire to do) and doesn’t need much explanation.

    Jeff Scott, Senior Analyst, Forrester Research

  • How about something that illustrates that the focus of the discussion is on the business?

    - "Business Fabric"?

  • In my conversations with architects the issue of effective communication has been unavoidable. Within those conversations the topic of terminology has come up often enough to warrant some attention. Some report some success with slight changes in terminology to soften the impact of -- on both the business and the technical sides -- of what are ultimately measures to control behavior and outcomes. So a little internal marketing can go a long way.

    But ultimately it comes down to business value and the understanding and perception thereof, as has been expressed in these comments and elsewhere. I had one conversation with an architect in which she expressed her utter frustration that while her efforts were having a noticeable technological impact, the business side took no notice because the improvements were under the hood, so to speak. IT was working far better than before, was far more efficient at supporting the business, but that improvement was not obvious to the business stakeholders. To correct that problem that architect took measures to define and effectively communicate milestones relevant to all stakeholders. Those efforts continue, but the success of the improved architecture is now more visible.

  • I think the term "enterprise architecture" needs to stay. It is an accurate term for the work an EA performs. Perhaps it is EA behavior that needs to change?

    The unit of architecture is not a single piece of software, a lawn, or a skyscraper. It is an entire business where the moving parts are both silicon-based (software, hardware) but also carbon-based (people!). It is the enterprise - people, process, and technology. Arranging these entities together to operate efficiently in achieving business goals is the job. It is using systems-thinking - understanding all the connections - to address real-world business challenges.

    The term is accurate. Unfortunately, there is sometimes stigma associated with it.

    The EAs are perceived as the exalted ones in an ivory tower with massive white boards and snazzy PowerPoint presentations. Some are not involved in project streams at all within a corporation. This can be dangerous as they miss the reality of the organization's operation.

    Those of us in EA roles need to navigate the tension of flowing visions of enterprise greatness with the needs for immediate and ongoing execution of the enterprise. It is a discipline of balance.

  • I'm always struck by how bright and well-meaning EAs are. [the ones I've met anyway]. So it's odd that their influence is usually minimal; they seem always to be disconnected from the business and operational realities.

    The question about what to call EA begs another one: 'What's the point of EA?' Agreeing the answer to that might make the best name self-evident.

    Whatever they may be called, I see the EA mindset as vital. But EAs need to engage. They need to speak the language of the business, to roll up their sleeves and contribute to multi-disciplinary teams collaborating on continuous business performance improvement.

Add a Reply

Recently Commented On

Monthly Archives