Is it Enterprise Architecture or IT Architecture?

In many of the online EA forums I follow, too numerous to mention all by name, I am seeing an increasing amount of participants questioning whether topics are related to EA or not.   Generally these topics are about lower-level, technology decisions that while within the purview of the overall EA, are really infrastructure/operations level decisions.  Similarly,  many EA events (conferences, webinars, podcasts) have participants who are increasingly asking “Is this still really what Enterprise Architecture is all about?”

This all revolves around a theme that I have been writing and talking about lately – the evolution of EA to be more than an IT-centric discipline.  Now on the surface, this may seem like an academic discussion.  Pragmatically, EA is still an IT organization’s responsibility within the vast majority of organizations worldwide.  While there is no dispute that EA started out as an IT-centric approach, most definitions describe EA to be more of a business-strategy driven approach.  Also, with the inclusion of Business Architecture as one of the domains of EA, practitioners are beginning to need to enter into the forbidden zone — the board room.

If EA is really going to become a method for “architecting the enterprise” rather than using business strategy as a driver for application, infrastructure and data future states, what is needed?   I think one precursor is acknowledged success of the EA contribution within IT.  This requires not only the full support of the CIO, but also the devlopment and collection of metics to support the claims of success of EA.  Secondly, there needs to be a business transformation effort to which the EA method is applied.  I have seen examples of EA being practiced with the business in full partnership (although still primarily applied to decisions within the realm of IT) when there is a major business transformation underway – such as major mergers/acquisitions, changing the business model, or significant modernization.  If an EA team can demonstrate visually and financially that their approach can help senior executives think through not only what their business strategies should be, but also the steps to take to execute those strategies, then EA can begin to fulfill its long-held promise as a business transformation enabler.

The question that I will leave you all with is this:  Can EA be successfully evolved to become a tool of business strategic planners, senior executives and boards of directors if we continue to call it Enterprise Architecture?

This may sound like a trite question, but for most of us that have been practicing Enterprise Architecture for many years, we realize that semantics count.  I believe that in most organizations, the connotations associated with EA are so strongly IT-centric, that it will hinder the ability to transfer the method within the business community.

What else could we call it?  More on that later.

