Internally, we have played with Microsoft Office Business Applications for quite sometime now. But, its very exciting to see industry majors like FedEx experimenting with those ideas.
Fedex has recently launched an application called 'QuickShip' which lets you to execute critical functions like shipping&tracking without leaving Microsoft Outlook. It is basically a Microsoft Outlook add-in that talks to FedEx services. I looked at the demo and I should say it was impressive and exhaustive. It has forms and menus built right into your outlook. Above all, FedEx distributes the app for free!.
Its a paradigm shift where companies are moving away from websites to consumer-side apps. And the next logical step would be composite apps that integrates not just FedEx services but with other external/commercial services as well.
Have a look at a list of other experiments that FedEx is engaged with, in Microsoft Sharepoint / Office areas. In one of the offerings, the FedEx data is integrated with Virtual Earth as well.
I firmly believe that we are few steps away from the tipping point for Composite applications.
Showing posts with label composite applications. Show all posts
Showing posts with label composite applications. Show all posts
Monday, August 18, 2008
Sunday, July 13, 2008
Risks in Composite Applications
Here is my recent experience on Composite Applications. Yes, Composite Applications are cousin brothers of Mashups in Enterprise World! :-). While Mashups are situational apps that are predominantly built using Web Interfaces (SOAP/REST), Composite Applications are custom applications that are defined around existing assets in the enterprise. The assets can belong to any technology and be available in any consumable form, not necessarily in the form of Web Services.
If you google for Composite Applications, You will get different definitions from different vendors each of them woven around their own set of products/technology stack. But, Ultimately they all define the same. These are the applications that are composed to serve the unstructured needs of the customer. For the same reason, you will find Microsoft weaves around Office Business Applications, IBM tells the story around Lotus Notes and SAP has Adobe Forms. And have a look at this Microsoft blog which explains the architectural differences between traditional apps and composite apps.
Of couse, the very idea of 'Composing' apps (and not 'building' apps) looks tempting and interesting!. Of couse, the idea of getting apps to the clients, instead of clients reaching out to apps, looks enriching and rewarding!.
Some of the interesting apps could be - clients accessing a purchase order information from SAP without even leaving his Microsoft Outlook and working through the Order collaboratively with his peers.
But, be warned for the following reasons:
- We are increasing the number of tiers in the application. Two-Tier / Three-tier no longer hold good.
- We are increasing the number of COTS in one vertical slice of the application. Its no longer pure custom app (100% coded). You will have participants from multiple platforms/products/technologies in a single business process.
- Security. The whole game would be easy if all the tiers in the app belong to single vendor/single technology/single OS. The moment where we compose the app out of assets from different participants, the security reconciliation of ID and Roles will be cumbersome!. In my recent experience, I realized that a Security platform, something like TransactionMinder, that would ensure end-to-end security across all tiers will help.
- System Management. If your custom apps have some footprint of desktop elements, then we are going a couple of decades back (unknowingly) in the app architectures. Performance - In Three tier web apps themselves, there is no single product/tool that is available in the market that would give me end-to-end performance of a vertical slice in the app. Imagine the amount of complexity involved in tracking the performance and other SLAs in a multi-tiered composite apps!.
- Last but not the least - the composite apps are pervasive and multi-channel enabled. We need new set of tools and techniques to manage the SLAs across channels for a single business capability that is exposed as composite!.
If you google for Composite Applications, You will get different definitions from different vendors each of them woven around their own set of products/technology stack. But, Ultimately they all define the same. These are the applications that are composed to serve the unstructured needs of the customer. For the same reason, you will find Microsoft weaves around Office Business Applications, IBM tells the story around Lotus Notes and SAP has Adobe Forms. And have a look at this Microsoft blog which explains the architectural differences between traditional apps and composite apps.
Of couse, the very idea of 'Composing' apps (and not 'building' apps) looks tempting and interesting!. Of couse, the idea of getting apps to the clients, instead of clients reaching out to apps, looks enriching and rewarding!.
Some of the interesting apps could be - clients accessing a purchase order information from SAP without even leaving his Microsoft Outlook and working through the Order collaboratively with his peers.
But, be warned for the following reasons:
- We are increasing the number of tiers in the application. Two-Tier / Three-tier no longer hold good.
- We are increasing the number of COTS in one vertical slice of the application. Its no longer pure custom app (100% coded). You will have participants from multiple platforms/products/technologies in a single business process.
- Security. The whole game would be easy if all the tiers in the app belong to single vendor/single technology/single OS. The moment where we compose the app out of assets from different participants, the security reconciliation of ID and Roles will be cumbersome!. In my recent experience, I realized that a Security platform, something like TransactionMinder, that would ensure end-to-end security across all tiers will help.
- System Management. If your custom apps have some footprint of desktop elements, then we are going a couple of decades back (unknowingly) in the app architectures. Performance - In Three tier web apps themselves, there is no single product/tool that is available in the market that would give me end-to-end performance of a vertical slice in the app. Imagine the amount of complexity involved in tracking the performance and other SLAs in a multi-tiered composite apps!.
- Last but not the least - the composite apps are pervasive and multi-channel enabled. We need new set of tools and techniques to manage the SLAs across channels for a single business capability that is exposed as composite!.
Thursday, April 12, 2007
Composite Applications in SaaS
This is an intersting observation.
I was thinking that SaaS always works in a platform based model. There is no client software that needs to be installed/or on-premise software to be purchased.
It is not always be the case. While SFDC provides a platform based SaaS model, there are other vendors who provide other models of SaaS.
For example, the vendor TwinField provides a Microsoft excel based add-on. This add-on needs to be installed on your desktop to perform extensive analysis on the financial data that is maintained by the TwinField services. The add-on interacts with the TwinField Services platform to retrieve the relevant data.
This is basically a hybrid model where you have little bit of on-premise and a lot of platform based services.
And this is absolutely the same architecture model that 'Composite Applications' follow. Its just that the TwinField does not implement this model in a Business Process/Flow context. Otherwise, it is very identical.
What I see is that, its not just the 'Services' that have the potential to be hosted in SaaS platform. Its also the 'Composite Applications' or some elements of 'Composite Applications' can also be hosted in the SaaS platform.
I was thinking that SaaS always works in a platform based model. There is no client software that needs to be installed/or on-premise software to be purchased.
It is not always be the case. While SFDC provides a platform based SaaS model, there are other vendors who provide other models of SaaS.
For example, the vendor TwinField provides a Microsoft excel based add-on. This add-on needs to be installed on your desktop to perform extensive analysis on the financial data that is maintained by the TwinField services. The add-on interacts with the TwinField Services platform to retrieve the relevant data.
This is basically a hybrid model where you have little bit of on-premise and a lot of platform based services.
And this is absolutely the same architecture model that 'Composite Applications' follow. Its just that the TwinField does not implement this model in a Business Process/Flow context. Otherwise, it is very identical.
What I see is that, its not just the 'Services' that have the potential to be hosted in SaaS platform. Its also the 'Composite Applications' or some elements of 'Composite Applications' can also be hosted in the SaaS platform.
Wednesday, January 31, 2007
Composite Applications Complexities
If we carefully observe the current trend, the objective of all the big vendors is to support 'disaggregation' in the name of composite applications.
On one side, in the name of web 2.0, everything is internet enabled. Your Office applications are available on the Web. You get rich user experience using AJAX kind of technologies. In the name of SaaS, the business applications are also exposed as services over the web. This I call it as 'Webifying everything' in your desktop and Access it on the Internet. Access/Interact & Execute everything on the Web. Internet is the Platform.
OK. This is one side of the story. Other side of the story is, to bridge the structured and unstructured world of the enterprise. The structured business process is always available as web application / Portal on the Internet/Intranet. The unstructured communication always happens over a range of tools including your email client, office applications, workflow, etc. all happening right there in your desktop.
So, Do you see a conflict?. One side - One Team is webifying everying saying 'You dont really need to have anything on your desktop except your browser. Other side - Another Team is saying 'Your desktop is reality. It will not go. And Your Internet app is again a majority. And the best practice is to bridge them both effectively, so that the business process gets executed in entirety without any fragmentation/disconnectivity'. This whole paradigm is now packaged as 'composite applications'.
All the IT solutions will inevitably be torn between these two ends.
And the real solution will emerge only if we meticulously analyze the user requirements and choose the best platform / tools to develop the end solution.
Here is a sample:
Now, the important one - Are composite applications portable across platforms?. The real answer is No. IBM is developing its own set of desktop tools/clients using Eclipse platform. Microsoft is having its own office applications. And SAP is building its own set of composite application using its partnerships between Adobe and Microsoft.
If you develop your composite using any one of the platform, Can your end-user / external user having a different client platform really be able to access the composite application?
The summary is the composite applications do not have the same benefits of SOA, just because it is associated with SOA. They have their own complexities and limitations.
On one side, in the name of web 2.0, everything is internet enabled. Your Office applications are available on the Web. You get rich user experience using AJAX kind of technologies. In the name of SaaS, the business applications are also exposed as services over the web. This I call it as 'Webifying everything' in your desktop and Access it on the Internet. Access/Interact & Execute everything on the Web. Internet is the Platform.
OK. This is one side of the story. Other side of the story is, to bridge the structured and unstructured world of the enterprise. The structured business process is always available as web application / Portal on the Internet/Intranet. The unstructured communication always happens over a range of tools including your email client, office applications, workflow, etc. all happening right there in your desktop.
So, Do you see a conflict?. One side - One Team is webifying everying saying 'You dont really need to have anything on your desktop except your browser. Other side - Another Team is saying 'Your desktop is reality. It will not go. And Your Internet app is again a majority. And the best practice is to bridge them both effectively, so that the business process gets executed in entirety without any fragmentation/disconnectivity'. This whole paradigm is now packaged as 'composite applications'.
All the IT solutions will inevitably be torn between these two ends.
And the real solution will emerge only if we meticulously analyze the user requirements and choose the best platform / tools to develop the end solution.
Here is a sample:
Now, the important one - Are composite applications portable across platforms?. The real answer is No. IBM is developing its own set of desktop tools/clients using Eclipse platform. Microsoft is having its own office applications. And SAP is building its own set of composite application using its partnerships between Adobe and Microsoft.
If you develop your composite using any one of the platform, Can your end-user / external user having a different client platform really be able to access the composite application?
The summary is the composite applications do not have the same benefits of SOA, just because it is associated with SOA. They have their own complexities and limitations.
Subscribe to:
Posts (Atom)