Enterprise Architecture’s Quest for its Identity

49 comments

1. One of the best and clearest descriptions of ‘real’ enterprise-architecture that I’ve ever seen: many thanks!

2. Well, said! I’d answer your two questions almost exactly the way you have!

3. Len – I love you, and I want to have your babies!

   I agree 1000% with everything you say and am stunned at the way you have said it – that post is going to do more to advance EA and it’s understanding than anything else in the last 10 years.

   Massive, massive kudos Len. Please please please please create a discussion on Linked in (EA Network is probably the best/widest) and paste you response above into it for people to more widely read and discuss (and hopefully agree with) it.

   I was going to post and link to this blog but I think it’s better coming from you because then you “own” the discussion as the creator.

   Then post a link to it or its title here……

   1. Shit. Babies you said?

   2. It’s been posted on the Enterprise Architecture Forum on LinkedIn… thanks for the suggestion!

4. Great comments Len. I have been treating the enterprise as a sociotechnological system which behaves like a Complex Adaptive System. In order to really comprehend the enterprise and Enterprise Architecture needs a level of “systems thinking” and how dyanmic systems structures and behaviors and how they respond to change.
   There is an element of philosophy, cybernetics, mixed with chaos theory which makes the study of such systems in my view quite exciting. I would be interested in your feedback and thoughts on my blog. Cheers…

5. Great article! Very important to discuss and divulge the matter, specially at Countries, which are “discovering” AE – as Brazil.

6. Excellent article. Just yesterday, I met a java developer that wanted to get into enterprise architecture – if only I had read your blog at that time, I would have asked him those two questions. (My guess: He would have gotten it wrong).

   1. First, thank you all for the enthusiastic support.

      I want to address something Peter said. I’m not sure that we are in a position to make any assertions about particular answers being “right” or “wrong”. I think we ought to adopt a consistent and logical (in some sense) convention for naming architectures, but that would just be a convention, something that names would conform to or not. Until the entire community adopts such a convention, it’s premature to label things “right” or “wrong”.

      Similarly, until we’ve had a serious debate about the question of whether EA is an engineering discipline, it’s just one man’s opinion among many. I know people whose belief that EA either is or can be a “hard” discipline is every bit a strong as my belief that it’s not.

      len.

7. Let me start with saying that I agree with the article for about 80%.

   The statements on Enterprise Architecture, I fully subscribe. The discussion for me is in the second question.
   I believe that you give a ‘hard’ answer to the question whether EA is hard or soft.

   In my opinion, EA is also ‘soft’, but then in the ‘soft’ sense: there is no absolute answer. As with most soft sciences, there is also some ‘hard’ methodology to be applied to the questions of that science. E.g. in philosophy, we know the notion of ‘logic reasoning’, which is some sort of hard science. In sociology, there is a part associated with demography, using ‘hard’ facts and (soft?) statistics.

   So, in theory, there is no difference between theory and practice. In practice however…

   1. Jan makes a good point, and I did allude, albeit a bit opaquely, to this in the aside “It may be possible to do so for EITA”. But to be explicit, while there are certainly some things about enterprise architecture that can be done with a certain amount of rigor, as the old saw goes, a chain is only as strong as its weakest link. If I connect a number of titanium rods with rubber bands, I suspect it’s the rubber bands that are going to most strongly influence the aggregate properties of the assembly. To pursue Jan’s sociological reference, we can certainly do demographic analyses with arbitrary precision, but whatever behavioral inferences we draw from the numbers are at best speculative. Sociology is a very long way from the “psychohistory” of Asimov’s Foundation novels, and enterprise architecture is an even younger discipline with nothing like the accumulated empirical research that supports sociology. If enterprise architecture is (at best) an “80% soft” discipline, I have no problem dropping the “80%” as largely irrelevant to reasonable expectations about what EA can do for us, and how we should do it to achieve those outcomes.

      len.

8. @Len: “It’s been posted on the Enterprise Architecture Forum on LinkedIn… ”

   Cool, but it has 5,000+members while the Enterprise Architecture Network group has 50,000+

