A typical Healthcare Information Exchange (HIE) accepts data from an array of disparate sources. Often the data it accepts is semantically and syntactically altered by a providing system to satisfy interfacing requirements. However, there are also cases where data from different sources need to be properly merged before reaching the HIE's interface.
I have been writing over the last month or so about how the adoption of SOA is evolving in organizations and that in most cases tactical deployment is occuring by individual business domain driving the need for a "Right-sized" federated SOA which segments and connects an enterprise architecture through appropriately targeted layers of technology.
Classic architecture considerations never seem to pass up a generation. The classic debate of whether it is better to buy and implement an "all-in-one" SOA stack from one vendor or to embark on a "best-of-breed" strategy where specific vendors and technology are selected for specific capabilities is a regular discussion I find myself particpating in often.
There has been much written and discussed about the technology advantages and business value of multi-core computing. At Oracle Open World last week, Intel's CEO provided several compelling examples of how multi-core computing can improve business outcomes, save dollars, and even potentially save lives.
I went to the InfoWorld SOA Executive forum held in New York this week. The theme of the conference was "Realizing the value of SOA". There were several well delivered presentations on the importance of understanding business process first, organizing the right team skills and structure and picking the right early projects in order to crawl, walk and then run with SOA. Without a disciplined approach focused on these basics any technology selection is doomed to either fai
"Time is money". That old saying is as relevant as ever in the modern financial service markets. Complex, real-time, and algorithmic trading are constantly pushing the envelope of that phase.
In many conversations I participate in regarding Service Oriented Architecture (SOA), part of the conversation oftens leads to "....how best can I incorporate my mainframe in the SOA architecture...". There are a number of mainframe SOA-enabling options, and in this post I will share my opinion on the application of a short-list of tried and true approaches.
Integrating the hot, new SaaS application into a company can often be a challenging undertaking. The SaaS application was acquired for a pressing departmental need, yet manually re-inputting and syncing key data like employee, vendor or supplier master directories is not practical. Manually coordinating a sale by the customer saying "yes" with a win recorded in the sales force automation tool yet hand crafting delivery instructions in the order module of the ERP is not really a sustainable business proc