Michael, 1) Totally agree. The issue is very serious in the project I am in at present. I have raised SOA serveral times and was told that we can not abandon everyting came of the methodology (waterfall) which I never said to do only model requirements in SOA way. I think that the issue is in the conception in the heads of managers/architects. SOA is an elusive concept and hard to understand to be applicable. I was thinking to organize a SOA study group bottom up depending on my availability.
2)I agree that IT is not a tool (part) but an environment(more than a partner) of a business. It directly affects a firm's operation's cost hence profitability. What I was saying is that it is the business' strategy (what services/products to what customers) that sets the firm's direction not IT. We first had a business strategy and determined how it related to IT. How to implement the strategy? Zachman's view said that architecture is the thing that bridges the strategy to its implementation. It makes sense to me. In the scope of SW project, it is the architecture that bridges requirement to design/implementation. 3)Is SOA right for all businesses of good size? Maybe most but not all. In my view SOA is for process agility - processes of a line of business. One organization has multiple lines of businesses in the same way an human being is a system composed of subsystems (respirtory system, digest system, circulatory system etc). Each sub system has a set of business process types of a category. SOA is at the level of subsystems and EA is at the level of the system (an organism or an enterprise) that considers all subsystems. We are not far part and just adress the issues in different aspects. Best, Jerry --- Michael Poulin <[EMAIL PROTECTED]> wrote: > Hello Jerry, > the discussion gets to certain ground, it is good. > Here are my thoughts on the same 3 points you > address: > > 1) I never blamed developers but rather managers > and architects, i.e. the carriers of organisation > culture and methodology, who got into the world of > IT more and more isolated from actual business > needs. And this is exact issue which SOA tries to > address and fix. > > 2) At this point we clearly going into different > directions. In my view, an EA should not bridge but > rather reflect business in the IT which should be a > part of the business (and SOA is the road to this > 'nirvana'); it should not be a servant but a > partner. At least in financial industry, > middle-to-large financial institutions cannot move a > finger w/o IT and, in many cases, IT Business > Analysts know the business better than business > personnel. Here simply no business if it is not in > the IT. In such environment, profitability of the > business directly depends on how smart IT is, how > quickly it gets technological advantages over > competitors. Well, this may be not the case for > other industries... > > 3) as I said before, I see SOA as a form of > development and maintenance in IT. Does it cover > everything an EA covers now? No, it does not. There > are IT business processes that SOA does not address. > I disagree with the statement that EA addresses the > context of business processes because it is the > business model addresses such context while EA > addresses operational functions in IT in addition to > ones that are not under SOA umbrella (yet). The > whole problem is/was in that EA w/o SOA did not > adequately addressed "all [business] categories and > their relations within the enterprise" from the > business perspectives. > > - Michael > > > Jerry Zhu <[EMAIL PROTECTED]> wrote: > Hello Michael > > I see three things in your message that I answer > one > by one. > > 1. The value of developers' work is not greater > than > paid for. > 2. Better P/L of IT investment is the goal of EA > 3. Relationship between EA and SOA. > > 1. I agree that today's SW cost more than planned > and > are highly defective w/ high failure rate. You > said > the blame is in developers. I disagree. Yes there > is > a difference between good and bad developers but > this > difference is quantitative not qualitative and > does > not change the statistics. I think that the blame > is > in the methodology not people. This can be > evidenced > that SW failure occurs in all organizations of all > sectors. > > 2. I think that EA is the bridge between > (long/mid/short term)Business Strategy (BS) and > its > implementation in the use of IT. Profibility is > the > responsibility of BS not of EA. EA only concerns > how > to implement a BS but can't say anything about > good or > bad BS. > > 3. EA has been around for more than a > decade(Zachman's > paper published in 1987) while SOA as a business > concept is much more recent. Zachman framework > has > been extensively applied in the industry w/o SOA. > SOA > is a way of modeling SW that require the modeling > of > business process in similar way. I agree that the > scope of software using SOA is larger than that of > SW > before SOA but not as large as that of EA. SOA is > about agility of business processes while EA > addresses > the context of business processes. From business > perspective, SOA adresses a category of business > process types while EA addresses all categories > and > their relations within the enterprise. > > Jerry > > --- Michael Poulin <[EMAIL PROTECTED]> wrote: > > > Dear Jerry, > > indeed it is awhile ago I passed Political > Economy > > and Philosophy tests doing my Ph.D. as well as > the > > tests on Sun's Architect certification; thank > you > > for refreshing my memory. > > > > Nevertheless, it is hard to me to find where > my > > feet are. However, I know, more or less, what > is in > > my pocket and I try to fill it faster and in > more > > reliable way. > > > > I guess many developers do not recognize that > the > > majority of their work worth not more than the > > amount of money their employers gain from the > > results of the work. This comes with experience > > (even in post industrial age). So, DB, App. > Servers > > and related Warehouse and multi-tier > architectural > > solutions are good only while they result in > more > > profit or less investments. This is the primary > > goal of Enterprise Architecture (at least, in 5 > > international financial institutions I worked > for). > > > > SOA-RM standard simply says the same as I > said > > above - horizontal conceptualization went too > far > > from the actual business needs and it is time > to > > return EA onto the business alignment rails. It > is > > appeared that to have such alignment the > business > > has to recall and re-use its vertical > > conceptualization. > > > > Is an EA wider than SOA? I would say YES. Does > EA > > make sense w/o SOA? I would say that in many > cases > > NO (though in some - YES). SOA cannot be > "without > > EA" because SOA is the form of the part of EA > which > > serves business (another part of EA serves EA > > itself enabling the first part to serve the > > business). That is, "EA entails a higher level > > abstraction than SOA" does not make sense to > me. > > Sorry. > > > > - Michael > > > > > > > > > > > > > > Jerry Zhu <[EMAIL PROTECTED]> wrote: > > > Michael, > > > > Before DBMS in 1960s-70s, Enterprise > information > > systems was in middle age. As we can buy DBMS > in > > the > > market we entered into industrial age (large > > amount > > labors massed around machines to produce > > standardized > > products - OS, DBMS, network OS etc). This is > the > > result of horrizontal separation of concerns. > > From > > architecture perspective, we have client > server, > > three > > tier to multi-tier etc. > > > === message truncated === ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