9. Len,
   My own view of EA is somewhat different than yours. I believe that EA needs to focus on the value that it and it alone can deliver. One important area where this value can be realized is organizational IT complexity control.

   By this I mean understanding how to project the business architecture onto the technical architecture so that the overall complexity of the IT systems is minimized and the ROI from the IT investments is maximized. If we can solve this problem, we will be solving a multi-billion$ problem. There is no other group that can solve this problem because the solution lives in the space between business and IT.

   Once we accept this as at least one of our problems, then we can move from being a soft science to a hard science. This is because complexity is something that can be studied mathematically and methodologies that are rooted in mathematics can be applied.

   This is what I have tried to accomplish with the SIP (Simple Iterative Partitions) methodology, a methodology rooted in the mathematics of set theory, partitioning theory, and equivalence relations. I am not saying that this is the only possible approach to bringing rigor and logic to specific areas within EA, but it is the only one I have seen to date.

   So the question should not be: is EA hard or soft? It should be: how can it be both? Again, speaking from my perspective, SIP and TOGAF are synergistic. SIP deals with problems that are amenable to mathematical and deterministic approaches. TOGAF deals with problems that require intuitive and non-deterministic approaches. This is a largely non-overlapping set of problems and in an ideal world, we will solve the union of both sets.

   1. My own view of EA is somewhat different than yours. I believe that EA needs to focus on the value that it and it alone can deliver.

      Your view seems to be the same as Len’s view called “EITA”. I can see why you would like to stress this view, together with applying the ‘hard’ skills you describe.

      However, as TOGAF describes Business Architecture on the same level next to Data/Information and Technical Architectures, I tend to disagree.

      In my opinion, there is also room for ‘hard’ skills in the development of Business Architectures. Looking at BPM process improvements and enterprise re-organizations, there is room to improve the design of the Business Architecture process.

      Furthermore, I agree with you that there is still a gap between the business and IT sides within the organization. This gap however will not be closed when working from one side only. The role of an Enterprise Architect responsible for both sides equally is the only one which could be capable of closing the gap. That’s mainly the reason why the role of EA is so difficult. And the problem will not diminish by minimizing the scope of responsibility to the level it can be handled easily.

10. IMHO it is in the first place unclear what an enterprise is, more and more business activities are done by coalitions not by single businesses (or enterprises). In the second place IT and infrastructure are just as much business as the more customer- or product-facing parts as clearly stated by Hagel & Singer (in 1999!). In the third place we are talking about an empathy problem between enterprice architecture & business (where empathy is about understanding audiences, including users, customers, and other players in any business ecosystem.)

    I think that the problem of the lack of empathy between enterprice architecture & business can only be solved by putting enterprise architecture inside “the business”.

    1. It may not be clear to you or others but that is a lack of knowledge on your and their part not on it being unclear. 

       An enterprise (in the context of EA) is the organisation plus everything else that provides the context for that organisation. Eg customers, suppliers, partners, regulators, shareholders, governments.

       Architecture is all about structure and proving that structure in the context (structure) of the things it relates to. 

       1. Well, the normal simple definition for enterprise is something like “a unit of economic organization or activity; especially : a business organization” (from Merriam-Webster). So calling me and others who doesn’t know or understand all possible TOGAF or other EA variations ignorant is not very sympathetic.

          So thank you for proving my empathy point so clearly!

    2. I don’t think it matters how we define “enterprise”. I think a definition of “enterprise architecture” that is an expansion of “the architecture of an enterprise” ought to work for any definition of “enterprise”. Lately I have begun to use this as a test for surfacing the underlying assumptions in proposed definitions of enterprise architecture. Too many people have adopted the simplistic convention that “enterprise” is synonymous with “business”, another too-overloaded word that I’m using here in the sense of an organization that engages on the provision of goods and services in exchange for some form of remuneration that covers the costs and risks of doing so. I think instead we ought to think of enterprise in the sense of the definition from the OED that I cited in the original posting. That definition easily encompasses the coalitions that you mention.

       I also call attention to the important point you make about IT being part of “the business”. Another pernicious convention that has taken root is this overly simplistic division of “the enterprise” into IT and “the business”, which has led to the equally pernicious convention that enterprise architecture is the sum of business architecture and IT architecture. This is a subject worthy of not just a blog but an extended essay, and I have spoken about this issue at some length in several of the presentations I have given at The Open Group’s Enterprise Architecture Practitioners Conferences.

       I’ll address your remark about the “lack of empathy between enterprise architecture & business” in my response to another post.

       len.

