On July 21st at 10am (ET) John Wilmes, our Chief Technical Architect for the Communications sector, will be speaking along with John Reilly, the TM Forum’s Senior Program Manager for the Information Framework, on a the Information Framework (SID).

You can register here

Everytime I attend one of the webinars that John Wilmes does with the Forum, I’m always impressed by the TM Forum’s completeness of thought. Unlike a lot of other industry and architectural frameworks out there – the Forum didn’t focus on just part of the puzzle.  What was understood, and what the Solution Frameworks (NGOSS) highlight, is that business transformation requires addressing elements that live both within and between business process, information models, logical applications and technical architecture. Part of the joy of hearing John talk about the SID is to hear again how the data, process and applications all interrelate to each other.

For those of you who might be new to the TM Forum – or even those of you who are looking for a solid conceptual framework for thinking about transformation problems - in addition to this webinar there have also been several other webinars from the Forum that John has done over the years, including:

• What is NGOSS and What Can it Do for You: If you’re looking for a great introduction to the Solution Frameworks
• NGOSS Contracts: The Key to Improved Interoperability:How Business Services (NGOSS Contracts) can improve interoperability across multiple business silos / stovepipes
• SOA and NGOSS Contracts: A Practical Approach to Integration: How SOA and the frameworks fit together

For an alternate, non-telco examples of a similarly complete framework that spans process, data and applications—there was also the recent webinar by Boris Bulanov and Frank Neugabauer about the Insurance industry’s approach to transformation the ACORD Framework. Many of the concepts are similar and it's another proof point that one must consider the whole problem and all its requirements when initiating an integration or transformation project.

Open Source SOA has arrived! On a single day we have one platform announce that they have simplified basic SOA, and another has announced that SOA is never simple - and if it is simple, just use web services. The question is... is there really a simple SOA and a not-so-simple SOA?

As I look at it, there is a very fine line between simple SOA and the more complex ones that require an enterprise service bus (ESB). Lines are blurred today. Now, ESB itself can be in a single container or more massively distributed ESBs with a strong messaging backbone (like Sonic ESB). But messaging backbone or not is more about the underlying integration infrastructure. So, what does it mean for the application itself? Is the model/paradigm different for the two cases? This is what gets lost out in the melee - the application models and the underlying infrastructure are quite decoupled. From an application standpoint many of the ESB mediation requirements may always be needed functionally. Can one access services without getting the data in the right format? To get it in the right format, won't we need data transformation? And security is a given in all cases. Sometimes one can look at business rules based routing to services. All of these regardless of whether it is a simple SOA or not-so-simple (more distributed multi-data-center) SOA. 

This (common treatment of all SOA use cases regardless of complexity) is very evident with the way our open source platform, FUSE, works because it has an embeddable transport layer. One could use the containers with or without Active MQ. But with or without distribution, the same functionality is available. Simple SOA? Or not?

In the last few weeks/months I have got more immersed in the world of REST and what it means to build and have a REST application.  While at first glance it may seem that REST is a lighter weight version of a web-service implementation, it is by no means the complete answer and I do not believe REST is simply a replacement of Web Services because of how they operate is different.

When developing Object applications, in whatever language, you hit a reality that if your application is successful, then it will grow beyond the confines of the machine/JMV that it runs on, and as such you have to refer to objects that are beyond a single instance of the application's memory space.  This can be done using a number of different technologies such as object databases that can map the same object into different application instances, but the locks are maintained by the central server so consistency of the objects are maintained, even if the object is distributed in 100s of applications at a time.

Now technologies such as IIOP (Corba), RMI, DCOM and Web Services have been used to access objects and invoke operations on the instances to retrieve data.  This essentially solves the long-wire problem of accessing an object and then returning an instance of the object, the issue here being is that typically a representation of the object that you want is returned, i.e. using Java serialization or XML and the reference to the actual instance is lost, unless you have a known object identity that you are working with.

