Hi all, Understanding and implementation is two different things. I'm currently involved in an over 4,400 man month project involving SOA. If you have been involved in any large project, you'll probably know that it is nearly impossible to teach every member on a new topic.
For example, I've also been involved in another large project to convert existing legency system based on COBOL and assembly to Java based object oriented system. Trying to teach every member about objects ended in a failure mainly because of the time limit. In a similar fashion, trying to teach every member on SOA is impractical within a limited time of a single project. What we do if create a set of procedures so the outcome will abide by SOA principles. Furthermore, SOA is not just about IT. To implement concepts of SOA in business is going to require some time. What I mean by SOA should be one of the goals of a EA is that it is possible to start a SOA project without having members know SOA concepts and have them gradually learn SOA as the projects progresses. Cheers, H.Ozawa Jerry Zhu 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 > >