11. @Peter: “calling me and others who doesn’t know or understand all possible TOGAF or other EA variations ignorant”
    At what point did I say “[people] who doesn’t know or understand all possible TOGAF or other EA variations”

    I was referring to the definition of one word when applied in one context.

    How you extrapolate that to mean “all possible TOGAF or other EA variations ” I have no idea.

    I have noticed this trend before. It is interesting in it’s own right in order to understand people.

    I have noticed it time and time again as a defence mechanism. Person A says something. Person B points out they are wrong. Person A pretends person A said something that person B did not say (and is also totally ludicrous) so that they can then condemn Person B for it even though they did not say it, thereby deflecting the conversation from the salient point.

    Just because something is unclear to one person does not mean it is unclear.

    1. @Kevin There is not one single well-defined EA context but there are multiple (there is a lot of discussion what EA is or should be). Therefore I extrapolated it. And I don’t think that is ludicrous because even TOGAF says (in the executive overview):

       Confusion often arises from the evolving nature of the term “enterprise”.

       And I don’t think they put that line there just for me.

12. Wow, there’s a lot of love here for Len, but where is the constructive criticism? In my opinion, as IT people we are only too quick to get excited when someone says Enterprise Architecture is “about the entire enterprise” and not just about IT. We seem to have an insatiable desire to be more influential in the enterprise than we are currently seen to be. I want to ask why IT people think there are so clever and so full of answers that we think we can ‘architect the entire enterprise’? In my experience, most IT groups within an enterprise are incapable of running their own operations in a cost-effective and effiicent manner, let alone be given the authority to put together the architecture for the rest of the enterprise. Until we get our own house in order, we can’t go telling the marketing people, accounting people, engineering, legal and other people how to run their business! The complaint I hear most often from senior IT people is that their business people don’t see them as strategic. So they end up reporting through the CFO or some other non-core business group. We get lumped in with HR, Finance and Facilities, rather than being seen as a strategic part of the business. I know that is not the case in all organisations, but I would say it is in the majority of cases.

    So, I am going out on a limb here and will say that EA is really about EITA until we demonstrate how we align with the business and how we can be a necessary part of the business strategy. I think it’s time for IT to know its limitations and raise its own level of maturity before we get carried away with ourselves.

    1. Tom has already addressed some of my response to your concerns, but there a few things I want to call attention to.

       It looks to me like you’ve drawn several inferences I did not intend. I said nothing about “IT people”. I said that much of what is today practiced under the rubric of EA is in fact what I think should be called EITA. I left unsaid the fact that there is some EA that is practiced by “non-IT” people (a qualifier I use despite my strong aversion to its implicitly IT-centric frame of reference), and which, as such, is probably not even called EA.

       I certainly did not say or imply that IT people are so clever and so full of answers that they can ‘architect the entire enterprise’, and I don’t believe anything like that. Perhaps I should have been more explicit and added the preface “Regardless of who practices it” to the idea that most of what is called EA ought to be called EITA.

       You write “The complaint I hear most often from senior IT people is that their business people don’t see them as strategic.”, and Peter Bakker notes “the problem of the lack of empathy between enterprise architecture & business”. Maybe a big part of why IT’s practice of EITA under the rubric of EA doesn’t get the respect of “the business” is precisely because it’s misnamed in a way that makes it sound far more important than it actually is?

       So, regarding your desire for constructive criticism, what exactly are your criticisms of the ideas that 1) we ought to name architectures based on what they actually address, and 2) a discipline whose subject has at its core the activities of people probably ought to be considered a “soft” discipline?

       len.

    2. Tim, your comments resonate with me. In fact I am considering re-badging our IT architecture group (which is really EITA) “technology effectiveness” to focus on our key result area: making sure that the business has the right technology to achieve its goals (strategic focus), and that we as IT run that technology as efficiently and effectively as possible (operational focus).