REST adds the concept of the pointer to the SOA infrastructure in a way that any business object can be referenced by a URL and thus referenced anywhere within the internet/cloud or a single program space. This is something that is not readily available in Web Services and now makes any RESTful resource available to anyone (given the correct permissions).  Now this sparks a whole debate on to how to identity a particular object and to detect duplicates etc, this is beyond the scope of this blog but will have the same techniques that are used in the object-oriented world, but now working at the cloud scale.

So now that REST gives us some new capabilities, how does this change the current implementations that you are working on?  Interestingly, I think many of the challenges existing in the Web Services world still need to be addressed in the REST world, I just believe that REST is probably better able to address some of the immediate ones and in fact just like every Progress customer has another application to connect to Web Services will always be required.

The other cool thing about REST is that I can typically use the services directly from an HTML page on a browser, something that was impossible for Web Services because HTML and WSDL are not compatible.  However, there is still the need to mediate REST in the same way that applied to Web-Services, for instance to be able to turn a switch to expose the same business entity as REST and Web-Service and in fact any possible protocol.  Allowing external access to your business objects will require caching and a level of indirection to provide for maintenance, performance, etc., and the virtualization of the underlying technology to ensure that an object is not a manifestation of the technology that stores it, i.e. database tables and rows are not part of the object serialization.  Security, Quality of Service (QoS) and Quality of Protection (QoP) are observed along with SLA commitments and the ability to monetize the object and charge accordingly.  This last point maybe very interesting as it would allow organizations to potentially charge for access to their data for different reasons and allow IT to start to become a profit-center rather than just a cost-center - something that I think people will look at as they invest in the cloud.

Now I think that the promise of REST is very interesting, in more ways than Web Services was, but whether the ideal is purely based around REST or a hybrid of many technologies is going to depend on the goal of what is to be achieved. In any event, it is very exciting.

A busy day in the rapidly converging SOA and Cloud worlds. Oracle talks about plans for the cloud, retracting from the skepticism expressed some months back. Intuit announces a PaaS platform. Another SOA infrastructure vendor dabbles with SOA on the cloud - striking dichotomy here. On one hand we are still trying to figure out how exactly to make SOA projects successful. And on the other, we are talking about SOA in the Cloud and PaaS platforms for SOA. Even so, I find it a natural progression.

PaaS, and therefrom the SOA impact, follows the success of SaaS. Which itself was the best thing to happen to ISVs in recent times. A combination of emerging application models, web based software UI approaches, new cloud platforms, and a very wide acceptance of externally hosted software solutions - less of technology and more of mindset. Now it is only a logical extension of the SaaS paradigm that now one will expect to build custom solutions on the web (PaaS). Or host solutions directly on the web based infrastructure (Cloud). And the moment there are applications, SOA cannot be far behind. The nature of the cloud beast is also such that the significance of SOA and distributed management/governance becomes even more critical given the rather loosely coupled and a less-controlled computing environment.

So while enterprises may be OK with having solutions hosted externally on the web/cloud, they may still want the integrated enterprise where these external solutions are seamlessly available in the enterprise integration platform (SOA) and also in the enterprise distributed management and governance platform. We can probably extend these to bring the external apps into the prevailing GRC and BAM framework in the enterprise, so it is only natural that SOA becomes a first class consideration when SaaS/PaaS/Cloud are in the picture.

Not far will be the support for SOA as a primary attribute of cloud platforms. Right off the bat one will have the ability to build and host applications over the web, with the default web based UI models and a very integration ready platform - both for consuming/orchestrating services over the web, and also to expose new services (off this application) over the web.

Now... taking this a bit further, one could look at explicit platforms just FOR integration and SOA!  Even now there are BPM vendors like Cordys that are providing a web based orchestration platforms (PaaS). These can easily be extended to offer a complete services and integration-application platform on the cloud. Only, we need to figure out the use cases where one needs integration off the cloud. Needing SOA as a Service (SOAaaS).

