First a general point. I write to this list as a private individual so will not point to specific company references that I have done with my employer.
2008/11/18 Nick Gall <[EMAIL PROTECTED]>: > 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) Gartner did not provide the content for the approach that I wrote about, it might have happened in line but it is not the same stuff. Out of interest what are Gartner's clients using for software design? > 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: > > 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 . I agree, which is exactly the reason to have a clear business service architecture as it helps restructure the application into its constituent services at the start of the programme which is exactly what stops the interfaces being a "lipstick on the pig" after thought. Oddly I can't just publish client interfaces on this forum. A traditional application approach with technical services is what leads to application centric interfaces, or can you explain how it doesn't? > 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. I just do not see this. I see scalability issues where people build big applications and then lob Web Services et al on top as an after thought thus disconnecting the external SLAs from the internal structure of the application. The systems I've personally worked on always had tight requirements around this sort of thing (find something that needs to be more available than Air Traffic Control). Services add a complexity in network effects but they also enable you to implement advanced approaches such as graceful degradation which isn't possible in an application centric model. > 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"), Yes, HUGE fan of Waterfall I am, always pushing it. Of course there is the alternate view... > 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. First off I AM a technology troglodyte, its what makes me good at doing Business Architecture. I've said a huge number of times that the key skill is knowing the technology but not exposing it to the business until its genuinely applicable. Secondly I created the method originally on technical delivery projects because we didn't have a way (Use Cases aren't it) of outlining the solution to clients and the organising the teams so they matched the solution. > 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 at the earliest stages of design > among all the stakeholders to ensure a truly unified design. And tell me Nick, how do you get those people working together? The answer is of course that you need to split down the problem quickly in order to have your co-operating teams. You can't do this by having 20 business people, 20 programme managers, 20 architects, 40 analysts and 100 developers all in a room. So what you need to do is quickly sketch out the business services (from experience we are talking about 4 weeks or less) so you understand the overall problem context then assign people to those different services (and establish an integration and technology team to work on the platform) these individual teams then work on the detail around the service. A normal approach is to define the service interfaces early to help drive the independence of the teams (Mythical Man Month on communication challenges in large teams). This sort of approach then gives you a series of small teams working within constrained environments. This of course means that you are much better able to hit the Agile sweetspot. So in fact a business service approach actually helps companies that are currently using Waterfall to switch to Iterative/Agile approach (I posted a couple of years ago how this can work) by making the "Waterfall" projects short (after all if you do 18 x 1 month "waterfall" iterations then its at least iterative). It also helps companies to understand where different approaches are required. Waterfall works (IME) in exactly one place... Vanilla Package implementation with a business change programme, Agile tends (again IME) to kill package delivery. So a business service approach quickly helps to split these areas so you can do the package delivery from the development extensions (e.g. what goes in Fusion Middleware over Oracle package). Steve > -- Nick > >
