The topics you've mentioned isn't because of B-SOA. If the end interface is application specific, it probably because the person who designed an interface actually didn't take SOA governance into account and designed an interface in the old fashion manner for a particular application.
The first step should be to define the goal and to assess the current situation (As-is in EA) which includes the current technology. SOA does not necessary mean developing an new system - it may be more of making better usage of the current resources. :) H.Ozawa --- In [email protected], "Nick Gall" <[EMAIL PROTECTED]> wrote: > > On Mon, Nov 17, 2008 at 7:22 PM, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > Hey? I think I've provided quite a bit.... lets see > > > > * I've written about the method and even contributed it into OASIS (so > > its IP free) > > * Defined the categorisation approach (Heatmap and delivery) > > * Defined how to do business process from a service context > > * Defined how to use UML within a BSA context > > * Defined how to organise teams around the BSA > > > > There are a bunch more things but that is an outline of how BSA goes > > through to delivery. > > > > Out of interest what more linkage would you want? > > Given that Gartner has provided all of the above (with the possible > exception of how to use UML -- haven't needed it) to its clients and still > seen "there's many a slip 'twixt the cup and the lip" from successful > business design to successful technical design (which is my constant refrain > in this discussion), I'd love to see the following: > > 1. Examples of the actual service interfaces that come out at the end of > all the business-analysis falderal. Far too often, I find that the service > interfaces that come out of lots of business analysis are far to > application-specific. The best service interfaces are application > neutral<http://www.gartner.com/DisplayDocument? ref=g_search&id=797713> > . > 2. Examples of the service provider architectures behind the service > interfaces. Again, far too often such architecture is incapable of providing > the continuous availability and other SLAs required by the business. > 3. Examples of the quantitative impact on the business of these > business-driven services. Since they were business-driven from the "top > down", we should expect them to have far more impact that "bottom up" > services, ie services that opportunistically took advantage of innovative > technology, eg Wal-Mart's adoption of AS2 for EDI over the Internet. > > Now that I think of it, having written all this out, what you seem to be > suggesting, Steve, is using classic waterfall methodology for SOA: Do all > the business design completely independently of any technology > considerations (which is why I called it "free floating"), and after all > that design is completely finished, throw it over the technology transom to > the technology troglodytes, with perhaps a tickle of feedback to tweak the > business design to fit the technology. Nice dream. > IME, Waterfall doesn't work in dynamic environments (esp business > environments) whether it's SOA or not. The best approach (here's my refrain > again) is to have the best business designers and technology designs work > jointly in a series of creative > charrettes<http://en.wikipedia.org/wiki/Charrette>at the earliest > stages of design among all the stakeholders to ensure a > truly unified design. > > -- Nick >
