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

[Keith Harrison-Broninski]

Hi Steve The best text I have read on Goal-Oriented Design is Alan Cooper's "The Lunatics Are In Charge Of The Asylum", which I recommend to you.  Cooper's stated focus is user interaction design, but his approach is really a general software design methodology.  And the approach really is all-or-nothing!  If you take silos like Sales or Finance and look for goals inside each one, you will only get departmental aims, even personal ambitions, not true business goals. It is also worth reading Drucker on the definition of a business (actually it's worth reading Drucker on anything, isn't it).  He makes it clear that a business is there for one purpose only - to serve its customers, which first means working out who they are and what they need.  Profit-making and rewarding stakeholders, for example, along with such ancillary functions as reporting, are simply enablers.  And the implementation of these functions, even their presence, is totally dependent on the current nature of the business. I could go on for a long time about these principles, but it's probably better in this forum to refer you to authoritative sources such as the above.  Having said that, if you or anyone else would like to go deeper into these issues here, I am very happy to do so. -- All the best Keith http://keith.harrison-broninski.info Steve Jones wrote: On 10/07/06, Keith Harrison-Broninski <[EMAIL PROTECTED]com> wrote: > > > > > > > > I agree that a more high-level and less technical approach is productive for enterprise architects (who wouldn't). However, as with (for example) user interface design, I think it is more sensible to focus on business goals than business services. > > In the end, the latter are only there to implement the former - you will get a better set of services by thinking first about the business goals they are intended to achieve. I'm not really disagreeing here, but to me the business goals tend to sit in an area. So to find the goals you need the areas, hence the reason why I think that service have a hierachy. I completely agree about using goals as a way to refine services and determine the next level down, I've just found that you can start with the high level blobs (services) first and use them to contain the different goals. As an example Sales & Finance are two services within the business Scenario 1: Sales has a goal of receiving commisions. They realise this by selling stuff Finance has a goal of reducing spend and reporting accuracy. Sales talks to finance to report its sales numbers, their priority on this interaction is the speedy payment of bonuses. Finance's priority is information accuracy. Scenario 2 Sales has a goal of selling stuff (no commision) Finance has a goal of reducing spend and reporting accuracy again Sales talks to Finance to report figures, now however Sales has no real goal assigned to the reporting beyond that assigned by Finance. In scenario 2 there is a reasonable chance that the information latency and accuracy will be an issue, in scenario 1 over-reporting might be the challenge. By understanding the different competing goals you can understand how the services should be developed and driven. So I'd definitely agree, I'd just add services first as the context in which to understand the goals. > > You can find a discussion and example of this approach to SOA in my blog. > -- All the best Keith http://keith.harrison-broninski.info __._,_.___ 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. __,_._,___