13. @Tim: “as IT people we…” – the point is that some of us aren’t ‘IT-people’! 🙂

    In my experience, yes, a lot of ‘EAs’ will naturally prefer to focus on the practical necessities of IT; but there are also a fair few of us who’ve ended up sort-of in IT less by choice than because that was the only place that architecture-like activity was happening. To those of us in the latter group, Len’s comments above provide a reminder of our real calling here.

    @Tim: “EA is really EITA until…” – yes, agreed. What Open Group describes in TOGAF as ‘EA’ is essentially EITA with just enough ‘real’ EA in its ‘Business Architecture’ section to provide a context for that EITA: it isn’t suitable at present for full-scope EA. (If you want to do pure EITA, I would suggest that you’re almost better off with TOGAF 8.1: a lot of technology-detail was dropped in the transition to TOGAF 9.) And perhaps TOGAF shouldn’t be about full-scope EA as such, given that, as an organisation and standards-body, the Open Group’s explicit emphasis is on IT rather than business-as-a-whole.

    @Tim: “I want to ask why IT people think they … can ‘architect the entire enterprise’?” Strongly agree that if that’s the perception from others, EA would be doomed to fail: in fact EAs need to emphasise, very strongly that we are not ‘IT people’ even if many of us have been hiding out in IT for the past few decades. We’re ‘architecture and strategy people’ who happen to have been IT because that’s where the work has been for the past while: but it’s not necessarily where we naturally belong. Architecture is orthogonal to IT rather than part of it as such.

    Which might seem to throw up a challenge for Open Group itself: if it’s not IT, why should Open Group do any work on it? It’s a valid question, and at first implies that Open Group should focus only on EITA, and ignore the broader EA. To me, though, there are several reasons where Open Group can and should play a major role in describing the broader EA.

    One reason is that Open Group has a lot of experience to share in enterprise-scope architectures. Methods, for example: the ADM needs a few tweaks in its detail to make it usable outside of EITA, but its overall structure and principles of governance, change-management and ‘architecture thinking’ are applicable to any domain-architecture. The TOGAF metamodel is at present still oriented strongly towards IT, but again a few tweaks – already underway in its links with the extended Archimate – would make it more usable in much broader range of domain-scopes. Much the same applies to reference-architectures: the existing TOGAF reference-frameworks may be of limited use even within present-day IT-architectures, but the underlying principles of how to develop a reference-architecture, and how to use it, are applicable anywhere.

    Open Group also has an essential task here in its role as a information-oriented standards-body. There is an increasingly-urgent need for interchange-standards to link across the whole toolset-spectrum for EA, from big-system repository to mid-range analysts’ tools to freeform information-capture and mobile/handheld consumption and feedback. No one vendor straddles that whole spectrum, and the needs and interfaces are so different that it’s unlikely that just one vendor ever will: yet we do need ‘boundaryless information flow’ across the whole of that space. With its long experience in architectures, it’s clear that Open Group is the ideal standards-body to take on this task.

    And from a practical matter of business-politics, doing this gives a real opportunity for Open Group’s members to showcase how IT-derived disciplines are of value to the broader business context – and in doing so, help raise the business credibility of IT in general. Architecture links structure to purpose, providing an explicit bridge between strategy and execution: the details vary, but the discipline itself is the same whether it’s whole-scope EA, IT-oriented EITA, EBA (business-architecture), ESA (security), EHSA (health-and-safety) or whatever. TOGAF at present may be usable only for EITA, yet it can also act as a template for all other kinds of architectures: there’s a real opportunity here for Open Group and its members that should not be missed.

    1. I think this statement from the Wikipedia strategic management page says it all: “Although a sense of direction is important, it can also stifle creativity, especially if it is rigidly enforced. In an uncertain and ambiguous world, fluidity can be more important than a finely tuned strategic compass.”

       Enterprise architects should help to establish the conditions in which business units (or even better: business activity systems) can self-organize themselves. And one of the most needed conditions is the boundaryless information flow (as clearly stated in the book “Power to the Edge”). For the self-organizing process itself something like business model generation is a much more understandable, creative, fluid and therefore better suited process than the rigid TOGAF/ArchiMate combination…

       1. @Tim: “this statement from the Wikipedia strategic management page…” – strongly agree.

          The point with this, though – and likewise with your later comments re Business Model Generation (and its Business Model Canvas) versus the TOGAF/Archimate combination – is that it’s not a simple ‘either/or’, but more like a contextual ‘both/and’.

          Domain-architects typically do one or the other: the fluid, such as implied in Business Model Generation, the classic task of an EBA [enterprise business-architect]; or the defined, such as in IT-oriented TOGAF/Archimate, the classic task of Len’s EITA. An enterprise-architect in Len’s sense must be able to do both. Problems arise when someone applies only one of those modes in a context where they do need to do both: for example, as you say, EITA folks applying “the rigid TOGAF/Archimate combination” to a more fluid business context, or would-be Agile programmers refusing to do any architecture at all.

          At the execution-level – especially for most detail-layer software – a rigid plan is often essential: biological systems are the obvious example of natural fluidity and mutual self-organisation, yet down at the point of contact, those same systems do look and act very much like machines. Most complexity arises from interactions between very simple rules: and those ‘rules’ form a key part of the architecture.

          Understanding those ‘rigid rules’ and the opportunities and risks offered by the interplays between them is where the real work of an architect lies. Sometimes we do need explicit plans – such as for converting a BPMN process-model to a BPEL executable. But at the human level, it’s not so much the plan itself as the disciplined process of planning that’s more important: in effect, a model becomes a record of conversations and decisions rather than a ‘plan’ as such.

          Architecture provides a bridge between strategy and execution, and likewise a bridge between the fluid and the fixed. Tools such as the Business Model Canvas work well at the business-level, yet are actually not well-suited to describe how to implement and execute those business-decisions. The practical problem with the TOGAF/Archimate combination is that its current true/false logic is, as you say, too rigid for many real-world uncertainties (though I know that some of the Archimate crew are looking at how to support ‘MoSCoW’-style modal-logic within Archimate’s inter-entity relationships). Hence we need some kind of method and model-type that makes it possible to link all those different needs together.

          (For an example of the latter, perhaps take a look at my Enterprise Canvas model-type, summarised in the cheat-sheet here and in my book Mapping the Enterprise, which links all the way from above Business Model Canvas to Archimate and below.)

          Domain-architectures such as EITA can usually operate on one or other pole of an either/or. A true EA must be able to handle the cognitive-dissonance of a full both/and. That’s what makes that architecture so challenging; but it’s what makes it so much fun, too. 🙂

