--- In service-orientated-architecture@yahoogroups.com, "Mark Baker"
<distobj@...> wrote:
>
> On 6/13/07, Steve Jones <jones.steveg@...> wrote:
> > So if the goal is to deliver IT that looks like and operates like
the business then ultimately it must be presented in service specific
ways.
>
> Why is that a goal, nevermind *the* goal? What are the
architectural
> benefits exactly? IMO, the goal should be to deliver a scalable,
> evolvable, extensible system with the right concerns properly
> separated through the principled application of constraints on the
> architectural elements of that system.

Mark/Steve,

let's not forget that the ultimate goal of most businesses is not to
create IT systems.

Leaving aside governmental and charitable organisations, most
businesses are designed simply to return financial benefits (whether
direct or indirect) to their owners, the shareholders.

A company like BP does this through the exploration, refining and
marketing of oil, gas and chemical products. Ford, on the other hand
chooses the manufacture and selling of motor vehicles. Citibank's
approach is to buy and sell financial products. And so on.

Of course the increasing competition resulting from globalised
markets means that today all of these companies *require* appropriate
IT systems to run their businesses. It is simply impractical to
operate such companies in a cost-effective way without a significant
investment in IT systems.

What we need is a way to decide what IT systems need to be built, how
they will interoperate with the other [human] parts of the
organisation and how to evaluate their cost and effectiveness at
supporting the objectives of the business.

In short, the real "system" to be designed is the business itself, of
which IT systems will be a [perhaps significant] part.

This is where thinking about "services" becomes useful.

The language of business design is very much about services, or the
three questions of:

1) What will you do for me (the service)?
2) How will this help my business?
3) How much will it cost?

So, we might have marketing services, finance services, HR services,
manufacturing services and customer support services all making up
our business. In choosing service suppliers, you care only
incidentally (through the SLA) about how the service is implemented.
Instead, services are considered as self-contained "black boxes".

Historically, the language of IT has been all about implementation
platforms and technology, with terms such as the mainframe,
client/server, SQL, Java, WSDL, REST and so on. In the context of
trying to design the [whole] business, this is largely irrelevant.

Now, if we can use the same language to talk about the operation of
the business as well as the IT systems then we are in a much better
position to understand and decide what IT systems are needed to
support the business. We can see immediately how these IT systems
will work with the other parts of the organisation to achieve the
aims of the business. And we can use the same methods for evaluating
the financial cost and benefits as we use elsewhere.

Although this may sound trivial, it is in fact a major step forward.

So what does this mean to the choice of technology implementation
approaches such as WS-Everything or REST? Clearly, WS-Everything is
more obviously oriented around "services", whilst REST is
about "resources". Isn't this a conflict?

Yes and no. This is where I think you need to take a hierarchical
(or fractal) view of the architecture, at least for two levels.

As we have seen, the concept of a "service" is a useful way to
partition the system that is the whole business. A business such as
BP, Ford or Citibank is a massive undertaking so we need some way to
simplify things and get a handle on how to design them.

But once we have broken the business down into "services", each such
service can be viewed as a system in its own right. Because the
services are self-contained, we can take a different implementation
approach to each one. Some might be dealt with by humans and manual
processes. Others might be heavyweight service-oriented IT systems
implemented using Java and WS-Everything. Still others might be way-
cool and resource-oriented IT systems using Ruby and REST.

I think it is a mistake to think that any large organisation can get
away with a single technology implementation approach for services.
In fact, I would go so far as to say that technology diversity is
*necessary* for survival. That is, you *need* both WS-Everything and
REST approaches in your organisation as well as a sprinkling of the
latest technological and product trends. A fractal approach to
service design can help you achieve this whilst controlling and
minimising the risks.

Regards,

-Mike Glendinning.