Re: [service-orientated-architecture] Re: Business Service Architectures

[Keith Harrison-Broninski]

Hi Phil I really like your analysis of the benefits of a goal-oriented approach. I don't share your fear, though.  If anything, I have found over-analysis to be a symptom of lack of goals!  And re optimization, no architect should worry about this.  Do you know Michael Jackson's rules? First Rule of Optimization: Don't do it. Second Rule of Optimization (For experts only): Don't do it yet. :-) You ask for an example.  Here's one from recent experience.  Early this year I did some consultancy for a UK government organization.  In  particular, they wanted to replace their cobbled together systems for monitoring scientific research.  However, as we discovered by applying a goal-oriented approach, the problem was really more general - to relate their activities in this field to the general operations of the agency - i.e., to make better use of the research and analysis work they were doing. This is not the kind of SOA project most of you will be working on, I expect - it's not transactional, for instance.  Why do I give it as an example?  Because what was needed was a set of business services: for finding relevant research, categorizing it, visualizing it, summarizing it, making it available to appropriate people at appropriate times, discovering issues, and so on.  And it is interesting to contrast the approach I took with previous consultancy work they had commissioned. At different times, different people had tackled the problem, and come up with point solutions to various parts - data entry tools, Web sites, Internet search tools, graphical analysis tools, and so on.    The rationale was always to address the points of greatest pain.  And this is what I see people doing with SOA and BPM at the moment - picking the low-hanging fruit, if you like, partly perhaps as a backlash against the failed "obliterate" BPR projects of the 1990s. But this is exactly the wrong approach, in my view.  All you end up with is a mess of disparate systems whose combination often creates new problems - and provides not a truly business-oriented solution, but a technically-oriented implementation. What we did in this case was to try and work out the goals of the different people involved - identify the personas, as you very aptly put it, and their needs.  This gave us a radically different understanding of what was going on.  We started to see how the true requirements for this system were to do with relating research to the "themes" of the agency, automatically identifying relationships between research items, finding "cluster points" that gave clues to possible issues, and so on.  With this in mind, we put together a simple, complete processing pipeline that: Met all needs, from Web crawling through to report production Required only free (mostly open source) tools Could be built incrementally Was low cost, requiring only minor custom programming Had the full support of the users, who couldn't wait to start using it Had the full support of the management, who felt they had taken a lead role in architecting it Exposed all of its functionality at each point, so other agency systems could hook into it as required. The last is the interesting point here, isn't it.  It was an SOA system!  Though none of us, including me, had set out to build one.  What we found was that taking a goal-oriented approach led naturally to SOA. This is why I feel the business viewpoint is so important.  First, it gives you the right scope - holistic, not reductionist.  Second, basing systems on business goals just creates better system designs - and these days, that means applying some form of SOA techniques. -- All the best Keith http://keith.harrison-broninski.info Phil Ayres wrote: Keith, I believe in the concept of business services when trying to take a reasonably well defined process and 'SOA enable' it, as in this example that takes a very process oriented approach. I have to say that I also like your business goals approach, for several reasons: Focuses on the different personas and their objectives, which is essential for real requirements writing and gaining executive buy-in Forces the architect to continue to refer back to the goals throughout the SOA process Provides metrics for assessing up-front, and measuring afterwards, success of the SOA implementation My fear would be that the process starts so high that the architect gets caught up in over-analysis of the problem or becomes overwhelmed with optimizing the solution to meet every goal. Can you relate any experiences where this has worked well (or improved an otherwise failing SOA project)? Cheers Phil __._,_.___ SPONSORED LINKS Computer software Computer aided design software Computer job Soa Service-oriented architecture YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___