On 06/10/06, Keith Harrison-Broninski <[EMAIL PROTECTED]> wrote: > > > > > > > Eric > > You say that services are more abstract than objects. Yes, exactly! In > other words, they are an abstraction that is further from reality - which is > my whole point. They are so far from business reality that, used as a > high-level modelling technique, they present a serious risk to organizational > health.
Ummm and here I disagree, services are directly the reality of the business, it has "Finance", "Manufacturing", "Sales" even "Servicing" which are all business services that co-operate to deliver the business goals. Whether services are more abstract in terms of the business is an open question, I'd argue that its abstract from an IT perspective but very close to the business perspective. > > As you expected, I fundamentally disagree with you that "that OO analysis > and design is more complex than SO analysis and design". It might be for > programmers, but for business people, OO analysis and design is a lot easier > since it is how they naturally think - about assets, headcount, product > catalog, inventory, customers, and so on. All these are objects, not > functions. Trying to get business people to categorize their world as a > bunch of functions is forcing a square peg into a round hole. Business are organised around their capabilities, and more importantly around the services that provide access to those capabilities. I've not seen a business which is organised around head-count, that is something related to the specific business service and its KPIs. I don't disagree that businesses _can_ think about objects, but that businesses do not operate based on objects but based on collections of capabilities. If you ask the CEO what his business does he will words that describe the "Stuff" that is done, this will tend to have words like "Logistics", "Finance" et al. It won't tend to have the object words as the primary assets. > > I'm not against SOA techniques. What I am suggesting is that there is an > entire layer missing - an OO modelling layer. Unless this is put in place, > SOA will end up like BPR - an approach on which the next generation pours > scorn, wondering how its practitioners can have been so incredibly > short-sighted. SOA should describe the business services that represent "what" the business does. This is where it is different to OO, OO represents the real world "things" where as SOA describes the real world "what we do". They are very complimentary approaches but OO doesn't fit everywhere, BPR was Visual COBOL, so are the latest generation of tools that claim to be SOA but all seem to start with processes. And this is the key point I guess. OO started to win when people realised what it meant, namely it was an approach not a technology, sadly SOA hasn't made it to that level of maturity yet. > -- > > All the best > Keith > > http://keith.harrison-broninski.info > > > > Eric Newcomer wrote: > > Services are more abstract than objects. > ... > > I am not saying objects are bad - I am saying that OO analysis and design is > more complex than SO analysis and design because SO maps more naturally to > the real world. (I imagine Keith would argue with this since one can say > that the world consists of a bunch of things but while that is true it is the > actions that are important to people and business, not the things in and of > themselves - if things don't do anything they are not helpful, but to model a > function it should not be required to figure out what the thing is first just > because you might want to later make an implementation choice for the service > to use OO technology). > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
