Talk:Enterprise architecture/Archive 1

EA practitioners

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.

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)

I am involved with The Open Group Architecture Forum and there is a peice of work being done to provide a comprehensive defintion of the terms surrounding, let us call it, technology and business architecture. I will soon be recieving some work from the forum which I will be happy to contribute here. This work has been carried out in a TOGAF neutral manner and thus seeks to provide an industry standard definition that is not IT centric and not TOGAF focused.

--Colin Wheeler (talk) 15:05, 23 January 2009 (UTC)

Implicit in the very meaning of the words, surely the only logical definition of "enterprise architecture" is the architecture of an enterprise? Bob Jarvis in Enterprise Architecture: Understanding the Bigger Picture - A Best Practice Guide for Decision Makers in IT" references the IEEE 1471 definition of 'architecture' (which seems to be accepted by a large consensus of practitioners) and comments that "so-called 'Enterprise Architecture'... []...is usually regarded as an umbrella architecture that covers business, application, information and technical architectures too.". That document is published by the UK National Computing Centre - who also had a hand in the definition of the SDLC. The four sub-topics (or domains) are also, I think, generally accepted as EA domains by most practitioners - and I'm sure there are dozens of authorities that can be referenced to that effect.

I think there is also a consensus on the meaning of 'Enterprise' in the term "Enterprise Architecture" - which is roughly along the lines of "a number of people in some organisational structures who share a common set of purposes" - but I can only refer you to a LinkedIn discussions between practitioners for that.

Bob Jarvis also goes on to comment that "An Enterprise Architecture is a dynamic and powerful tool that helps organisations understand their own structure and the way they work. It provides a 'map' of the enterprise and a 'route planner' for business and technology change."

That document also defines the "Strategic Architecture Model" (SAM) which can be regarded as another EA framework similar to TOGAF, EAP, IAF etc.

I would also observe that EA as a profession is still as yet immature and that consensus of practitioners may be as important in defining the evolving semantics of the professional terms as published authorities. —Preceding unsigned comment added by Ian Glossop (talk • contribs) 12:45, 22 January 2010 (UTC)

I believe that there is a deep lack of shared meaning around what EA is. I believe this is caused by the use of vague words to decribe it. When we say that it is more then just about IT, that it's about the whole, or about the business, or about people/process/technology... what does this all mean. In the context of EA, what does business mean exacly, for example is organizational structure/design included or compensation for that matter! When using the classic triade people/process/technology does the people component include organizational culture, kwowledge management, etc. If it is about the whole, were is capital budgeting included ? Also, there as been a lot of work done on the concept of strategy by people such as Mintzberg as well as work on the relationship between people and technology by Emery and Trist. Shoudn't this body of knowledge be acknowledge by an article on EA since many talk about aligning people/business with technology or that EA is about strategy ! Do others feel the same way ? It just that I feel that this article is based which regards to in perspective on EA, as though there was a certain level on consent around the term but there is not! Moreover, I believe that ver y little is known about EA because there is very little research being done (maybe only 5 places in the world)... a lot that is written is basically folklore and pop culture. --Jlapalme (talk) 02:48, 30 July 2010 (UTC)

I agree with all the above.

In the introduction of TOGAF "enterprise" is indeed defined as either being the entire enterprise or a specific domain within the enterprise. Apart from that there is also a note on the "extended" enterprise which includes partners, suppliers and customers as well as internal business units. This is an interesting idea in point of view of the nature of for example supply-chain management and modern telecommunication business. Obviously the scope of the enterprise architecture needs to be clearly defined and needs to be aligned with the objectives. —Preceding unsigned comment added by Yves.bouwen (talk • contribs) 14:01, 30 July 2010 (UTC)

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:

• Enterprise Archicture for the RUP
• Agile Enterprise Architecture Techniques
• Zachman Framework

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

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)

I removed the disambig link to Sparx Enterprise Architect. The primary reason is that a search for "Enterprise Architect" will produce a different page. The name of the product is not "Enterprise Architecture" so a link from this page is nothing more than advertising. 24.17.70.103 (talk) 16:16, 20 September 2008 (UTC)

On the contrary, I searched for "Enterprise Architect " and was brought to this page, expecting to be taken to the Sparx product. Either that page should redirect to the Sparx product page, or there should be a disamb link on this one. 62.25.109.195 (talk) 09:42, 14 January 2009 (UTC)

Following wikipedia naming conventions Enterprise Architect should redirect to Enterprise architect, which could be a disambig page.

Oops... Enterprise architect is allready an article. Enterprise Architect should simply redirect to Enterprise architect here and the problem is solved. I will fix this in a second. -- Mdd (talk) 11:37, 14 January 2009 (UTC)

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)

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

I agree with Hubbardaie on this and as a practicing EA feel that it would be a good idea to expose this pitfalls so that people can avoid them. I always say that 20% traction is good traction in EA and most EA projects and programmes that I have seen do not deliver anything near thier "advertised" potential. This does not mean that it is an activity that should not be carried out, but rather that it is an activity that should be approached with a more reason level of expectation and a more mature promise of results. I find that EA is generally overweight and this is the primary reason why the business generally finds little benefit in it after having turned to an EA programme in desperation to find solutions to very challenging problems.

--Colin Wheeler (talk) 15:11, 23 January 2009 (UTC)

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)

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)

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.

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)

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

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)

Can anyone explain (not only in this discussion page, but in the article itself, the VALUE of developing a system architecture? It costs a lot of time and effort to develop it for sure, such as DoDAF products. But is there a ROI on it? Please elaborate, and elaborate profusely. This looks too much like a paper exercise with no real benefits.--96.244.247.130 (talk) 01:03, 1 July 2011 (UTC)

I agree with Whenning. I zoned out after the first few sentences. It's hard to think this isn't wishy-washy MBA speak when it can't be explained in clear, normal terms. 192.104.54.79 (talk) 18:09, 14 February 2013 (UTC)

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)

For those of you who are so concerned about the "ivory tower" aspects of EA, I believe that it may be true that creating a 'complete' EA is unrealistic and non-productive in the real world. Still, as an overarching description of such artifacts/models and the consideration that all of these aspects of an organization should be aligned, EA has an important place. The models will be created as the need arises and alignment with other aspects of the corporate environment will be key to designing these appropriately. Over time, one may have many of these artifacts available, if you keep them, so as to speed up new initiatives. For example, if a company decides to look at a new market or launches new product, this will undoubtedly affect the corporate strategy, require new processes, possibly new organizational structures, maybe changes in IT strategy and architecture, changes to applications, changes to the websites, possibly facilities in the new market, and on and on and on. All of these changes should be in alignment. Making changes from the existing structures is easier if you know what they are. Identifying where you will continue to need to tweak things will be easier as well. Well, that's enough for now. Like I said to start with, the goal is not to create an EA but the aspects of day to day transformations will require these artifacts. EA gives a good way to think of it all in an organized fashion. —Preceding unsigned comment added by WTGhack (talk • contribs) 16:35, 12 May 2010 (UTC)

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)

eTOM (enhanced Telecom Operations Map)

Should we add eTOM as a EA framework?

In my opinion the eTOM/SID (now rebranded Frameworx) is not an EA framework on the abstract level like TOGAF or Zachnman frameworks are. But this framwork can be seen as an telecom industry specific application of a more abstract EA framework. One of the tasks an enterpise architect should do is evaluate and adopt such industry specific frameworks. Such tasks are specified in the TOGAF Architecture Development Method (ADM). So TMF eTOM/SID is not an EA framework as such, but it has a clear link to them for sure.

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)

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)