Friday, November 2, 2007

Enterprise Applications

I really enjoyed this post and as an importantly, all of the replies to it.

Khoi Vinh, posted

If it looks Like a Cow, Swims like a Dolphin and Quacks Like a Duck, it must be Enterprise Software..

It really does show just how many companies are struggling with their enterprise applications and of course cannot just get rid of them (else they wouldn't be struggling, right?). I am absolutely not convinced that even the new applications we are building are not going to fall into the same traps, because alarmingly, there are not many answers to this problem, even with hindsight!

As you know, I am a big advocate of enabling agile and flexible API’s into Enterprise Applications. You can do so much more once these API’s exist. Of course, if the Enterprise Application doesn’t have an API or the right one for you, you can use OpenSpan to provide it. Using OpenSpan to enable your application to be customizable too is pretty cool, even if I do say so myself!

Anyway, enjoy this post and the great replies, it speaks for itself, IMHO. (Yes I’ve replied a couple of times as well).

Wednesday, September 26, 2007

Agile SOA - without the wait

Create Web Services by wrapping legacy applications - now that's agile

You have a workflow that involves 2 legacy (10 year old) windows applications (say written in VB and C++), a legacy web application (say 2 years old with embedded DHTML and Ajax), a packaged Java application and an SAAS application like salesforce.com. This workflow (transaction) is carried out 10’s of thousands of times every day by hundreds of users.

How quickly would you expect to build a service around some or all of this process? 1 year, 3 years, 5 years, 10 years perhaps?

Assuming you can persuade your SAAS and packaged application vendors to do their share in your timeframe, there is still no telling really how long this will take. All of the business logic needs to be replicated, that so far took thousands of man years to develop and assuming you actually know where to find it! In the mean time of course, your business user requirements around improving and extending this workflow are not standing still. Indeed they must not stand still in today’s competitive environment.

What if you could wrap these existing applications and workflows, and have your SOA that way? What if you could taking any of your (or your vendors) existing web services (if they exist yet) and have them participate immediately in these workflows without waiting the 1, 3, 5, or 10 years? You wouldn't even need to understand your existing business logic because it would automatically get carried forward in the wrapping.

At OpenSpan, we believe in SOA but we believe it should not take away the critical importance of remaining Agile. This applies to remaining Agile around the deployment of SOA as you build it out as well as being agile around changing business requirements. If you build a web service, your existing applications should be able to consume it right now (see Last Mile of SOA).

A successful SOA strategy will be an Agile SOA strategy. IT and Business both win with this approach. IT get to work on their long term SOA strategy yet remain the superstars for introducing SOA immediately, and whilst continuing to deliver on the ever changing real-world business needs.

Wednesday, September 5, 2007

If only all PC applications were Open

They can be.

For quite some time, Salesforce.com has had some really good integration with Microsoft Outlook. I love the fact that whilst in Outlook, I can click a button that pushes the email or the contact information into the relevant contact in salesforce.com. A way cool benefit to me as a business user. There are other vendor applications that have some cool close ties with Outlook and other Office components but compared to the number of applications out there, there are relatively few that integrate so closely.

So, it begs the question, why are so few applications tightly coupled like this?. Why should integration only be limited to those vendors that chose to tie their solutions to other vendors product, like Microsoft Office. If only any application could be tied to Outlook in the same way, even if the original developers didn’t build that functionality into their application.

OpenSpan can take virtually any application and enable this cool plug-in capability with Office, even if you don’t own the application or have any source code. With OpenSpan’s ability to rapidly give applications an API where one previously didn’t exist, existing applications extensibility takes on a new lease on life!

In fact, you are not limited to just Microsoft Office either! Ever wanted to integrate one of your applications to Google Office? Now you can and you don’t have to be a hard core developer to do it!

There are a lot of things you can do, now there are ways to give existing applications virtually instant API’s.

Thursday, August 23, 2007

The Next New thing – that’s the problem!

I am confident I have found a Holy Grail. The root cause of most project failures and the main ingredient for the mess we have, and continue to have around Enterprise Applications and Integration. Scarily, I also think new projects, and even SOA are likely to suffer from the same root cause and will NOT be the panacea everyone hoped for. We are seeing evidence of that now. I see no big fix on the Horizon either, for future projects in IT and the types of problems we have today, will be the same problems we’ll have 10 years from now! Am I sticking my neck out here?

When I look back, since I started in IT 30 years ago, there has always been the “next new thing” in technology. This fact is not disputed but the penny dropped for me last year when I thought about the relationship to this fact when you add one other major ingredient – PEOPLE.

Is it not true that most people working in technology and especially in some form of development, only want to be working on the next “new thing”? Is it not also true, these same people get bored really quickly with the “new thing”, often before it even gets “old”.

Smart people in technology get bored at around the 18 month marker and want to be working on the next “new thing”. This is my Holy Grail and I am not sure that it’s ever going to be fixable. At least acknowledging this fact should allow us to prepare for it!

18 months is not long enough for most projects, not even close and if the smart people who started them are not around for the completion, testing, roll-out and continued evolution of the applications, it is no wonder the expectations are rarely met.

You can certainly do no wrong by breaking down projects into smaller pieces where feasible. This will help and that’s certainly a prospect of SOA, if done right. For Quick wins, look to smaller projects and products that can consume these “new” services from existing applications!

This Holy Grail is good for companies like mine, that will help the tens of thousands of companies that have hundreds of thousands of applications that need to be enhanced to do more now than what was originally delivered. The fact OpenSpan can take 25 year old and 1 week old applications/technologies and tie them together to deliver what users need today, goes a long way to allowing the “Next New Thing” projects to finally exceed original expectations.

Thursday, August 16, 2007

SOA Failures

My thoughts around SOA is for the Rich man, not the poor man is panning out after I found a link to an Article by Gartner (thanks to Tekrati) confirming such. This is a scary (but realistic) outlook and why companies should be looking to complimentary alternatives whilst on this path to SOA Nirvana!

"Gartner predicts that by 2010, less than 25 percent of large companies will have the sufficient technical and organisational skills necessary to deliver enterprise wide SOA"....

Why SOA deployments fail

SOA is the right road, just that it's a very long road and also not the only road. Bear that in mind when you are trying to solve business problems, Right Now!

Wednesday, August 15, 2007

The Last Mile of SOA.. What's that?

Have a web service you want to write or someone else's you'd like to consume? Say an address validation web service, a trouble ticketing log web service, a web service that monitors and records information into your analytical systems or even a simple web service that creates a shipping record into one of the main shipping company systems.

All very well and good but how the heck do you consume a web service when it's likely going to involve some heavy lifting development effort to get it into your existing applications (assuming too, you own those systems)?

What we call the last mile of SOA, really means integrating web services RIGHT NOW. Since OpenSpan inserts itself into running desktop applications, it can intercept what a user does, what data is where and even what the application does with that data. Armed with all that information (and no coding), OpenSpan allows even complex Web Services to be integrated with that information, based upon any event or trigger from the user, you define. Until Legacy systems go away (never), this approach is one of the most immediate and agile approaches to integrating web services and legacy systems. Real-time desktop application integration has come of age.

As you will read (see news), our new partnership with Aspect Software, enables their customers to interact with the Aspect Web Services, Right Now, without ripping out the back end, which would normally take years and large development efforts.

The last mile of SOA may seem like a strange term to describe some of what we do, but it's as good as any... and it works..

Monday, August 13, 2007

Fix what we already have - AGAIN

Airtran cancelled a flight for me and my family getting ready to go on a vacation because at the last minute, a first officer was a no show. The plane was there but no first officer. Fair enough, this stuff happens.

Rebooking 200 people on other flights was bad enough although they did use technology to do this. The slow and sad part involved manual integration - 2 men and 2 phones. 1 person at the gate, reading out bag tag numbers to someone on the tarmac was approximately 5 minutes per passenger.

So, in the end, Airtran couldn't transfer people to new flights fast enough because they overlooked this manual process that would not be so difficult actually to automate.

So, before you look to sweat the big back end integration projects, look to sort out the little stuff first! You'll be surprised at the customer / end user / business satisfaction rates going up.