14. Pingback: blog.ujuzi.com » On the EA identity crisis ..

15. (Would help if I’d replied to the right person… 🙁 Apologies to Tim, and also to Peter – to whom that reply above should have been addressed…)

    1. @Tom,

       I totally agree with you. And I’m happy you refer to biological systems although I think you reversed the equation “yet down at the point of contact, those same systems do look and act very much like machines” 🙂

       I think we agree that the challenge for EA is not to make the whole system rigid but only those parts (the hubs) which are keeping the system working and allow the rest of the system to self-organize. This should be a win-win situation because EA can focus on the really important parts instead of trying to fix it all…

       (and I used the business model generation method as an example but in the end the self-organizing parts should be able to choose whatever tool/method/language they like and think is best)

16. Very clearly defined Len. Thank you!

    Until EAs get the concept correct, the leaders who would hire us won’t get this.

17. Pingback: Enterprise Architecture – the search for a faster horse? | The Life of a Software Architect

18. Good thoughts Len, though not new at all.

    Check out my presentation at The Open Group India Conference in March 2011. The fundamental messages there are:

    1. Enterprise Architecture is not the same as IT Architecture.
    2. Strategic (Systems) Thinking is an integral part of being an effective architect.
    3. Synthesis takes precedence over analysis, anyday and everyday.
    4. Moving forward, an architects role will not be to design the architecture layers and tiers but to design coherence. In other words, the focus will move from capturing the ‘boxes’ to capturing the ‘arrows’ or the connections.

19. Pingback: Thoughts on Enterprise Architecture - SOA Talk
20. Pingback: Thoughts on Enterprise Architecture | Service Oriented Architecture - SOA
21. Pingback: Tom Graves / Tetradian » What do we mean by ‘business-architecture’?
22. Pingback: What do we mean by ‘business-architecture’? | devblogging.com
23. Pingback: Tom Graves / Tetradian » Is Archimate too IT-centric for enterprise-architecture?
24. Pingback: Government is not a business; FEA can ≠ “EA”. « yetanothereablog

25. Good one. Semantically well structured.

26. Len: You give me hope on Open Group’s EA direction. TOGAF has made a lot of contribution on IT centric EA. However TOGAF is also the rudimentary cause to the confusion of EA and EITA. Your article has clarify my concern. What is the open group plan to steer EA to the right direction. Thanks.

