latoga labs

(Disclaimer: I am currently employed by IONA as a Senior Solutions Consultant. See general disclaimer to the right.)

This past week, IONA announced the acquisition of C24 Technologies out of the United Kingdom. IONA has had a reseller agreement with C24 Technologies for quite some time that matched the strengths of our two companies for the greater benefit of mostly our financial services clients. This acquisition is a great example of complimentary products and people joining forces to provide truly differentiated value.

I have been working with the C24 IO tool (re-branded by IONA as Artix IO) for the past seven months at various Fortune 100 financial firms. IO (Integration Objects) is a data mapping and translation tool that enables model driven data management. Not only does IO come preconfigured with in depth knowledge of standard financial industry message formats, but it provides a graphical data mapping tool for building data translation models, it can convert these models into transformation rules, and generate optimized java code based upon the data mapping models. IO also has the ability to provide constraints to message validations that go beyond what’s available today with XML schemas or XPATH; and these constraints can be applied to any message format. Data models generated with IO currently process trillions of dollars of financial transactions daily around the globe.

Side Box: John Davies, co-founder and CTO for C24, enjoys showing prospective clients how IO can handle the intricacies of complex message schemes like SWIFT, FpML, and ISO 20022 and then providing the test schemas to the client to have them try the same test with the other data mapping tools they are evaluating…he hasn’t come across an instance yet where the other tools didn’t fall over on some part of the schema’s intricacies. After spending over two decades in the financial services industry dealing with these complex message formats, John and the C24 team has ensured that IO can handle the complicated formats that enable electronic banking in today’s world. (John also did an interview with TheServerSide.com on the acquisition.)

To provide some contextual background, IONA’s Artix family of distributed SOA infrastructure products enable true distributes service integration and has been in use for years within both the Financial Services and Telecommunications markets. The entire concept of SOA is about service enabling functionality within your enterprise and making that functionality available to anyone who needs to access it. Any point in your enterprise could directly consume a service within the enterprise to leverage its functionality. Enabling this type of efficient point to point connectivity using standards based message formats and transports is the genesis of the Enterprise Service Bus (ESB) concept. That concept seems to have gotten diluted over the past few years during the conversion of existing applications server stacks into essentially ESB Hubs that all service consumption must pass through. Artix is a truly distributed technology that embraces this ESB concept. (For further discussion on the Stacks versus Distributed concept, see William Henry’s Gravity of the Hubs postings).

By hosting the model generated Java code from IO within the Artix runtime on the distributed services within an enterprise, Financial Service clients gain the combined benefit of efficient distributed services with robust model driven data mapping for financial message formats. This allows a firm to choose the best way to service enable an application based upon the unique technical, business, or political architecture of their organization. And they can do it in the incremental value driven approach that has become the new standard within the maturing technology industry over the past five years.

I am very excited about the joining of IONA and C24. I foresee some exciting case studies coming in the future as we continue to work with our large financial services clients on Artix and IO based solutions; and as the combined team continues to expand IO’s preconfigured message format understanding beyond financial services.

For the past few months, I have been working with two well know Financial Services firms around “SOA” initiatives. I put quotes around SOA because different terms describing services are used in each firm for various reasons (usually politically in nature). At the core, each firm is looking at how to use services to facilitate greater levels of reuse within their development organizations. One interesting fact to note is each firm’s primary driver: one is doing this to reduce the rate of increase in IT spend, the other is hoping to increase the velocity of their application development cycles (shorten the cycles to get products out faster).

One of the most interesting aspects that has come out of this work is the acute awareness of the social aspects of SOA and how important that is for the success of any initiative. (Steve Vinoski has written a wonderful article about the Social Side of Services).

Firm A has invested considerably in socializing the concepts of SOA and reuse through out their organization (up to the highest levels of management). They have a very clear plan on how to implement services across their organization; understanding of new positions that will need to be added to ensure services succeed; functional technical areas that will need to be addressed to enable services; mechanisms to measure the amount of reuse in order to track their progress; programs to educate the developers on services and reuse. All this work was done by the Office of the CTO and took time and effort to put in place, but Firm A realized the need for this and made this investment.

Firm B decided over a year ago that they needed to do SOA based on all the hype in the market place. This decision was made by the business side of the house versus the technology side. Services were soon showing up in project requirements the business side was sending over to the IT Development groups. There was no real centralized planning or coordination with regards to services. Now IT is playing catchup and trying to make sense of all services currently out there. One of the big problems they have is that most of the services that are available are not really reusable by most others, just services internal functionally from applications.

Doing a postmortem on Firm B’s services, you see a number of number of mis-steps that has been taken with their SOA initiative. One issue is the fact that the business side of the house needs to provide functional requirements, not technical requirements. A second, more important, issues is that fact that Firm B totally ignored the social side of SOA…they never took into account the political, organization, and cultural changes that need to be implemented to make SOA really work for them. They never did an analysis of how services could benefit their application environment.

While on paper Firm B has been doing SOA much long than Firm A, Firm A will see value from SOA much sooner than FirmB. In this case, a little investment will go a long way for Firm A.

It’s still amazes me how much technology development or implementation (even at large companies) occurs without taking into consider the social impact of the technology. Even when it’s the social impact of technology on techies (i.e., developers or managers of technology).

I’m curious to hear from others with regards to the social techniques in use within their organizations when it comes to SOA or technology in general…