Service-Oriented Architecture

Most well established large organizations suffer from some level of "Web sprawl." It organically grows for the same reasons as a disparate systems environment:

• Mergers and acquisitions
• Legacy architecture now deprecated
• Tactical solutions circumventing architectural goals
• Disparate IT skill sets
• Lack of architecture steering
• COTS package purchases provide heterogeneous platforms and functional overlaps
• No centralized IT, i.e., different IT organizations across business units

The list could continue. By the same token the enterprise architecture team is tasked with reigning in Web sprawl and stemming its propagation.

Fighting Web sprawl within a large organization is an uphill battle. Experiencing this on a daily basis has shown me that there are some things you can do to help alleviate the issues. It is popular (and rightly so) to have a target unified portal framework somewhere along its migratory path in your organization. This is important, but you also want to ensure that it is applied against Web enablement requirements as they raise themselves. What is required is a means to describe how to classify the context of a requirement's solution.

What Are Architecture Patterns?
The architecture patterns described herein demonstrate an approach to Web enablement of legacy systems and a catalog of options. They are deliberately more iconic in nature, and provide a simple way to communicate an idea to both IT and the business.

When published in an appropriate manner they allow the "requirements front door" (e.g., business analysts) to select from a catalog of choices for Web enablement.

A solution can reside between the options presented and can also mix and match approaches.

There are further design patterns applicable within any one of the architecture patterns shown. The catalog serves as a generic overview of the highest-level choices to be made.

It is imperative to the success of this approach that the use of the patterns is added to the IT delivery processes. This will allow the centralizing of exceptions and the creation of new patterns over time to meet changing needs. Also, not least it will give a better understanding of the candidate solution, hence better effort planning and estimating.

The Misunderstood Single Sign-On
If I had a dollar for every time I was asked to build a single sign-on (SSO) interface to an existing Web application, I'd be a..., well I'd have enough at least for a trip to my favorite restaurant.

It is one of those perfect cases of the old saying "when you have a hammer, everything looks like a nail." Indeed, any of the patterns presented later may require an SSO interface with some external resource or EIS. However this is only part of the solution, and getting the architecture right can greatly simplify the task of unifying the corporate web. While providing a consistent SSO solution is important, so is business process alignment, corporate branding, consistent user journey, data consolidation, usage and marketing reports, etc.

All too often requirements will arrive at IT saying something like "provide single sign-on to <legacy> application." Ideally the requirement should have been a functional set of requirements (which can point out "by the way <legacy> application is already performing this today"). It should then be an enterprise architecture decision as to whether to:

• Indeed keep the existing legacy application and perform SSO from the strategic portal, but also to consider alternatives such as:
  - Refactor all or part of the legacy application to the target architecture
  - Replace all or part of the legacy application with a target strategic application
  - Migrate the legacy users to an existing strategic application (may involve improvements to support gap analysis from legacy requirements)

Enterprise architects have the job of evangelizing the target architecture and often reasons are found to circumvent this (budget, IT skills, time-to-market, etc.). One of the few times when architecture should be able to be influenced more easily is incrementally "while the hood is up." Requirements of the form described above often hide the underlying business needs that are trying to be met.

Catalog of Web Integration Options
What can we do as enterprise architects and IT professionals? Well we cannot be everywhere at once, particularly in a large organization. The creation, presentation, and prominent publication of a set of Web integration options presented as architectural patterns will help to classify your Web enablement solutions. It will have a number of positive effects:

• Business analysts can correctly align solutions, which helps the evolution to your target portal architecture
• Using the correct pattern can help point out the key benefits and hence help the business case for more strategy-based solutions rather than always the tactical
• Many metrics of the solution are easier to establish given the right classification (such as complexity, budget, effort, expected ROI)
• In time the business itself will start to put requirements in the right solution context before IT are even involved

The patterns for Web enablement will vary from organization to organization and can depend on many factors such as: the availability of COTS packages in your industry, the size of your company, the amount of deprecated legacy, the technical architecture of the strategic portal environment, etc. It is important to create the feasible set that represents your organization along with an understanding of the architectural order of preference (and the business factors that might push a solution down the preference list).

The catalog list presented below illustrates some of the key approaches to Web enablement in a large company:

• Standardized Portlet (Figure 1)
• Remote Portlet (Figure 2)
• Composite Portal Application (Figure 3)
• Web Clipped Portlet (Figure 4)
• Direct Content Encapsulation
• Separate Browser Launch (Figure 5)

As stated earlier, remember we can mix and match across these patterns to define a candidate solution context.

1.  Standardized Portlets (Web Parts)
Problem
Vendors often want to provide both the process logic and the presentation tier of an application but customers have heterogeneous portal environments and this only propagates problem.

Solution
In many large organizations a buy vs build approach is often taken, particularly when the functionality is not a core competency of the business (i.e., systems such as billing, CRM, product catalog, etc.). Just because we have an ideal architectural solution in mind we cannot ignore this fact. We also don't want to reinvent the wheel if a COTS package already provides the necessary presentation-level functionality.

A standardized deployment architecture is provided for Web application vendors to develop upon. Usually the provider of the EIS also provides the standardized portlet/s, but not always. The Web application is deployed locally into the customer's native portal framework. Although largely dependent on the vendor's implementation, the system's being Web enabled acts as a black box to the portal.

Application vendors now only need to support this one standard and can market their applications to any compliant server environment. The solution is close to out-of-the-box and usually requires only deployment and configuration with little-to-no development necessary. Also the consuming portal avoids the need for custom integration code to be built.

Applicability

• The COTS vendor provides all the necessary functionality required (or the ability within their Web framework to create it)
• The processes involved do not generally span other systems or functionally overlap, and there is no strong requirement for interportlet communications
• The internal processes of the solution application are not reused elsewhere

Example Known Uses
JSR 168 offers a standard for J2EE portlets to allow deployment of COTS portlets into any compliant application server (BEA, IBM, etc.).

Custom Web Parts and Sharepoint Services offer a consistent framework to extend the Microsoft Sharepoint Portal Server environment.

2.  Remote Portlet (Web Parts)
Problem
Vendors and third parties not only require developing their own presentation tier as in #1, but they also only wish to allow deployment within their own application server environment.

Solution
Allow the presentation tier to be accessed via a Web service layer. Web Services for Remote Portlets (WSRP) is an OASIS standard that is gaining significant support within the portal market. Vendors can build Web applications that effectively run locally but that also are WSRP enabled so that other portals can access them remotely. There is no visual difference to the user.

It allows a local portal (consumer) to reuse and aggregate other portlets within remote portals (producer).