27. Len,
    It was interesting to read your article on Enterprise Architecture. I come out of the world of IT and never liked the term Enterprise Architecture being applied to our work. Indeed it was Enterprise IT Architecture, designed to support the current and anticipated needs of the entire organization.

    I have the same issue with the honesty of the term Business Analyst. A Business Analyst should be just that, a person who analyzes the current state of the business and makes recommendations to the Enterprise Architects about how to adapt / adjust to a changing set of requirements and a changing environment. Instead it is used to refer to those people who have one foot in the IT world and one foot in ‘the business’ and acts as the translator. These are IT Systems Analysts not Business Analysts.

    Through most of your article I could not agree with you more. Then I read the following sentence and could not disagree with you more: “And, for the purpose of enterprise architecture, i.e., to ensure that an enterprise’s assets and capabilities are aligned with its vision, mission and strategy, it isn’t necessary to do so, even if we could.”

    Since I agreed with you so completely during the first segments of your article, I must allow for me not correctly interpreting what you meant by that sentence because it seems to be in opposition to the idea of architecture and design.

    First allow me to say alignment can be designed into an enterprise. In fact I contend that alignment can only be designed into an enterprise, it cannot be managed in. Alignment is one of the outcomes of Business Model Design (BMD) – something I do.

    Allow me to ask you a question. Do you concur that Enterprise Architecture, as with any type of architecture, follows design principles? Perhaps the most basic of all design principles is Form Follows Function. When referring to Enterprises (in the sense we are using it) we have to define what we mean by Form and what we mean by Function.

    Function can be thought of as goals, performance requirements or expectations. In this discussion all three are interchangeable. Vision and Mission are two types of goals. Mission is a shorter-term goal and Vision is long-term. Both Vision and Mission creates performance requirements for the design of the enterprise. They are not the only goals that need to be considered when designing the enterprise.

    Another type of a goal is strategy. Strategies exist for one purpose only – to achieve goals. Inputs to the design of the enterprise (BMD) also include the strategies you wish to be able to execute at some point in the future. I refer to them as Desired Strategies. Those desired strategies must be embedded into the design (architecture) of the enterprise so that they can be executed at the appropriate time. It is important for people to understand that the only strategies that can be executed are those that can be accommodated by the design of the enterprise.

    I mentioned the need to also define Form since Form must be aligned to Function. Any Form (architecture) that cannot produce the Function (performance requirements) is an unacceptable form. The same idea can be applied to a product or process.

    Function aligned to Form (Products/Services, Processes, People and Support). For the sake of brevity I will not expand on the components of Form at this point.

    But I feel compelled to say that in order to execute strategies and in order to execute the business design the enterprise must have certain assets and capabilities. I don’t understand why you would say that aligning them to the enterprise design is not necessary. I would contend that if you don’t you will have waste and inefficiencies.

    I did enjoy your article and thought it to be well written.
    Regards,
    Stan Kirkwood

    1. Stan – we are in complete agreement. Please reread the sentence before the one you have singled out, the one that says:

       “It is simply not possible to specify an enterprise as completely, and to the same level of detail, as it is to specify a building or a locomotive or an airplane.”

       That is what it is not necessary to do, even if we could. It is absolutely necessary to “ensure that an enterprise’s assets and capabilities are aligned with its vision, mission and strategy”, but doing so does not require that the enterprise be specified, as some have said, in “excruciating detail”. The very nature of an enterprise makes it impossible to specify it completely, and even if we could, that specification would be immediately obsolete.

       len.

28. I would agree If the article was written by a strategist, but as usual this is the point of view of an Senior IT professional If I read Its public linkedin profile.
    I would say “But people don’t just interact with an enterprise; in a fundamental sense, they are the enterprise” so Does EA include architecting the work force? Who among us plan (and have the skills ) as an EA to plan incentives, pension plans etc….? Let me give you an hint for companies under M&A: http://www.imaa-institute.org/docs/m&a/towersperrin_01_M&A%20Due%20Diligence%20-%20The%20360-Degree%20View.pdf
    Is Towers Perrin an EA company?

29. Pingback: Tom Graves / Tetradian » On Archimate 2.0
30. Pingback: When You Say “System”, What Do You Mean?

31. First of all i want to thank you for this wonderful article.
    Its great to see we have a place to discuss this very important point.
    In my opinion “EA is mechanic of an organization” who use both soft and hard methods for the fulfillment of the objectives of the enterprise. the ratio of the soft and hard methods may vary as per the time, place,political influence ,product and the size of the industry .and EA is mainly responsible for the
    1. creating base for the organization
    2. dealing with challenges (social, economical,place in the market,environmental etc,)
    3. maintenance & overall functioning of the enterprise.

32. Can you please provide me steps to perform Reverse Engineering on C#.NET code through Enterprise Architect to obtain a class diagram with their Relation ship?

    I Tried obtaining class diagram but Relationship was not maintained.

33. An attention-grabbing dialogue is worth comment. I feel that you need to write more on this topic, it won’t be a taboo topic but typically people are not enough to talk on such topics. To the next. Cheers

34. I just identified your web site on Ask Jeeves, a definitely excellent understand.

Comments are closed.