Talk:Enterprise architecture

From Wikipedia, the free encyclopedia

Contents

[edit] Misc initial comments

There are a large number of EA practitioners that believe that EA has moved from a IT governance activity to a wider operational governance activity. The slogan "EA it's not just for IT anymore" (After the successful Florida Orange Juice Commercial tagline). Is anyone else finding this to be true? Stevebattista 17:29, 1 August 2005 (UTC)

According to John Zachman, EA was never just for IT. He designed his framework to produced detailed, structured descriptions of enterprises 'in the whole'. That's certainly the way we're using it at work. --Richard@lbrc.org 13:55, 6 August 2005 (UTC)

I took a shot at cleaning this up. Additional improvements (or corrections) are welcome. Gletiecq 04:04, 29 October 2005 (UTC)


  • I think all the external links should be moved to the end of article. Mahanchian 23:01, 28 February 2006 (UTC)

I agree, the definition from the business perspective (architecture not Architecture) is far closer to what any EA practitioner would use. The more detailed levels of the architecture tend to have IT involved, since most organization have some form of IT as part of their process and organization. Organizations that do not have any automation still have an Enterprise Architecture, just a low-tech one.

[edit] Definitions

Since there is no consensus on the definition of Enteprise Architecture, I think that we should list some different definitions available in literature. For instance, the US Office of Management and Budget, developing the Federal Enterprise Architecture (FEA), claims that "Enterprise Architecture is an established process for describing the current state and defining the target state and transition strategy for an organization’s people, processes, and technology." The Open Group, developers of The Open Group Architecture Framework (TOGAF), states that the "term 'enterprise' in the context of "enterprise architecture" can be used to denote both an entire enterprise, encompassing all of its information systems, and a specific domain within the enterprise" while the term 'architecture' means either a "formal description of a system, or a detailed plan of the system at component level to guide its implementation" or the "structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time". Pontus Johnson 18:17, 11 November 2006 (UTC)pontusj

Adding to this topic, the definition in the FEAF, at least, attempts to define the concept of 'enterprise architecture' which is salient to this topic. The TOGAF makes no such attempt. They define the words separately. Therefore, if this was wictionary, we could certainly reference TOGAF, but for a wikipedia article on 'enterprise architecture' we should probably rely on people who are attempting to define the concept itself.

