Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search

View all Portals

Scheduled Events
Archived Events

White Paper Library
Research Papers

View Job Listings
Post a job


DM Review Home
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

Buyer's Guide
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

About Us
Press Releases
Advertising/Media Kit
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Enterprise Architecture the Holistic View:
In an SOA Universe, How Important is Platform Selection?

online columnist JP Morgenthal     Column published in DMReview.com
July 21, 2005
  By JP Morgenthal

Application platform selection is still one of the remaining vestiges of unpredictability in a market that is becoming more and more predictable by the day. For some, application platform selection is a completely emotional choice, while for others it is pure logic. For some, application platform selection is made, or ratified, by the CIO or other senior IT executive, while for others it is made by the developers.

However, with the market leaning toward achieving interoperability of applications through service-oriented architecture (SOA), two questions should immediately rise to the surface. The first question should be, "If I use SOA the underlying platform that a service is running on should be totally transparent to me, so why should I care about application platform selection any longer?" The second question should be, "What is the impact on SOA on the application platform selection I've already made?"

Starting with the first question first, the consumer of a service should not care about the application platform that the service is running on, however, you as the service provider is responsible for the availability, maintenance and management of that service. Hence, for you, platform selection is as important and valid of a question as ever. The application platform you select for development and deployment of your services will have significant impact on your ability to deliver continuous service.

All SOA does is amplify the role of IT in the organization. IT has always had to ensure availability of the mission-critical applications, but when one application is down, most often times, all the other applications are still running. Hence, unless you are Comair in the middle of Christmas rush, chances are that a downed application will not lead to significant repercussions should failure occur.

With SOA, this attitude will not suffice. As your organization deploys more services and those services become sub-components of new business processes or other services, a downed service could impact thousands of applications simultaneously - certainly this will have significant repercussions and will be definitely noticed. With SOA, IT becomes and internal utility company, same as the electric company, water company and telephone company. If any of these utilities' services are unavailable for any reason, a large number of people will notice rather quickly and respond negatively.

For this reason, SOA must be taken seriously by your organization and, thus, so must your application platform selection. It is this author's opinion that application platform selection be made by the CIO or similarly responsible senior IT executive with input from the development staff. Today, there are effectively two application platform choices you will be making for the delivery of services: J2EE (or as it will be known in the future Java Enterprise Edition) or Microsoft .NET.

Your developer staff will have a lot to say about this choice. Be sure there are zealots on both sides. Some of their points are valid and needs to be evaluated by business, such as we have more Microsoft certified developers than Java developers. Your choice of platform should reflect your ability to support that platform and develop services on top of it. Additional factors that need to be taken into consideration with this decision include:

  • Who are the vendors that you will partner with to provide this platform? Typical answers include IBM, BEA and Sun on the Java side or Microsoft on the .NET side. Another alternative is also not to select a vendor, but instead use open source software, which typically means you're selecting Java.
  • What is the cost of managing and scaling the platform? If you review past experience, and there is lots of engineering error embedded in this point, but Java EE platforms have not scaled as promised for many companies. These companies are now in the process of reworking applications to make them scale. Part of this is due to the server requirements for Java EE. .NET, on the other hand, is still rather immature, but builds on many of the platform scaling and management techniques for Windows server. If you've been successful in scaling your Windows server environment, chances are you will be successful scaling your .NET application environment.

As for the second question we posed at the start of this article, "What impact will SOA have one the platform selection I've made already?" SOA is moving processing closer to the data and will require more fine-grained levels of management. Application platform selection is not a right or wrong decision; although vendors, pundits and zealots would have you believe it is. The application platform selection decision needs to be based solidly on business requirements.

Let's say you've selected Java EE as your application platform (I'm using Java EE here only as an example and I am not stating opinion on its strength or weakness as an application platform). Does the Java EE server you've selected integrate tightly with network management consoles from Tivoli, BMC or HP to manage the services deployed? If not, then perhaps you've made a good application platform choice but have not selected a particularly good implementation. As you move to SOA, you may want to review the vendor decision you made and not the platform decision.

However, if you've selected Java EE as your application platform and your application is now suffering performance degradation as you grow your business, and your systems administrators have no idea how to identify the problems, then chances are that it will not support your needs as you move to SOA. At this point, the best thing to do is bring in a team of experts that can help you identify the bottlenecks and identify the process and costs for removing them. Chances are, if Java EE will not support your needs, perhaps you need a more lightweight Java option, such as an enterprise service bus (ESB).

It is the rare case that an organization needs to switch their application platform completely from Java to .NET or vice verse. In those cases where it has occurred has it had more to do with pricing incentives and support from vendors than being driven by actual technical requirements. Again, since I believe that business needs to drive this selection, this is a fine reason to switch, as long as the longer-term needs of the SOA can be met by the application platform choice.

I've stated it a couple of times throughout this article, but will repeat it here at the conclusion, business requirements needs to drive the application platform selection. The introduction of SOA only makes the demands on that platform to be highly available and scalable more important. Available resources for development and management need to be factored into the equation, and should be on the list of business requirements, but developer preferences should not be on this list. To answer the question posed in the title of the article, in an SOA universe, application platform selection is critical.


For more information on related topics visit the following related portals...
Enterprise Achitecture and Service-Oriented Architecture (SOA).

JP Morgenthal is managing partner for Avorcor, an IT consultancy that focuses on integration and legacy modernization. He is also author of Enterprise Information Integration: A Pragmatic Approach. Questions or comments regarding this article can be directed to JP via e-mail at morgenthaljp@avorcor.com. Do you have and idea for a future Enterprise Architecture column? Send it to JP; and if it is used, you will win a free copy of his book.

E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2006 DM Review and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.