<<The migration to SOA of the large packaged applications such as ERP
has begun but is an evolutionary process that will take many years
(glacial speeds). The guts of large ERP systems are not service oriented
and the internal mechanisms being put into place to create service
interfaces are band-aids at best. These packages are not being rewritten
from the ground up, nor am I suggesting that they should. I believe that
would be too disruptive to the application software market. These apps
are just too big, too complex with huge install bases that have massive
customizations to worry about.
Worse yet, for smaller niche, industry specific applications - like
health care where we desperately need better integration - there is much
less progress towards service orientation. These vendors have less
competition, less revenue, lower R&D spends and are less sophisticated
technically than the larger vendors.
Consider also that we, IT that is, mostly buy applications versus
building them. So our application vendors have a huge impact to our SOA
plans. I was speaking to a user group recently and told them it is
wishful thinking to believe that IT and architects can greatly sway an
ERP decision based on the packages service orientation. However, I do
think that SOA can have an impact on application software purchases if
approach properly and here's how.
First, ask open end questions about SOA and standards during the RFP
process such as "Describe your company's comment to SOA" and "What is
product XYZ's SOA roadmap" and "Describe how your application APIs
support industry standards such as Web Services, JMS and REST" and
"Describe your support for industry standard data formats and semantics
within your external interfaces like HL7, SWIFT, (insert your format)"
and "Can major business processes be externalized using an orchestration
engine such as (insert your most important ones) and "Are the following
functions available as business services (insert your most important
ones)".
Next, you will want to see demos and potentially a proof-of-concept
around your integration, presentation and orchestration requirements.
Now that you have data, how can you actually impact the business
decision of which package to purchase - after all the business should
buy the package with the best functional fit? You have to prove to the
business that SOA matters in this decision - if it in fact does.
SOA for integration can greatly reduce packaged application integration
- what are your integration requirements and what are the cost
differences between packages? The business will understand cost savings.
Also, SOA can greatly impact customization costs by creating external
business processes that orchestrate business services. This impacts
cost, feature fit, and process flexibility.
So the applications SOA direction does matter. You have to prove it down
to individual business services, business processes, costs and ROI. But
it can and should be part of the exercise. And it's better to be part of
the process than just getting an application thrown over the wall at you
to implement and integrate.>>
You can find this blog at:
http://it.toolbox.com/blogs/the-soa-blog/buying-service-oriented-application-systems-31007
Gervas
