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.
>
> Currently we are in the early stage of
> transformation
> from industrial age to post industrial age as we
> begin
> to reconceptualize the world. One of the new
> concetuplization is separation of concerns that is
> vertical rather than horrizontal. This is a hard
> transition simply because most of us have both
> feet
> still in the world of industrial age.
>
> The most important change today is in the way we
> try
> to understand the world, and in our conception of
> this nature. If our view of the world is out of
> date,
> our behavior they drive will be out of date.
>
> Best
>
> Jerry
>
> --- Michael Poulin <[EMAIL PROTECTED]> wrote:
>
> > Well, well, this starts to look like a driver
> > without car...
> > - Michael
> >
> > Jerry Zhu <[EMAIL PROTECTED]> wrote:
>
> > Robin
> >
> > Agree with what you said.
> >
> > EA is the thing that bridges business strategy
> > (present and future states and steps from here
> to
> > there) to its implementation. It's enterprise
> > wide in
> > scope.
> >
> > SOA is in the scope of lines of business and
> > concerns
> > business agility - one set of sub
> architectures
> > (we
> > call it sub because it is the architecture of
> > lines of
> > business) among many for EA.
> >
> > EA entails a higher level abstraction than SOA
> and
> > yields the understanding of SOA.
> >
> > Jerry
> >
> > --- Robin <[EMAIL PROTECTED]> wrote:
> >
> > > Well well, I think that SOA without EA is
> like
> > > driving a car without a
> > > clear destination. You may enjoy the ride
> of
> > course
> > > and I bet lots of
> > > people on this list do ;-)
> > > I think EA should indicate the target
> > architecture
> > > supporting the
> > > business strategy and vision. SOA is then a
> mean
> > to
> > > reach this target
> > > enterprise architecture and not a goal on
> its
> > own.
> > > Robin
> > >
> > > --- In
> > >
> [email protected],
> > > Michael Poulin
> > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I am afraid that SO{alphabet}A will
> > destroy
> > > the concept and
> > > allow a "flavor" of SOA for compromising the
> SOA
> > > principles on the
> > > ground that in a SOxyzA they are not
> needed.
> > > >
> > > > I am working primarily with
> financial
> > Web
> > > sites and, in
> > > particular, with Web interfaces for internal
> and
> > > external users.
> > > According to Adrian's logic, I have to say
> that
> > I
> > > deal with SOBIA
> > > where BI stands for Business Interface.
> > > >
> > > > However, on the basis of `plain'
> SOA, I
> > was
> > > able to explain
> > > my business clients that the Web site
> represents
> > an
> > > aggregation of
> > > business services that join its business
> > interfaces
> > > for business
> > > collaborative tasks and that Web page flow
> > simply
> > > reflects the flow
> > > of business units of work mixed with the
> User
> > > Experience aspects, and
> > > that an interaction between Web sites is
> nothing
> > > more than a business
> > > process. This allowed me to re-model the Web
> > > interface design as a
> > > design of collaboration of business
> interfaces
> > > sitting on the top of
> > > business services currently represented by
> web
> > > applications (that will
> > > be replaces by SOA services in close
> future).
> > As a
>
=== message truncated ===
__________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news
---------------------------------
8:00? 8:25? 8:40? Find a flick in no time
with theYahoo! Search movie showtime shortcut.
