When looking at technology buying patterns in the world of SOA, there's one
common thread. The Global 2000, and many government agencies, are purchasing
from their existing vendors, no matter what the needs or requirements. I call
these solutions purchasing "comfort technologies" since they consider the
relationship with the vendor more than the value of the technology itself.
It's comforting to deal with the same company, people, and platform.
Moreover, many of these same companies working with "comfort technologies"
are also allowing the vendors to design and define their solution. I call
these vendor-driven architectures or VDAs but they are always called a bad
idea if you understand the core issues. What's most disturbing is that this
seems to be an emerging buying pattern. Architects are making the "SOA deal"
with a vendor in hopes some magical technology emerge... (more)
Last month I wrote about vendor-driven architectures (VDA), and I had a few
vendors ask me to look on the other side of the fence. In essence, to
consider how vendors can better address the needs of the customer,
considering the new drivers with SOA.
Truth be told, I can't believe the unsophisticated approaches many vendors
have when selling their product. Indeed, I'm taken aback weekly by a vendor
pitch that just does not flatter their technology, perhaps even making them
take a few steps back in my book, and perhaps in the opinions of their
Core to this is the fact... (more)
A few people who have been reading my blog and this column, and listening to
my podcast, as well as reading other SOA blogs and articles, have become a
bit confused pertaining to the notions of:
SOA Reference Model(s) SOA Reference Architecture(s) And how all of this
works and plays with Enterprise Architecture I spent a few hours of my
weekend attempting to research and define these concepts a bit better, in
essence, taking everyone's opinions and normalizing them so they make better
sense. What I found were many of the same notions, defined differently, but
all attempting to s... (more)
Architectures are like archaeology; in essence, layers upon layers of
systems, applications, databases, and connections, typically built or
procured to solve a tactical problem.
Many corporations talk a good game and brag about the strategic long-term
direction of the enterprise architecture that serves the business. The fact
is, tactical needs have trumped strategic direction over the years. Thus,
layers upon layers of technology on top of technology are the end result, and
an architecture that is inflexible, static, fragile, and thus difficult to
change along with the business... (more)
Dave talks about Sun's very weak movement back into cloud computing, and the
death of Sun Grid Proto Cloud.