10 thoughts on “Is it Enterprise Architecture or IT Architecture?”

  1. RE: “Can EA be successfully evolved to become a tool of business strategic planners, senior executives and boards of directors if we continue to call it Enterprise Architecture?”

    We see the same issues you so well pointed out Tim.
    I would suggest no, the name will not survive; it’s not a matter of if, but when. We talk about this frequently in our CAEAP organization and have some basic ideas on how to tackle.

    Mark

  2. Has the term Reformation ever been used in context of the Business Architecture and the changes in mindset around architecting the business?
    Really, what I think we’re talking about is a change of state, from what business has been with respect to IT to where it’s going. Thinking about it, there are similarities between The Reformation (the religious connotation) to what is happening in corporations. The teaching and preaching of IT shops is now being called in to question by business people, looking for answers, looking for more from what they are getting for their loyalty and faith placed in the almighty IT purveyors.
    As you know, more business people are looking at IT and treating it more like a pen and paper, than an oracle (yes, I used oracle as a play on words, a little), a way of improving the future outlook of the company’s bottom line through the use of technology and vast amounts of data.

  3. Name change? No. I think it is okay for a method, practice, framework, etc. to evolve without changing its name. I believe name changes are the reason so many business customers and IT practitioners alike are sometimes cynical about new ideas, often dubbed “buzzwords” in this industry. I’m convinced longevity has value; it proves an idea, methodology, etc. has outlived the “buzz” surrounding its debut, and has matured, or is maturing, into a true discipline that is taught in schools, written about in books, and practiced in industry; complete with case studies that explore the successes, failures, and continued challenges of its evolution.

  4. I see this argument from the other way around.

    I would say that there has always been a difference between Enterprise Architecture and technical architecture. The former has its origins in the Zachman Framework which has always included the business architecture aspects. Technical architecture has evolved to become IT architecture and IT planning.
    Most organisations have kept business architecture and IT architecture separate because of the typical separation of responsibilities within an organisation. They like to keep IT in there place so to speak. The language of IT architecture has claimed that it now deals with ‘enterprise’ level software, i.e. software applications like SAP that are used across all the business areas.

    For this reason many IT architecture efforts now rather erroneously call themselves Enterprise IT Architecture (EITA) or Enterprise Architecture, whereas in fact they still only address IT architecture subject matter.
    So when people claim to have been doing EA this is likely not to have been actually true and the ‘inclusion of Business Architecture as one of the domains of EA’ is somehow a further misrepresentation.

    EA has always been a method for ‘architecting the enterprise’, it’s just that IT Architecture is trying to claim EA’s clothes. The move from TOGAF 7 to TOGAF 8 and now TOGAF 9 illustrates this path. Many organisation’s have yet to truly understand that EA is different from EITA.
    As someone who has been trained in the Zachman Framework and IFW since 1995 and done ‘real’ EA, it is clear that IT Architecture should no longer try to claim to be Enterprise Architecture, but concentrate instead on being Solution Architecture and clearly distinguish itself from Enterprise Architecture which really doesn’t need to change it’s name. A sheep in wolf’s clothing is still a sheep.

    Adrian

    • Adrian,
      I completely agree with you on the difference between IT Architecture and EA and the fact that IT Architecture has been misrepresented as EA. Those of us who always understood why the word ‘Enterprise’ was part the name have tirelessly worked to reeducate the miseducated at every opportunity. I chose not to open that can of worms in my earlier response and simply chose to register my vote that we do NOT need to change the name. I think you succinctly addressed this bigger issue quite well. Thanks!

  5. If you have time to debate this subject, then you don’t have a clear understanding of Enterprise Architecture. The only people debating this term are well intentioned, but ultimately navel gazing.

    If you provide value to an enterprise- either through IT architecture or through EA- then you shouldn’t worry about your title or division title. If you’re reducing costs or creating revenue, the business will name you.

    Successful EAs rarely have the title EA, they are Director of Strategy, Director of Product Development, Chief Architect, Chief Strategist, etc. etc. and they have staffs called whatever.

    In fact, I get scared whenever some IT person with a big salary starts talking about “Business Architecture” because it usually means the don’t understand the business architecture (which is really just strategic planning around lines of business).

  6. On my team I work in a planning and strategy role. I am required to take the long term view, and have been tasked with articulating our vision for the future. In the same unit we have people whose day to day work is making sure solutions fit the current technical architecture of our organisation. (About 5000 desktops – to give you a scale indicator.) This creates conflicting agendas that if not recognised and managed have the potential to pull the team apart.

    I find the distinction between ‘enterprise’ and ‘solutions’ architecture to be helpful and important. There is a real difference between planning and strategy work that takes the 2 to 5 year view, and the need to build complex and technically coherent solutions to todays operational requirements. When we are working on our various projects I try to get the team to ask the EA and SA questions explicitly – how will our technical reference model, for example, support planning and strategy and how will it support solutions?

    I agree with those who argue that there are different but critically related roles. Some clarity in the nomenclature would be helpful. It will be an uphill battle though. For example here in my home town of Melbourne we have a University (RMIT) that offers post-graduate study in “Enterprise Architecture”. However they list a Computer Science degree as a pre-requisite, and a cursory examination of the curriculum makes it clear that this is a course on “IT” or “Solutions” architecture for large scale organisations.

    The development of this course also had the backing of Australia’s peak professional body for the IT industry, the Australian Computer Society (Kind of the AMA of IT). If the academics and professional bodies are staking a claim to the term ‘Enterprise Architecture’, and using to describe and create the discipline of large-scale IT solution design, we may need a different term. The need to plan the business and its technology together is not going away.

  7. Great comments everyone. I have continued to have this conversation with others during client interactions and speaking engagements, and one thing remains clear to me: Just as many people think EA and ITA are the same things as those that think that ITA, although called EA in many organizations, is really a subset of EA. I am firmly in this second camp, and will continue to help people understand that point of view.

  8. A late comment as the discussion is still on in the EA community. There is a debate between the rather new breed of business architects and IT architects. IT Architecture currently equals EA, that is true. And that is unfortunate because the IT EA does not deliver on its promise, lessening its credibility. IT Architecture is only a part of EA which should also include business, organization and non-IT technology architecture.
    IT does its best to provide an IT EA though, given the void in the business architecture body of knowledge.

    The Enterprise Business Architecture,to differentiate from the Enterprise IT Architecture, would be a proper name for this essential EA layer of interest to business and management. At the same time, the naming would reveal that BA, as IT, is still part of a whole EA.

    Nevertheless, the existing EA IT architects are restless and keen to move into the business architecture domain. And that is not too difficult as long as there is demand, there is no specific body of BA knowledge and no selection criteria for a business architect. I’ve already seen ads for business architects requiring TOGAF certification. Another issue is that, without an agreed framework, the BA mail fail to produce the goods. I had to build my own BA using concepts from business and process management.

    Adrian

Comments are closed.