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)
It has come to my attention that there are really two kinds of SOA technology
vendors out there, old school and new school - each offering very different
approaches to solving the SOA problem. I'm not going to mention any
particular vendors, but you guys can guess who they are.
Keep in mind, what's important here is that not any particular approach or
technology is correct, but that the approaches and technologies you employ
match up with your requirements and business expectations. However, it's also
important to understand exactly the type of technology you're going to
So, what do AJAX and SOA have in common? The answer: Everything.
Is AJAX an enterprise technology? The answer: Absolutely.
As we move to next-generation enterprise architectures using newer notions
such as Service Oriented Architecture (SOA), there's a need for a dynamic Web
interface that can layer over services and provide more value to the
enterprise. Moreover, the enterprise in general can benefit from the
advantages of AJAX; it's just a matter of making enterprise developers as
well as the SOA architects aware of AJAX.
AJAX is becoming the standard dynamic interface for the W... (more)
As we build services/APIs for use within the enterprise or cloud computing,
there seem to be two clear trends for those who are consuming the
services/APIs: they want to leverage APIs that drive social networking, such
as Twitter and Facebook, and they want to leverage complex,
business-oriented, and high-value APIs that they don't want to build
APIs around social networking are easy to define and leverage. They have
simplistic data structures and well-defined methods. While they are
simplistic to use and understand, they also have huge value for both the
Many organizations out there don't really have to sell SOA. They understand
that hype is the driver, and, in essence, leverage the thousands of articles
and books on the topic to sell this architectural pattern.
However, in most cases SOA has to be sold in the enterprise. If you're doing
SOA right, you'll find that the cost quickly goes well into the millions, so
you'll need executive approval for that kind of spending. However, the
benefits are there as well, including the core benefit of agility that could
save the company many times the cost of building a SOA. Or, at least, tha... (more)