Congratulations are in order for our hard working data services and engineering teams. Progress was recently awarded two ACORD Accomplishment Awards for our work with the insurance standards organization, ACORD.

We won an Innovative Implementation Award for the Progress DataXtend Browsers for ACORD, in P&C and Life flavors. These browsers will enable ACORD members to more easily use and understand the existing ACORD standards for P&C and Life.   We also won an Early Adopter Award for our work supporting the unambiguous mappings between the existing ACORD XML standards and the new ACORD Information Model. 

If you’d like a seven minute summary, you should watch our interview with Frank Neugebauer, the Assistant VP of Technology at ACORD. John Petrie, Bill Gino and Boris Bulanov discuss with Frank our work with the Browsers and the Information Model. While the interview is a great summary, I'm sure that many of you would like to learn more about the new ACORD Framework, its core components and the business value it offers. 

At 3:00pm ET on June 25th Frank Neugebauer of ACORD and Boris Bulanov gave a webinar on ACORD Information model. An archive of the event will be posted here.  It’s a great opportunity to join your colleagues to learn more about the ACORD Framework and how the ACORD Information Model provides the foundation for information architecture in insurance.

When I got to the gate, the gate agent was calling out my name.  United's not my regular airline so I didn't have any special status that would get me upgraded automatically or anything like that.  So, when the gate agent calls your name in this situation, you usually think "uh oh". I went up to the gate to find out what was up.  Here's what they told me:  They said that the flight to San Francisco might leave late due to delays in San Francisco so my connection would be tight.  So, just to make sure, on the spot they re-booked me through Los Angeles on flights that left and arrived at around the same time as my original itinerary.

The last 15 years I've been Platinum or higher on multiple airlines - but this was the first time an airline had ever been this proactive.  As soon as I was re-booked, I checked and there was no delay listed for the San Francisco flight yet nor did the FAA show any general delays for San Francisco.  I was pretty impressed and am a very happy customer. I will also try to fly with them more in future (now if they'd only put electrical outlets in coach - but that's another story).

How does this translate to the IT world?  If you can anticipate or detect problems before your business users are even aware of them you, will become a hero.  Some people want to hide issues from their users, but don't be afraid to let your business users know there's an issue. If you are taking actions to address the issue, and the users see that, they will gain trust in you.

A question that often runs through people's minds when they think of this is, will your users think you're not on the ball if this happens too often (is it better to only react to the really bad issues proactively)? Would I have gotten mad at United if the original flight wasn't actually delayed?  Not at all.  The fact that they were thinking ahead was what mattered to me. 

Users don't expect perfection - they expect (and respect) honesty, empathy, responsiveness.  Give them that and they will be with you for the long haul.

Was visiting a customer in Switzerland last week and a funny thing happened.

They presented us with where they are in their deployment... they've deployed their first "major" application early last year (Inventory Management), and this year are planning two more applications in the suite to be deployed in 2010 (E-Ticketing & Centralized Checking-in).

They're using a very old version of Actional (v6x), and I was hoping to help them understand why it was important to upgrade to the current release (v8.0). The Inventory Management application contains about 300 applications (including TIBCO BusinessWorks and Oracle/BEA WebLogic Server), and is designed for 400 million messages per month. They're currently doing about half that. (It was really cool to see the Actional console with those sorts of numbers in the dashboards!!!)

Each of the new applications will probably add a similar amount of traffic. 1.2 Billion messages per month. Surely, there's my in.

I started talking about how we've made major improvements to auditing performance, user-interface usability in large scale environments, and CPU and memory utilization, along with general performance improvements you'd expect in two years of development. I was sure this was a certain driver for them to upgrade to a recent version, when the lead architect from Progress leaned over, and whispered in my ear...

The current architecture's not even breathing hard. Even with that traffic growth, we'd probably only be at 30-40% of design capacity.

What can I say? We have a really fantastic engineering team.

And, I'll have to work with the customer on building a business case for upgrading using a different angle.