Gervas Douglas
2013-01-16 12:56:18 UTC
*<<If SOA is back, as many have been arguing in recent months, then it's
different now -- it comes with more flexibility and choice than before
and it's not just the preserve of the big corporate; this time around
it's not one size fits all, but it's for everyone.*
Let's take a concrete, real-world example, which we come across all the
time. If you're working in a small IT department that finds it has to
integrate its back-end systems to Salesforce.com., what are your options
to put that integration in place in a standard-based, service-oriented way?
First, there's the question of what you use to build the integration.
Most people in order to implement SOA have some form of ESB from one of
the big vendors at a cost of hundreds of thousands of dollars. They
might only be connecting to Salesforce.com to their SAP back-end, a
simple problem that they don't really need a whole ESB to solve, but
that's what they end up with.
The alternative is to have the developers write a point-to-point
integration, but that's what we are trying to get away from in building
a service-oriented architecture in the first place.
But rather than implementing a full ESB SOA, something that is clearly a
sledgehammer to crack a nut, why not contain that within an adapter? Or,
to pick up on an analogy I have used many times, why not piece together
your SOA out of the specific building blocks that you need, at a
particular time, and in the way you want them delivered?
If you're building a simple Salesforce integration, you can pick up the
blocks that work with your back-end system such as SAP, and those that
work with Salesforce and plug them together to make a connection. You
still have all the benefits of SOA -- the reuse, the service orientation
and the open standards -- but without the cost and hassle traditionally
associated with architecting and maintaining an SOA.
Second, alongside what you run, there's the question of where you run
it. If you don't want a big monolithic system running on-premise,
there's the further option that you can federate it out to the edge of
the network and run it in the cloud.
Then it becomes a question of building that cloud-to-cloud integration
in a way that doesn't leave you open to changes in the cloud vendor's
service and how that is exposed.
Cloud vendors, such as Saleforce.com, are all pushing their own APIs and
in recent years have been continually updating their API, in contrast to
the more traditional vendors like SAP whose interfaces are more static.
Changes in APIs are coming thick and fast, almost too much to keep up
with, and they're also exposing their applications in different ways
with different types of APIs for different purposes.
For the business manager that just wants to get at a specific piece of
information in a database or expose a particular piece of functionality,
this rapidly changing landscape of APIs can seem quite daunting. Speak
to IT and you will find a developer eager, as developers are, to write a
piece of code that does exactly that piece of integration -- but it does
only that, and may not be adequately supported as the developer moves on
to the next project.
What the business is looking for is a packaged solution that's supported
no matter what changes occur at either end. This is where the adapter
framework hosted within the cloud comes in -- it just works and
continues to be supported, and the organisation's IT department is
shielded from the complexity and the shifting sands of API management.
Finally, just as the model of what you use and where it sits is
changing, so is the model of how you acquire the service -- and again
this is now designed to provide more choice to the customer.
It's similar to how you buy a mobile phone. You might want a pay as you
go service, where you just pay for what you use, or you might want to go
on a contract, which specifies how many minutes, how many text messages
and much data you have, then if you want extra minutes, text or data you
can buy it.
Similarly with the integration frameworks, you can buy the pieces you
need right now and buy more as you go along, or you can sign up to a
subscription model and build it out as you need it.
This really plays to the realities of customer choice: some people want
to buy the least expensive integration available that does the job;
others want to buy the most high performing integration engine. It's not
just about providing a cheaper alternative to building the entire SOA
stack, this is about providing more flexible ways of building it so you
can modify, add and scale depending on what the budget allows or the
business demands.
It's SOA's "Martini" moment: Integration you can have Any-time,
Any-place, Anywhere.>>
*You can find this at:
http://www.businesscomputingworld.co.uk/soas-martini-moment-anytime-any-place-anywhere/
*
*Gervas*
different now -- it comes with more flexibility and choice than before
and it's not just the preserve of the big corporate; this time around
it's not one size fits all, but it's for everyone.*
Let's take a concrete, real-world example, which we come across all the
time. If you're working in a small IT department that finds it has to
integrate its back-end systems to Salesforce.com., what are your options
to put that integration in place in a standard-based, service-oriented way?
First, there's the question of what you use to build the integration.
Most people in order to implement SOA have some form of ESB from one of
the big vendors at a cost of hundreds of thousands of dollars. They
might only be connecting to Salesforce.com to their SAP back-end, a
simple problem that they don't really need a whole ESB to solve, but
that's what they end up with.
The alternative is to have the developers write a point-to-point
integration, but that's what we are trying to get away from in building
a service-oriented architecture in the first place.
But rather than implementing a full ESB SOA, something that is clearly a
sledgehammer to crack a nut, why not contain that within an adapter? Or,
to pick up on an analogy I have used many times, why not piece together
your SOA out of the specific building blocks that you need, at a
particular time, and in the way you want them delivered?
If you're building a simple Salesforce integration, you can pick up the
blocks that work with your back-end system such as SAP, and those that
work with Salesforce and plug them together to make a connection. You
still have all the benefits of SOA -- the reuse, the service orientation
and the open standards -- but without the cost and hassle traditionally
associated with architecting and maintaining an SOA.
Second, alongside what you run, there's the question of where you run
it. If you don't want a big monolithic system running on-premise,
there's the further option that you can federate it out to the edge of
the network and run it in the cloud.
Then it becomes a question of building that cloud-to-cloud integration
in a way that doesn't leave you open to changes in the cloud vendor's
service and how that is exposed.
Cloud vendors, such as Saleforce.com, are all pushing their own APIs and
in recent years have been continually updating their API, in contrast to
the more traditional vendors like SAP whose interfaces are more static.
Changes in APIs are coming thick and fast, almost too much to keep up
with, and they're also exposing their applications in different ways
with different types of APIs for different purposes.
For the business manager that just wants to get at a specific piece of
information in a database or expose a particular piece of functionality,
this rapidly changing landscape of APIs can seem quite daunting. Speak
to IT and you will find a developer eager, as developers are, to write a
piece of code that does exactly that piece of integration -- but it does
only that, and may not be adequately supported as the developer moves on
to the next project.
What the business is looking for is a packaged solution that's supported
no matter what changes occur at either end. This is where the adapter
framework hosted within the cloud comes in -- it just works and
continues to be supported, and the organisation's IT department is
shielded from the complexity and the shifting sands of API management.
Finally, just as the model of what you use and where it sits is
changing, so is the model of how you acquire the service -- and again
this is now designed to provide more choice to the customer.
It's similar to how you buy a mobile phone. You might want a pay as you
go service, where you just pay for what you use, or you might want to go
on a contract, which specifies how many minutes, how many text messages
and much data you have, then if you want extra minutes, text or data you
can buy it.
Similarly with the integration frameworks, you can buy the pieces you
need right now and buy more as you go along, or you can sign up to a
subscription model and build it out as you need it.
This really plays to the realities of customer choice: some people want
to buy the least expensive integration available that does the job;
others want to buy the most high performing integration engine. It's not
just about providing a cheaper alternative to building the entire SOA
stack, this is about providing more flexible ways of building it so you
can modify, add and scale depending on what the budget allows or the
business demands.
It's SOA's "Martini" moment: Integration you can have Any-time,
Any-place, Anywhere.>>
*You can find this at:
http://www.businesscomputingworld.co.uk/soas-martini-moment-anytime-any-place-anywhere/
*
*Gervas*