I largely replaced the definition that was there (unattributed, and not related to FEAF's definition) with a specific definition from the MIT Center for Information Systems Research. --Nickmalik (talk) 21:01, 7 April 2008 (UTC)

[edit] Merged text

Here is the text that I merged:

In the same manner that buildings or aeroplanes have an architecture, so do Information Systems. That architecture is there, whether it is implicit or explicitly described.

An effective enterprise architecture (EA) promotes consistency across an organization's systems by guiding development teams towards using a common set of proven approaches. This not only enables reuse and improved system integration through common mechanisms and compatible semantics across systems, but also provides a better relationship to business goals, objectives, processes and rules. Your EA is part of the foundation which enables IT Governance.

A typical EA will address many views, including but not restricted to:

  • A business view
  • A structural (data/component) view
  • A technology (network/hardware) view
  • A financial (cost/benefit) view.

An Enterprise Architecture Framework, imposes a grid-structure. It asks you to define the What (data), How (process and technology), Why (business goals and rules), Where (Location and Network) and When (business cycle to batch cycle) from a conceptual to physical level (or from architect through designer, through builder to contractor views). Fundamental to this is the ability to link the cells of the grid together, for example the data to the application, the business process to the information.

Suggested Links:

[[Category:Business terms]] [[Category:Software engineering]] {{Compu-soft-stub}} --Dan 02:37, 20 April 2006 (UTC)

[edit] Enterprise Architect...this is not what I was looking for

Can we get a disambig page or at least a [i]For the Software Modeling Tool, see [Sparx Enterprise Architect][/i] ? please? Bihal 05:29, 29 May 2006 (UTC)

If nobody has any comments to make, I'm going to go and learn how to (and then) add a disambig link at the top of this article Bihal 05:55, 1 June 2006 (UTC)

Done. Bihal 01:49, 6 June 2006 (UTC)

Notable enough? (I wasn't the one who deleted, but the question certainly came to my mind. And I am an enthusiastic EA user.) Charles T. Betz 02:41, 13 June 2006 (UTC)

Well, notable enough to already have its own article. The article is useless if people can't get to it. Bihal 03:56, 13 June 2006 (UTC)
I'd be inclined to mark the EA product page for deletion. It sets a very bad precedent. But I'm not going to fight that fight. Charles T. Betz 02:48, 16 June 2006 (UTC)

[edit] Ivory tower EA

I have marked this section as needing citation. It is very POV and requires supporting evidence. Anecdotal impressions of "ivory tower" EA groups is insufficient; I am going to be a real stickler on this one and require notable, verifiable sources. Charles T. Betz 01:57, 24 October 2006 (UTC)

[edit] "Criticisms of EA" Section

This might be a surprise to some EA proponents, but there have been a number of big flops in EA, including the federal government. EA requires extensive use of time from representatives across the business and, I've seen on more than one occasion, a virtual revolt of apathy by these participants. EA projects tend to be long and after the first several months of long meetings and workshops, many participants (right or wrong) start to see it as unnecessary overhead.

Furthermore, there have been many "successfully completed" EA projects that ended up having little or no effect on actual development efforts of new systems. I had one client who was just starting an extensive EA project and did not realize they had completed one over 10 years earlier (of course, with entirely different team members). The first model went so unutilized that it had no apparent effect and fell off everyone's radar screen. Now, I know many EA proponents might say that for this reason we should not consider EA ever "completed". To that, I say see the previous paragraph.

I'm sure proponents of EA will argue that such things would never happen in a "properly" run project but, in reality, these problems arise even when "experienced" EA proefessionals are brought in to guide the project. There are three fundametal issues that make these problems a reality: The extensive and ongoing time requirements on the rest of the organization, the relatively abstract nature (at least to the business participants) of the EA and its purpose, the need for constant enforcement to guarnatee use of the EA by future initiatives.

For these reasons (and a few more I think others can think of) there needs to be a Criticisms of EA section in the article.Hubbardaie 14:41, 16 July 2007 (UTC)

[edit] Too much "advertising"

I removed a lot of links that were blatant advertisements and pointed to non-authoritative sources (I'd consider we should use only seminal articles, and those that are truly independent, with mandates from governments (even indirect ones such as COBIT as used by audit offices. This page is quite schocking for the number of self-promotions that had been inserted. I've tried to put some of these into a hierarchy so readers can identify the more commercial frameworks, but I hope contributors will monitor such activity in the future David T. Bath 02:44, 6 November 2006 (UTC)

More blatant advertisements added since I (partially) cleaned this up. I notice that one (Tata Consulting) has created it's own wiki entry for self-promotion, even though it is unlikely to be as worthy of an entry as IBM, Ford and other companies that have had an influence on the world. Should we say "tata" (goodbye) to the Tata self-promoting entry? How do we ask for a blatant self-promoting wiki entry to be removed? Does this need arbitration? Can other readers please be watchful and ruthless about such self-promotion? One of these ads (for Zero Delta) knows so little about wiki formatting that they used the double-square-braces to point to another wiki entry about themsevles that doesn't exist - but then that probably reflects other aspects about their knowledge and capabilities! David T. Bath 06:16, 12 November 2006 (UTC)

I don't know if we're talking the same Tata Consultancy Services Ltd but they are one of India's biggest employers, generate profits in the billions of dollars, and are highly regarded in professional circles. Not minnions by any stretch and certainly a company that has had a major influence on the world. IMHO Poweroid 18:10, 13 November 2006 (UTC)

[edit] Related article (Architecture_frameworks)

To my mind the discussion of EA frameworks here is better than "Architecture_frameworks" which should be moved to a separate page "Enterprise Architecture Frameworks" or subsumed into this article. In general, the Architecture_frameworks and this page reflects very poorly on the disciplines we are supposed to exhibit, NEITHER even pointed to Zachman's seminal article in the IBM Systems Journal. Compare the articles on DODAF and MODAF for example. If we move the Architecture_frameworks article into this one, I suggest we include an outline of the "quagmire", i.e. the interrelationships and history of the frameworks. Unfortunately, the best web page I've seen on this is no longer available. (http://www.software.org/pub/architecture/quagmire.asp) David T. Bath 02:44, 6 November 2006 (UTC)

[edit] Please edit carefully

It appears as though there are arbitrary criteria in use for drawing a distinction between commercial vs. non-commercial frameworks or methodologies. The Zachman Framework is a commercial framework. The only 'non-commercial' aspect to ZF is a published cell structure diagram that has been floating around the public domain for many years. ZF is heavily commercialized vis-a-vis ZIFA.

[edit] Why I treated ZIFA as non-commercial

I (David T. Bath 06:05, 12 November 2006 (UTC)) agree that ZIFA is commercial, but Zachman should be given due credit for his early work in the field, which is why I cited the more esoteric article in the IBM Systems Journal, rather than pointed to ZIFA. I totally agree ZIFA is commercial, and that the Zachman diagram beloved by many architectects is mainly of historic interest. (see the quote from the EABOK I made in reference to the Zachman diagram v DODAF and the FEA). Nonetheless, I stand by my decision to split up the references between non-commercial and commercial: while still welcoming peer review. Also see my comments about "too many advertisements" higher up in this talk page. I note that commercial organizations have again added MORE self-promotions to this page. David T. Bath 06:05, 12 November 2006 (UTC)

[edit] 'Technical' Merits of Zachman

I realize that this isn't the forum for debating the technical merits of one framework/methodology over another; however, I feel compelled to point out that placing too much emphasis on Zachman is (i) a bias or predisposition for lack of a better understanding of this practice area, (ii) mis-leading to the knowledge seeker, who may assume that Zachman is the appropriate solution to solve the woes of developing an effective EA programme and, (iii) a negative gesture towards other solutions that may be more robust, effective, and efficient.

Certainly I hold with your comment that ZF should be given credit as a 'seminal' piece of work. The conceptual framework that John laid down was, in 1983 (emphasis), an epiphany to architects (more appropriately in those days 'engineers') who were so focused on the 'bit level'. Based upon my experience with ZF over the course of the past 12 years (and general system design theory experience to nearly 20) and inputs from hundreds of companies the world over, there are serious short-comings in this approach, which have contributed to (i) failed EA efforts; (ii) EA efforts that are little more than 'staff-captured architecture exercises', and (iii) serious confusion in the market about how to 'make the leap of faith' from a conceptual framework to well-articulated and effective blueprints and roadmaps. I've personally witnessed Stan Locke, while presenting at a conference in Dublin, struggle with this very issue as he fumbled with a marvelous 3-dimensional cube format of the ZF.

The burden is on responsible members of the COMMUNITY to determine how best to articulate what is Enterprise Architecture. I posit that, being that it is nearly 2007, we look to solve the conundrum in this space and practice tolerance and patience as the market continues to shift towards a viable commercial framework and methodology.

Cheers.

[edit] Criticism of article

Am I the only one who thinks this article is a bunch of xxxxxxxx? It's as vague and confusing as the useless junk you find on corporate websites. I'm a programmer and none of this seemed like actual solid work products someone could spend time on. Am I to believe that enterprise architects just draw diagrams and create other useless stuff rather than actually creating stuff -- you know, like writing programs and scripts, installing and configuring software and servers -- actual stuff? Jesus christ I hate enterprisey nonsense. Whenning 04:52, 2 January 2007 (UTC)

Those programs, scripts, software and servers (what you call actual stuff) are to serve enterprise (bigger stuff) also known as organizations. Enterprise architecture is a way of understanding and modeling organizations in the same way software architecture understands and models computer programming. Believe it or not, there's a bigger world (outside of those little boxes) that involves bigger programs (organizations) with people that are much more important and influential than the tools (computers) they use. Oicumayberight 07:36, 2 January 2007 (UTC)
See, you people can't ever escape the world of meaningless consultant xxxxxxxx that you depend on for suckering in businesses. If the CEO needs outside help just to understand what they've been spending the company's money on, they have problems that can't be solved with Microsoft Visio, you sarcastic jerk. Whenning 16:59, 3 January 2007 (UTC)
Excuse the mild sarcasm in reply to vulgar words like "BS" to describe this article. Why do you even care enough to make comments on this article? What are you afraid of? If it were "meaningless", nobody would be interested in it, let alone interested enough to write an article with dozens of contributors. Just because you are not interested in the subject, doesn't mean nobody else should be. The world doesn't revolve around your perspectives and opinions. Look in the mirror. And you're calling me a Jerk? Oicumayberight 20:00, 3 January 2007 (UTC)
Calm down gentlemen. I am an Enterprise Architect and to be fair to Whenning, I find myself in agreement with him, albeit in slightly less colourful language. A large part of my job as an EA is trying to promote it to the rest of the organisation... Communication --> Comprehension --> Acceptance. In the beginning, we were having huge trouble with the 'Comprehension' part, and as a result we weren't getting 'Acceptance'. We were communicating but people either weren't interested or didn't understand. From speaking to peers in other organisations I was in no doubt we were in the same position as many other companies; EA is the 'ivory tower'. It took us a while to realise that the message was too vague and too complex. We spent a lot of time and effort 'rebranding' our EA initiative in a way that the average developer can relate to. This is not dumbing down the message - these people aren't dumb. It's simply removing the 'enterprisey', 'consultanty' waffle that we, as a group of people, use far too easily. We distilled the EA message down to a set of simple questions: "What is Enterprise Architecture?". "What's in it for me?". "What's expected of me?". The answers to these questions are very simple, short, and avoid jargon or 'fuzzy' terminology. We call it "Pub Language", because if you're in the pub having a drink and a non-IT mate asks you what you do for a living, you don't reply with: I apply a comprehensive and rigorous method for describing a current and/or future structure... blah, blah, blah.
To get back to the point, I think this article is meaningless to anyone outside the immediately circle of EA. It seems like a lot of words with very little meaning. We used the original Wiki EA definition (about 18 months ago) in the original presentations we gave to staff and it just didn't work. I realise that Wikipedia is not a tool to train staff, but at the same time the articles need to be understood by all - an expert (or someone truly interested) in the subject will use the Wiki article to gain a basic understanding and read more detailed books or websites for the more complex information. As a random example, look at the Cricket article; a universally applauded Wiki article for it's ability to describe a complicated sport in a simple, understandable, encyclopedic summary.
At the moment, I think this article is over-kill. I would post my organisation's 'Pub Language' definitions, but that would be Original Research! John the mackem 09:45, 22 January 2007 (UTC)
Translating the jargon to pub language may be needed. It appeared to me that Whenning was implying that the article should be deleted because the concept was useless. I don't think the concept of studying and improving the structure of organizations with universal language and modeling is useless. Improve the article, but don't call it BS. Just because it's difficult to understand, doesn't make it BS. Most of us don't understand quantum mechanics either. Oicumayberight 04:33, 3 February 2007 (UTC)

Just to kick in my 2 cents (and not indent, so perhaps you might give feedback here) is that we might say something like this for the 'pub language' specification: The scope of the enterprise architecture domain is the enterprise wide identification, specification, and prioritization of business needs. Therefore the enterprise architect produces the enterprise architecture vision, identifies the "as is" business and technology architectures, determines the "to be" business and technology architectures; and provides governance to this iterative process. The key factor here is, the concept of business architecture -- and the wikipedia article on this is not currently that good (imo).

I personally still think it's a bit vague. How about - A organisation may introduce an Enterprise Architecture programme in order to answer questions such as "What do we have?" and "What do we want to have?" - where the "What" is any business asset such as data, software, technology, business process or organisational unit. Mapping what they have allows a organisation to identfify areas of poor coverage, or areas of duplication. The Enterprise Architecture team is also responsible for generating the "roadmap" outlining how to go from the "as-is" to the "to-be". John the mackem 23:35, 2 February 2007 (UTC)
A key point needs to be, I think, a focus on the concept of "business architecture". Which is why I think the wikipedia article on that needs to be improved. Typically business architecture sits on top of a stack with 4 (or 5) layers. A 4 layer stack might be: business architecture, information (or data) architecture, application (includes SOA) architecture, and technology (or infrastructure) architecture. Enterprise architects work first with the business architecture layer. Organizations that don't conceptually have a business architecture, don't really do enterprise architecture -- typically they have people who were J2EE (or dot NET) jockys, DBAs who worked up to be data architects, they staff a group with these people and call them the enterprise architecture group. Now such a group can mature into doing true enterprise architecture, but the business architecture development is a prerequisite. —The preceding unsigned comment was added by SunSw0rd (talk • contribs) 15:17, 5 February 2007 (UTC).
Agreed; I alluded to this when I mentioned that an EA "as-is model" helps an organisation identify areas of weakness and areas of duplication. Obviously you need some Business architecture in order to do this, as you need to group your assets into areas before you can analyse the distribution. I still think "Business Architecture" is a vague, consultanty term... we call ours the "Base Map" which is just as bad to be honest! John the mackem 16:53, 5 February 2007 (UTC)

Having contributed to the original article, and having struggled for the last 3 years to get architecture in our IT department accepted to the level it is at the moment, I can see where both sides are coming from. The whole is still getting bogged down in tech speak, and, whilst definitions can be useful, reading this at 2am in the morning is showing that there is still far too much jargon in the article. When this happens, it usually means you have an elephant to describe. So breaking it down for the definition: "Enterprise" - an organisation as a whole, such as a company or government department. "Architecture" - a set of documents and models describing why the item (building, aircraft, enterprise) is there, what it consists of, how it fits together, what resources it uses and related standards, measures, rules and constraints. Why do you need architecture? For the same reason you need it when building a tower block - without it you cannot get all the bits (presentation, data, function, integration, hardware and communications) to integrate together without a lot of mistakes along the way. It's too late at night for me to research the sources, but, if I remember correctly, there is empirical evidence to show that architected projects typically have a total cost of ownership of 50-75% of that of a stand-alone project, and a far lower rate of project abandonment. For reasons of commercial confidentiality I cannot quote actual projects we have pulled - nor the ones we shouldn't have done whilst outsourced to a consultancy firm - but when I was a programmer there was nothing more frustrating than working on a project for a year only for it to be thrown away three years later because it was only a tactical solution, rather than a strategic one --MaryEF 02:52, 22 April 2007 (UTC)


Too Much Jargon! EA doesn't produce "artifacts" that describe the enterprise. The models produced are hardly byproducts - they are the core of EA. So why not just say models? Here is a (better I think) definition of Enterprise Architecture: "A structured description of an organization which includes a framework (which defines the structure) and models (which are the description). Enterprise Architectures may also contain other elements, such as reports or findings but a framework and models are always present." Adecker720 (talk) 23:43, 26 January 2008 (UTC)

[edit] Create subsidiary pages in a category??

I think it might be useful to split up this page into separate topics, if not make Enterprise Architecture a proper category.

"Enterprise Architecture Frameworks" in particular is a good candidate, as it would include a description of the various frameworks (e.g. DODAF, TOGAF), underlying theory/rationale/requirements, history (e.g. going back to Zachman's initial article), and provide pointers to the various modelling "languages" (graphic and textual, e.g. Process Modeling (although I prefer two "L"s in modelling) , IDEF, UML).

Many of you probably have ideas about good candidates for other pages, and before doing anything, i think there should be considerable discussion. I leave taking any action personally for a month or so.

As a side advantage, blatant ads would become more obvious if they were not confined to the relevant page.

David T. Bath 05:06, 6 January 2007 (UTC)

I came back for a look, and it was enlightening to look at the diffs for the last month. Guess where almost all the activity was? That's right, the advertisement section. One "contributor" took three or four goes to enter in a link to an external site (a closing square bracket is soooo useful), so either suffered from partial seizures (I do) and consequent fumble-fingers, or was a newbie to the wikipedia and the "preview" function. So many contributions, such little enhancement to the article. I wonder if any of them have read the article and used any of the reference material from authoritative sources. No wonder such contributions are anonymous! (You can probably guess which anonymous edits over the last few months have been mine from looking at the diff).

Maybe we shouldn't have subpages, but get rid of the page altogether, although on second thoughts, it does provide useful information to non-EAs about the rigor and motives of a substantive number of people who call themselves EA practitioners. Any EAs out there who can get huge kudos by revamping the whole thing and prove that their salary is justified? Any wiki-experts feel like putting the whole thing under an "unregistered users cannot edit policy" if there is one. I'll wait a month or so more, and maybe put in a long weekend so this gets into shape unless someone else does. David T. Bath 18:36, 2 February 2007 (UTC)

I would definitely support Frameworks being moved to separate topics. Likewise modelling tools. --MaryEF 02:55, 22 April 2007 (UTC)

[edit] Title Needs Editing

Does anyone know how to edit the title? The "a" in "architecture" should be capitalized. Factician 19:39, 27 March 2007 (UTC)

[edit] eTOM (enhanced Telecom Operations Map)

Should we add eTOM as a EA framework?

[edit] Linkfarm

Most of the external links (and probably some references) need to be removed per WP:SPAM, WP:EL, WP:NOT#LINK, and/or WP:SOAP. Most of the external links look easy to assess. The references will take work to ensure they either aren't actually being used or are not reliable sources. --Ronz 18:40, 30 July 2007 (UTC)

[edit] EA Frameworks

Should specific EA Frameworks be listed in the "See Also" section of this page, when there is already a reference to the EA Frameworks topic? Jmgendron 20:41, 4 December 2007 (UTC)

[edit] Moved here for discussion: Further Reading

Given the lack of references in the article, this Further Reading list is a distraction at best:

--Ronz (talk) 22:36, 25 January 2008 (UTC)

When under the heading of "Further Reading" why are these references considered a link farm? Enterprise architecture is a HUGE topic & these links appear to be a nice, moderate beginning for someone new to an immensely complex topic. I vote for putting this section back into the article. DEddy (talk) 18:51, 26 January 2008 (UTC)

Thanks for the response. My apologies for not getting back to you sooner. Basically, WP:EL, WP:SPAM, WP:NOT#LINK, and WP:COI still apply. More importantly, the article needs references, and this linkfarm is distracting editors from providing them. --Ronz (talk) 16:55, 31 January 2008 (UTC)


[edit] Conflict of interest discussion

Going on at Wikipedia:Conflict_of_interest/Noticeboard#Enterprise_architecture --Ronz (talk) 18:58, 18 February 2008 (UTC)

There is already some beneficial editing going on over at Zachman framework, since a number of participants do seem to have knowledge in this area. In a way, Enterprise architecture is the parent article for Zachman framework and it is highly desirable to make this article better. (This is our chance to give a nice overview of the concepts). If you do have general ideas for improving the whole area, you are welcome to contribute to the COIN discussion of these topics. EdJohnston (talk) 04:25, 2 March 2008 (UTC)

[edit] Sparx Enterprise Architect redirect

Sparx Enterprise Architect is not a commercial link or reference. It is part of a standard Template:Redirect redirect to help those who went to Enterprise architect by mistake while looking for Sparx Enterprise Architect.

Note that Sparx Enterprise Architect is being considered for deletion: Wikipedia:Articles for deletion/Sparx Enterprise Architect --Ronz (talk) 17:30, 21 February 2008 (UTC)

That AfD closed with Merge to Sparx Systems. There seems to be no case for making a hatnote on Enterprise architecture to specifically point to the Sparx tool 'Enterprise Architect.' Even the article on Sparx Systems doesn't yet have any reliable sources to document the notability of Enterprise Architect. EdJohnston (talk) 04:16, 2 March 2008 (UTC)

[edit] cleanup of opening paragraphs

Not sure if it will be warmly welcomed or not, but I edited the first two paragraphs to put in, first, a definition of EA from an established and credible source: MIT Center for Information Systems Research. Peter Weill, the director of that center, and Jeanne Ross, his collegue, co-authors of the book "Enterprise Architecture as Strategy" defined the term Enterprise Architecture in their work, and I felt it was a cleaner, more complete, and more authoratative definition that the unattributed one being used in the pre-existing article here.

What I don't like about this article is legion. It doesn't flow. It is not readable. For people who don't already know the material, it is unclear what they are supposed to learn from it. I will be wandering by on occasion to try to rectify the readability, without, necessarily losing content. --Nickmalik (talk) 22:08, 4 April 2008 (UTC)

[edit] comparison of frameworks table

Where did this table come from? Who considers it authoratative, or even useful, or correct? I do not. --Nickmalik (talk) 22:08, 4 April 2008 (UTC)