--- In [email protected], "htshozawa" <htshoz...@...> wrote: > > I think the MUST is coming here because the processes and services > weren't designed and implemented so they were flexible enough.
SOA/SO isn't about processes. It is about services. > If the processes are services are inflexible, there is a need to > start at the enterprise level because they can't be changed so > much. But isn't this defeating the purpose of SOA? > > We can apply SO principles to EA, but is this what we really want? > Wasn't SOA a solution to avoid all those failed EA initiatives and > projects because EA is actually very difficult to execute mainly > because of internal political reasons? With the tight economy, I > think it's going to get more difficult to start an EA initiative. No, SOA was never intended as a replacement/substitute for EA. It is a style of architecture. Initially, Gartner described it as a style of application architecture. Many have found SO principles are a good fit for other architecture levels, including EA and BA. If one is applying SO principles to enterprise-scope planning activities (architecture is a planning exercise) then one is "doing" EA, regardless of style. > I think the tools are getting much better, and it's getting to the > point of proper using them. I agree that if tools can't be properly > used, it's probably better to revert back to the test proven EA > because we at least know that works if it can be executed. What do you consider to be "test proven EA?" -Rob
