[
Lists Home |
Date Index |
Thread Index
]
By the time an RFP is issued, the guessing had better
be done and the bets made.
I worded the question deliberately to see how different
people would approach the problem. I said, "an
enterprise of a **type**".
1. One might assume that the 'type' determines services
that this enterprise offers beyond the common business
sets, say spec'd by something like ebXML. One would
want to understand that type very well and stay away
from types one doesn't understand (start ups have a
definite chicken and egg problem although the fact
that many XML committees are staffed by smaller firms
or industry outsiders gives them an opportunity if
a thin one).
2. Given an RFP, as I said, the first thing I would
do is look around for any specification citations and
hardware or software required or optioned. That scopes
the technology options.
3. If this is an RFP (Request for Proposal) and not
an RFI (Request for Information), I would assume the
consultancy period is over. I don't get to argue the
customer out of things, but I can say no or suggest
alternatives. RFPs are typically coded for such
responses. Important: the more I argue with the
customer about what is good for the web, whether or
not a vendor of a particular system is evil, or anything
other than answering the specific requirements, the more
likely I am to lose. Keep technical politics out of
Proposals and on Blogs where they belong. If I
try to argue REST vs SOAP, I won't make the downselect.
One has to either be prepared to say 'no bid', or
implement one or either. One may get a bid that
says 'service-oriented architecture is desirable'
and that is all.
Now one has to make a bet because dollars to donuts,
the customer doesn't know what that is, and possibly,
one's opinion of what that is varies from one's competitor's
and perhaps one's core technology vendor's. I am willing
to bet a beer that if we ask on this and a few other
lists 'what is a service oriented architecture' we
would get some surprisingly variable answers that
make different cases for the values of different
technologies for loose coupling, HTTP vs Everything Else,
identity authentication, orchestration vs choreography,
transaction recovery, and so on.
How many would actually take the time to compose a
service set standard for the enterprise type?
The answer Chris gives describes the technologies he
would implement. Unless that conflicts with what
is found in item 2, he is ok but just starting.
Now one has to determine which of the functions
this enterprise type performs are suitable for
web services, and which aren't. What are the
criteria?
As one can see from item three, the battle of
the web services is not fought by the vendors of
the core technologies. They are just the arms
dealers and map makers. It is fought in the middle
tier vendors who are often selling to small to
middle sized businesses for whom ROI has to be
fairly immediate and where for the implementor,
the profit margins for the jobs are thin and
costs are fixed once bid.
Probable result: commitment to a core tech vendor
production system for creating service sets for
enterprises of a given type. Otherwise, one won't
be able to compete against IBM. Didier says one
shouldn't be dependent on a particular vendor, but
for jobs of this size, one will want to be. The
job is not done by a single developer but teams.
Managing multiple developers each of whom
has a different technical religion will result
in failure to meet schedule, budget, and requirements.
Particularly in the battle for web services, one
will want to provide as turnkey a solution as
possible or else the implementation costs will
consume all of the profit. No free lunch.
BTW: the battle is not over the content
type standards. These have to be free and reliably
implemented by the time the RFP is issued. It
is **precisely** over capturing the business logic.
Why did Bill Gates suddenly embrace open standards
and open source? Because in a services-oriented
architecture for a typed business, the implementation
technology should not make any difference to the
services the system can perform. If it does, the
technologies are NOT standard and the customer is
right back to buying from the vendor with the most
complete system. No change. In other words, web
services are NOT a killer app, and do not puncture
the equilibrium. They open up communications and
enable enterprises to interoperate. That's all.
The value is still in the business logic and it
is even more locked behind the firewall than ever
before.
len
|
