Lists Home |
Date Index |
> From: Andrzej Jan Taramina [mailto:firstname.lastname@example.org]
> Sent: Monday, February 18, 2002 2:39 PM
> To: email@example.com
> Subject: [xml-dev] Plumbing versus semantics...
> ...from the current InfoWorld rag, CTO Survival column:
> "Software is an opinion about how a business should run.
> It's expressed
> in code rather than English, but it's an opinion nonetheless.
> So when you
> buy software from multiple vendors [or have different teams develop
> applications independently as is so common in large
> organizations] you're
> buying differing opinions. Interfaces are where they clash.
> To state the
> obvious: technology can't resolve a difference of opinions".
> - Bob Lewis
> He was talking about Web Services not being the magic bullet
> for all EAI
> ills...which most battle-scarred IT veterans already know.
> It would apply
> equally to many XML technologies.
This is straying pretty far off-topic for this list, but I couldn't resist
making one particular comment on this.
I don't disagree with his key points, but he has an oversimplified
perspective on the real sources of integration woes. He almost seems to
suggest that integration woes are really due to buying technologies from
different vendors (which offer "differing opinions" on how to run the
business). If only IT depts. had the budgets to write everthing from
scratch, then these integration problems could be avoided. This is just as
utopian as thinking that web services will solve all of these integration
woes. Yet it seems to be a widely held view that lack of integration in the
enterprise typically stems from technical causes. The real failings
typically have more to do with process and lack of a sound enterprise-wide
The truth is you don't have to look beyond an organization to find
"differing opinions" of how a business should be run. He suggests that
redundant data arises due to pre-packaged solutions wanting to structure
data their own way. However, the truth is even with home-grown systems you
encounter redundant data, and sometimes that is for sound business reasons.
Sometimes the dept. (or other internal organization) served by a system has
a different view of what that data should look like than other groups within
the organization. They view the whole enterprise from the perspective of
their own business function. It is fitting that a system should be tailored
toward the requirements of the group it intends to serve. The failing
typically is understanding where it fits into the larger picture.
The most successful integration efforts proceed from a sound architectural
vision of the whole enterprise -- one that respects the autonomy and
distinct perspectives of individual business units while seeking to
understand where they fit into the larger picture. One interesting effort at
a framework for such undertakings is the Zachman Framework . But few
enterprises approach their IT strategies with such a sound vision. When you
undertake any enterprise-wide integration initiative without such a holistic
vision of the enterprise, you virtually ensure that systems will become
islands. Interfaces clash as soon as automation attempts to cross
organizational boundaries that were not taken into account when the system
was designed. Undertaking cross-enterprise integration efforts without such
a firm enterprise-wide architectural understanding increases risk by a few
orders of magnitude.
With that said, though, I would agree that Web Services (or any othe
technology) will not be a silver bullet. But there will also be those who
will fail to appreciate the value that Web Services do bring, here, because
they attribute their own failings with process and architecture to be
shortcomings of the technologies they use -- just as is the case with OO