Keith Harrison-Broninski will probably disagree on this one. He
just posted his last entry in his current series on SOA:
http://www.ebizq.net/blogs/it_directions/archives/2007/02/
taming_the_mino.php
He states:
A cornerstone of my argument is that an organization cannot be
properly understood by talking only about the services it provides,
either internally or externally. Rather, an organization can only be
understood as a network of interacting objects. Contrary to what you
might expect, it is IT people who seem to be insisting on the
simplistic service-based approach, and business people who naturally
see the world as a system of "things" and relationships between them.
This is really an interesting area of discussion, and one that
there's no right or wrong answer. Ultimately, we're trying to apply
some form of classification or organization to the business. There
are hundreds of ways of slicing and dicing it up, however, and the
"right" way depends on what you're actually trying to gain by the
classification. It's clear looking at any organizational chart that
business people don't always see the world as a system of "things"
and relationships. Organization charts tend to be grouped by
function: Staffing, Sales & Marketing, etc. Even if there is a top-
level breakout according to "things", the functional aspects are
frequently broken out at the next layer. Using financial services
for example, there may be divisions by product types, such as Equity,
Fixed Income, Insurance, etc., but then within those you see the same
functional areas. Where these functions are placed is more of a
question of centralization versus decentralization based upon the
corporate objectives. So, one could argue that from an
organizational perspective, a functional, or service based view makes
a lot of sense. Given that services are intended to represent
independently managed items (it's all about ownership), this approach
seems to be a great fit. Unfortunately, this can lead to a path of
redundancy. A resource-oriented view will likely lead to less
redundancy, however, who owns it? This is not to say that this view
isn't important, it's important for different reasons and objectives
than a service-oriented view. In designing solutions, ultimately
both will be important.
I'm not going to speak for Keith, but in the rest of his article, he
doesn't state that a "thing" based approach is the right way to go,
either. As I read it, he is advocating an approach that incorporates
multiple views, including processes, goals, automation, and
services. That's my oversimplification, he provides a lot more depth
in his article.
-tb
On Feb 8, 2007, at 7:44 AM, Eric Newcomer wrote:
I think what Steve said in the previous post is very important. To
gain the benefit of service orientation it's important to design
and model software systems in terms of functions (services) rather
than things (objects) since functions are more naturally aligned
with "what we do" as people and businesses.
Given the service abstraction, implementation is a separate issue.
As we have heard many times on this list a wide variety of
technologies can be used for implementation. The most important
thing is to get the design right - meaning to meet the business
requirements, to align with the services that the business provides
for its customers, or other departments.
Eric
----- Original Message ----
From: Mark Baker <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, February 8, 2007 7:58:18 AM
Subject: Re: [service-orientated-architecture] Booch on SOA &
Architecture
On 2/8/07, Dan Creswell <[EMAIL PROTECTED] org> wrote:
> Hmmm,
>
> "Obviously someone who can't give up objects in favor of services"
>
> Someone thinking in objects has serious wrong-thinking in terms of
> design full stop!
RESTful design is largely object-oriented, and I've had no trouble
designing very large scale systems using it. REST was at one time
called the "HTTP Object Model", in fact.
It's also why I've continued to use "distobj" as my email address.
Mark.
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbake r.ca
Coactus; Web-inspired integration strategies http://www.coactus. com
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
