Comment lines: Scott Simmons: Modernizing banking core systems

There is a movement happening in the banking industry to modernize core systems. The process of transforming or replacing key banking applications presents co-challenges that are at odds with each other -- like trying to perform heart surgery during a marathon. Although maintaining and managing the current solutions while working to replace them seem both necessary and impossible to do at the same time, it can be done, and there are lessons to be learned from those who have been there. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Scott Simmons, Executive IT Architect, EMC

Scott SimmonsScott Simmons is the Lead Banking Solutions Architect for IBM's Worldwide Banking Center of Excellence. Prior to his work with the Banking Center of Excellence, Scott was the Lead Architect for the Worldwide SOA Technical Architecture team and was the technical leader for over 50 IBM SOA Architects around the world. Scott is both an IBM Certified Senior IT Architect as well as a Master IT Architect with the Open Group. Scott specializes in design, development and implementation of SOA architectures for customers and partners and is also a Certified SOA Solution Designer. Scott has been published in numerous periodicals including WebSphere Developer Technical Journal, Web Services Journal and WebSphere Journal. Scott was formerly the Previous to working for IBM, Scott was the lead architect for the Chief Technology Office at Peregrine/Extricity as Director of Technology Solutions. Scott has extensive experience in integration and messaging architecture as well as data architecture design/deployment through employment with Vitria, Illustra/Informix, and Sybase.


developerWorks Contributing author
        level

03 September 2008

Also available in Chinese

Performing heart surgery during marathons

The heading above might seem to be an odd phrasing for a technical column, but the analogy is actually borrowed from a banking client describing his system requirements. Banking core systems make up the cardiovascular system for a bank, providing the solutions that drive revenue generating operations, such as account management, deposits, loans, credit cards, and the like. The current core systems are largely 20+ year-old mainframe-based product-oriented applications that lack flexibility and often impede the ability of IT to quickly and efficiently respond to new business requirements.

In numerous engagements with banking clients around world, the IBM® Banking Center of Excellence (BCOE) is witnessing a concerted movement for core systems modernization -- the process of transforming or replacing these key applications -- and so the heading above refers to the co-challenges that are at odds with each other in maintaining and managing the current solutions while working to replace the core system functionality.

Before going on about "heart surgery," we need to take one step back and state definitively that core systems modernization is not legacy system integration; it is much more than that.

First, "legacy" is a presumptuous term when applied to banking mainframe solutions. Legacy is defined as of, relating to, or being a previous or outdated computer system. So, "legacy" is not really a valid term in this context, since mainframe systems are the workhorses of IT; current estimates place 80% or more of the world’s current data on mainframes. Though this estimate varies by industry, COBOL and PL1 on CICS®, IMS, and batch environments provide the foundation for the world’s core banking applications. More importantly, this approach will continue to be a cornerstone of banking IT architecture for the foreseeable future. Although we see an increase in core banking solutions implemented on distributed systems, the inherent scalability, reliability, and security of the mainframe continue to be key determinants for the ongoing use of mainframes in Tier 1 and Tier 2 banks worldwide.

Second, core systems modernization is more than just an integration approach. In fact, many of the problems surfacing today in core systems result from the application of tactical integration solutions with minimal regard for the end-to-end solution architecture. This problem is shown graphically in Figure 1.

Figure 1. Current core banking systems
Figure 1. Current core banking systems

Product-oriented core banking solutions are plagued by ongoing application fragmentation resulting in an ever-increasing maintenance burden. In 2005, Tower Group reported that core systems account for one-half of total IT spending in a bank and account for three-quarters of the total maintenance in IT. The inflexibility within core systems limits the ability to respond to business requirements, and this in turns leads to patching to keep the solutions relevant and viable. One current client commented that adding a financial product to their existing CICS-based core systems required over six months. Such an IT burden creates an untenable situation. As a result, banks are reviewing core systems alternatives to reduce costs and -- perhaps more importantly -- to provide better alignment between business and IT.

So what is the answer to modernizing core systems?

In many cases, of course, there is no single recommended approach. Business priorities, geographical considerations, risk exposure, and time to market needs are some of the key dimensions that drive a "surgical" decision. At the Banking Center of Excellence, we find core systems modernization usually falls into one of four major areas:

  • Package replacement: Selecting and implementing a vendor package to replace the current core systems.
  • Custom application development: Design, develop, and implement custom solutions to replace the current core systems.
  • Augment or extend current core system functionality: Select and implement off-the-shelf solutions to extend or augment current core function areas, such as product and pricing management, customer master data management, customer relationship management, and other specific core banking domains.
  • Progressive modernization approaches: Use a combination of off-the-shelf solutions and custom development to renovate and extend (and, in some cases, replace) portions of the current core systems architecture over time.

The first three approaches listed above are valid options, but the focus for this discussion is the fourth approach, the progressive renewal of banking core systems. Entire end-to-end core system replacement projects ("heart transplants," if you will) can take four or more years to complete, cost hundred of millions of dollars, and come with no guarantee for success. On the other hand, the progressive approach enables banks to "perform heart surgery during a marathon" with an iterative approach that targets business-critical gaps in the current core systems while leaving much of the overall infrastructure untouched.


Core systems modernization

Progressive modernization extends or replaces core system functions incrementally, based on business requirements. This approach has been evangelized by IBM for many years. With the formalization of service-oriented design approaches, emergence of banking-specific master data management capabilities, and maturation of industry models (such as IBM’s Information FrameWork), this approach is increasingly preferred as a strategic roadmap.

Core systems modernization requires the linkage of business strategies with the selected approach. Additionally, it is mandatory to have active project/program sponsorship usually at the level of the CEO, CIO, or the Board of Directors; core system modernization projects with a business-oriented approach results in higher overall success. We also find that these projects are more successful with the definition of a comprehensive business architecture (for example, business models and associated activities or processes, business roles/user groups and business information models). Business architectures are often modeled as business components using approaches such as IBM’s component business modeling technique. After these business components are defined, solutions can be designed through development of process models, use cases, and associated key performance indicators (KPIs). These models and KPIs become key inputs for the technical design.

This business-driven approach enables banks to prioritize the domains for modernization based on business needs. This prioritization is followed by phased development or initiatives for these specific domains. Some companies pursue mulitple workstreams simultaneously, but this multi-initiative approach is typically very challenging; banks attempting concurrent projects need to manage the interdependencies between the projects, as well as manage expectations. Disciplined scope management is a key success factor for executing modernization roadmaps.

Solution definition can be accelerated through the adoption of industry frameworks and reference models. Using models enables banks to customize best practices as part of the surgical process. Many banks utilize IBM’s Information FrameWork to assist in assessment, requirement definition, and component development for process and data solutions.

The Information FrameWork consists of multiple models, including:

  • Financial Services Data Model (FSDM) provides a classification model for concepts and information domains in banking.
  • Financial Services Function Model details the key functions that must be managed by a bank.
  • Banking Data Warehouse Model (BDWM) provides an extensive data model for data warehouse and business intelligence requirements. Related components include the Business Solution Templates, Application Solution Templates, and Project Views to further support data warehouse and business intelligence projects.
  • Financial Services Workflow Model (FS-WM) details an enterprise-level dictionary of key activities independent of product, channel, organization structure, or technology.
  • Business Process Models document over 400 processes for banking and financial services in areas such as customer on-boarding, transaction processing, and payments.
  • Business Object Model (FS-BOM) provides use case definitions and an integrated class model of all financial services concepts to support requirements definition and business-oriented solution design.
  • Interface Design Model (FS-IDM) details the components and interfaces of the concepts identified in the Business Object Model to support implementation of service-oriented components.

The details of the individual components in the Information FrameWork are beyond the scope of our discussion, but a recent Redbook (see Resources) does an exceptional job of describing the use of the Information FrameWork with the IBM Software Development platform, and is a key reference for core system developers. The Information FrameWork recommends a top-down approach that links the elements of the bank’s business architecture to the IT architecture specification.

The Information FrameWork identifies the key domains for a banking organization including (but not limited to) core systems. A current banking client uses the Information FrameWork to act as an extended checklist for the classifying data and application assets in their 300+ mainframe applications. This application asset profiling coupled with a top-down design approach (based on Information FrameWork’s Financial Services Data Model and process models) are cornerstones in this bank’s core systems initiatives.

A recurring theme in successful modernization projects is the definition of a common solution foundation for the To-Be core architecture. Core system modernization typically requires a coherent enterprise approach at the business or technical levels -- although it does not necessitate using identical architectural approaches across all solutions.

Given a well-defined business and technical architecture, we usually recommend a progressive modernization approach. This iterative approach consists of three major areas:

  • Application transformation focuses on applying pattern-based approaches for integrating and extending current mainframe-based core banking assets. We see this being implemented in a variety of ways (more on this later), often through bottom-up design and development efforts. This approach also provides for the integration of core solution assets with third party solutions to enable best-of-breed approaches.

  • Business process management (BPM) is a process-based approach, usually arising from a top-down modeling of business processes and use cases. This approach is often characterized as an SOA solution that compliments and extends the current core systems. The process layer and services mid-tier isolates the underlying core systems and can enable development of innovative channel-based applications across various external constituencies and communication solutions (for example, mobile, direct, Internet, and so on).

  • Master data management for customer, account, and product data. The product-oriented application silos that comprise most core banking solutions lead to data redundancy for core bank data domains, such as customer and product data. This proliferation of data leads to data quality issues, as the bank struggles with multiple "versions of truth." This situation usually leads to the adoption of master data management solutions focused on two key data domains:

    • Customer and account domain: This solution approach characterizes the evolution of the traditional customer information file (CIF) solution to the implementation of an end-to-end customer-data architecture that manages involved-party as well as account/arrangement relationships.
    • Product domain: This functionality is associated with "product factory" functions and focuses on implementation of an operational product catalog to support product creation and lifecycle management.

These approaches are non-exclusive; projects can use one or more of these above approaches as part of their roadmap. At the moment, we see a greater shift towards business process management and master data management-based approaches, but we continue to see banks approaching core systems renewal solely via application modernization activities.


Application transformation

Application transformation is the most fundamental approach to core systems modernization. Many banks employ this approach through re-facing mainframe applications, service-enabling existing application assets, or rewriting portions of their current solutions. One limiting aspect of this is that it often represents a bottom-up IT-driven approach for core systems renewal. Although application transformation can help you take the initial step towards next generation core systems, this approach is often a tactical response confined to surfacing or service-enabling one or more key assets. When combined with a broader strategic initiative, such as business process management or master data management, application transformation plays a key role in a business-driven core systems approach.

The article SOA programming model for implementing Web services: SOA and the mainframe software environment by Jim Rhyne discusses that the "extend the mainframe" approach often represents the easiest alternative with the lowest total cost of ownership, based on SOA. This is a key reason why SOA-based application transformation is a key component of a renewal approach. When looking at application transformation from a service-oriented perspective, one problematic area is the identification of candidate services and the subsequent service specification and modeling. We urge clients to use the Service Oriented Modeling and Architecture (SOMA) method to develop services models and an overall SOA approach. During the SOMA service identification phase, asset discovery makes use of tools such as the IBM Rational® Asset Analyzer and CICS Interdependency Analyzer to generate asset metadata. Through analysis of this metadata, clients are able to isolate potential assets and identify candidate services.

During asset analysis, clients are advised to select a small number of key domains or applications to focus on. Once the asset discovery process identifies potential assets, this information is reconciled with business requirements to narrow down the potential candidate service. IT-driven application transformation projects often skip this critical step, which results in the identification of potentially hundreds of fine-grained candidate services. This situation leads to the design of non-business-oriented services that do not reflect the desired target core systems state, greatly limiting the effectiveness of the SOA approach.

The Information FrameWork FS-BOM and FS-IDM models provide support for the design and development of component services from both business and technical perspectives. These models support integration with IBM Rational Software Architect to support design activities, and they support the service identification and specification phases by providing a model for service definition and implementation. A current banking client is using the FS-IDM model to guide in the design of target financial product management services as part of a cooperative project with the Banking Center of Excellence.

Following service identification and specification, service realization activities then commence that lead to service implementation tasks. Alternatives for application transformation are typically grouped into three major areas:

  • Wrap assets: This approach consists of multiple techniques. One popular technique enables clients to re-face 3270 user interfaces with tools like Host Access Transformation (HATS) to generate Web-based interfaces as well as services. Many clients employ service-oriented approaches through J2C adapter development or the use of Web service frameworks available through CICS and IMS. These SOA-based development tasks often use tools like IBM Rational Developer for System z™. Often, these externalized services or operations are extended with Enterprise Service Bus patterns to provide mediation, conversion, and routing.

  • Restructure assets: This approach extends specific aspects of the asset. Commonly, we see this approach implemented to support re-definition of data access (for example, transitioning from IMS-DL/1 to DB2®). This also provides an approach for message-enabling applications via solutions such as IBM WebSphere MQ or JMS.

  • Rebuild assets: This approach is the most complex of the group and is characterized by rewriting the asset through Java™, COBOL, C, or IBM Rational Business Developer. These rebuilding activities are often coupled with redeployment of the function to new solution architectures (such as WebSphere Application Server), and sometimes through redeployment of the asset to, for example, distributed platforms. This transformation approach is the most costly, and requires careful assessment to ensure the solution aligns with future requirements. Additionally, the design needs to detail decommissioning the current asset, which also requires dependency analysis and planning.


Business process management and modernization

Progressive renewal of core systems through a process oriented approach is key to aligning business requirements with IT. Using the analogy of heart bypass surgery might be appropriate because the BPM approach extends core applications with a process and service middle-tier. Although the approach is involved, it is a common and tested approach that we see being widely adopted. The BPM approach is characterized by aggregation of services into higher-order business oriented services and functions using SOA-based BPM technologies including WS-BPEL.

This process-oriented approach begins with the domain decomposition sub-technique as part of service identification. This set of activities directs business architects to use process modeling techniques to identify and decompose key business functions. In client engagements, we often use the Information FrameWork business process models as accelerants in developing core system business processes; the models can be used directly with multiple tools including ARIS, IBM WebSphere Business Modeler, and IBM Rational Software Architect.

Although business process management can be undertaken as strictly a process modeling and analysis exercise, the ability to implement executable business processes is a key part of the solution approach. Orchestrating service components via a loosely coupled programming model enables the creation of business services that exist in different applications, platforms, and even organizations.

This process-oriented approach to core system solution design is shown in Figure 2. This diagram depicts retail lending as a high level business service that comprises multiple processes such as loan origination, loan servicing, and loan closure. Each process invokes atomic and composite services, such as receive applications, check credit, and so on. Each service, in turn, provides interfaces to specific service components that might represent adapter operations, message flows, or other interface components that encapsulate functions from the operational systems. Additionally, the processes utilize technical service components depicted in the Integration, Quality of Service (QoS), and Data Architecture layers on the right side of the diagram. By enabling a loosely coupled approach to core systems integration, the business processing approach provides a foundation to generate new business services more easily.

Figure 2. Loan origination business process example
Figure 2. Loan origination business process example

The BPM-based SOA solution mid-tier also provides development of service-aware service consumer applications. As a result, solution layering enables banks to develop channel-based interfaces (for example, mobile, direct, Internet) to exposed services and then augment or extend the channel layer as needed. For example, this approach enables portlet generation from the business services, such as loan origination.


Master data management solutions

As the third dimension of modernization, master data management patterns provide solutions that extend and enhance core banking applications through a more streamlined and consolidated data architecture. A key deficiency in current core systems is data proliferation with mulitple applications acting as sources for key data. The lack of a "single version of the truth" results in maintenance challenges, regulatory exposure, and data inconsistency. An enterprise master data management (MDM) approach can provide this "single version of the truth," enhancing core systems functionality and providing transition approach to the next generation target core systems.

The article Master Data Management architecture patterns discusses architectural aspects of the MDM approach and identifies four key implementation styles:

  • Consolidation: Provides a limited set of the master data and support synchronization via batch import/export of the data.
  • Registry: Provides enterprise applications read-only access to master data and materializes only a small subset of the domain information (cross-reference and critical data) in the master data solution.
  • Coexistence: Fully materializes all master data attributes in the MDM system and synchronizes information between the master data solution and the source/target applications periodically with a distributed authoring pattern.
  • Transaction: Provides the operational source (system of record) with central authoring for all key master data -- and the master data is consistent, accurate and complete at all times.

We see many users employing the co-existence style as a transitional approach with the objective to move to a transactional style as the target end-state. One current banking client is supporting a customer master data implementation as well as a global product catalog project using Information FrameWork and IBM InfoSphere™ Master Data Managerment Server. The solution is initially implementing a co-existence pattern with SOAP-based service calls between the InfoSphere Master Data Managerment Server and their existing CICS-based applications. As part of the transition plan, we are designing an approach to migrate the solution to a transactional style over the next 2-3 years.

The implementation of an MDM solution is often complimented by the adoption of the Information FrameWork FSDM and IBM (or other vendors’) master data management solutions. The current InfoSphere Master Data Managerment Server provides support for the customer and product domain; through the use of the Information FrameWork reference models, we are enhancing the master data domains and processes to support extended banking requirements. Organizations use the FSDM to guide definition of the information domains and use the FS-IDM to characterize target service implementations, as discussed earlier. The customer MDM solution focuses on the concept of an involved party domain (for example, agent, customer, employee, prospect, supplier, and so on) and the concept of an account entity (for example, contract, agreement, reward program, financial account, and so on). As an example, a banking client is currently using FSDM in conjunction with IBM’s MDM solutions to implement a global customer repository providing support for cross-marketing, relationship management, and improvement of the customer experience.

The product master data management approach provides implementation of global product functions in a single catalog or repository enabling faster time to market for new products and the management of products across multiple business domains and applications. The product domain primarily focuses on the product entity and the characteristics of the specific product (like attributes, rules, terms and conditions, pricing, risk, and so on). The product domain supports relationship across both account and location domains.


Providing the architecture for progressive modernization

As a final area for discussion, it is critical to review the non-functional architectural aspects that must be designed, developed, and managed as part of progressive modernization solutions. After all, when a patient undergoes surgery, it's important to maintain their vital signs. This becomes challenging when the patient is running a marathon at the same time; providing full access to current functions while enhancing those functions in a progressive approach. The non-functional aspects of the new solution must be consistent with the current environment to meet with expectations of the application consumers.

The BCOE worked with a large customer on the assessment of their current environment and their readiness for core systems renewal. The assessment revealed product currency gaps in their operational environments, as well as monitoring deficits resulting in our recommendation to correct the infrastructure issues prior to embarking on a core systems renewal approach. The point is it that you do not want to "operate on a sick patient."

Non-functional requirements must be characterized during the modeling of every service, process, and data function. When evaluating approaches, there are several key non-functional areas that should be assessed and evaluated, such as:

  • Performance and scalability: The new solutions must support the same workloads (as well as projected workloads) with equivalent response times as the current system. This requirement might force tradeoffs in design and implementation to include service modeling decisions, service realization and implementation options, virtualization techniques, and the introduction of extended solutions (for example, appliances such as IBM WebSphere DataPower®, mainframe specialty engines such as zIPP and zAPP, and IBM WebSphere Extended Deployment).

  • Availability and reliability: Similar to performance and scalability, users expect solution uptime and reliability to be consistent with the current system. With additional components added to support modernization, the design must identify hardware and software redundancy, definition and assurance of failover capabilities, and additional considerations for remote site recovery.

  • Security: In this age of hackers, security has added significance. A key attribute of the mainframe over the years has been its rock-solid security at the hardware and software level. With the introduction of new solution components, new security considerations might arise and require the introduction of federated security solutions or security components (such as DataPower appliances).

  • Management and monitoring: With the introduction of new solution components, requirements for management and monitoring require re-evaluation. As a result, users need to assess system management resources (tools and personnel) to manage these solutions. There might be additional tools needed, as well as operational processes and procedures developed to manage these new solutions.

As a result of the above, platform decisions (both hardware and operating system) become critical in the modernization approach. Given the huge presence of core system assets on the mainframe, a strong case can be made to deploy new solutions on the mainframe. The key strengths of the mainframe include:

  • Process performance: The mainframe sets the standard for performance and scalability but large distributed systems are catching up (and in some cases even surpass performance for specific types of applications).

  • Management: Even when performance becomes equivalent with distributed solutions, mainframe reliability, continuous operations, security, chargeback support, and virtualization surpass comparable distributed platform capabilities.

  • Support for SOA: Key updates in CICS and IMS environments enable direct SOA implementation and new component approaches. This is a key evolving capability of the mainframe landscape (and a key aspect of core renewal approaches).

  • Green initiatives: The emerging focus on "green" computing is a major advantage for the mainframe. Advances in cooling and energy utilization have shown the mainframe to offer huge advantages over similar workloads deployed in distributed environments.

Just to be clear, I am not disparaging the use of distributed systems, the key is to have the right platform for the solution. Although we see a movement towards distributed systems for core banking systems, the mainframe (and System z) excels at supporting mixed workloads and continues to provide the scalability, reliability, security, and availability required to support core systems operations.

In addition to determining the optimal platform approach, the definition of the software solution stack for modernization represents an important set of architectural decisions. As mentioned, there are three major approaches and each requires the introduction of new development and runtime solutions. Typically, clients already have many of these software solutions present, although they might not be applying them to core system solutions. The components needed to accomplish the range of core system renewal approaches we have discussed optionally include:

  • Process server solutions, such as IBM WebSphere Process Server: This component provides a framework for the execution of WS BPEL-based process solutions and support for human task management.
  • Service registry/repository solutions, such as IBM WebSphere Service Registry and Repository: This solution component supports the ability to publish, find, enrich, manage, and govern services and policies.
  • Portal server solutions, such as IBM WebSphere Portal: This component provides the runtime environment for user-facing, role-based applications and associated search, personalization, and security capabilities.
  • Rules engine solutions, such as iLog JRules: This component provides a business rule management system to define and manage business rules and policies.
  • Enterprise Service Bus solutions, such as IBM WebSphere ESB, WebSphere Message Broker, and WebSphere DataPower SOA appliances: These components provide service mediation as part of a service-oriented architecture implementation.
  • Master data management solutions, such as IBM InfoSphere Master Data Management Server: This component manages master data across customer, product, account, and other key master data domains.

Figure 3 shows a comprehensive software stack to support core systems modernization. Although not all components are needed to support renewal projects, the diagram shows the likely end-state target architecture for supporting application transformation, BPM design and deployment, and banking master data management approaches.

Figure 3. Core banking systems
Figure 3. Core banking systems

Summary

If you made it this far, congratulations, you are an amateur heart surgeon! All humor aside, banks must develop a coherent and consistent approach to core systems renewal. The current systems simply do not work; these challenged solutions impede banks in many critical ways. When we review the history around core systems modernization, bottom-up design and line-of-business approaches have driven siloed IT decisions, accelerating the decay of these solutions. As we move forward, it is clear that top-down design is required for successful core system renewal projects. Without a strong business architecture and sponsorship, modernization projects are seriously challenged.

We have learned a number of lessons as we have engaged clients in core systems modernization. Among them:

  • Successful core systems modernization projects benefit from "laser focus" on one or two domains. By developing a roadmap based on business priorities, iterative improvements in core systems lessen the risk and better support changing business requirements than full replacements.

  • An industry model approach (such as the Information Framework) provides reference components to help define the target business architecture and overall technical solution approach. The model-based approach enables better business-technical alignment and provides assets (services and processes) for the design and development of new solutions.

  • The adoption of a disciplined approach to service design, such as SOMA, is critical to the development of business relevant solutions and is key to application transformation, BPM, and master data management renewal approaches.

The development of a core systems modernization approach links directly to business strategy. By developing a roadmap based on business priorities, banks can surgically extend and replace key portions of their cardiovascular system. The incremental introduction of application transformation, BPM approaches, and master data management solutions represent initiatives that form the basis for a complete modernization solution. For banks that require a full core system replacement, there are multiple core systems replacement strategies to manage the risks and provide both ISV and custom approaches for end-to-end core banking solutions. Success with core systems modernization results from thinking strategically and executing tactically, applying proven approaches to enable banks to "perform heart surgery during marathons."


Acknowledgements

I wish to acknowledge Jim Rhyne, Ben Baker, Steve Engle, Dave Zimmerman, and Skip Churchill for their contributions to IBM’s banking industry expertise and their review of this article. Additional thanks to the entire Banking Center of Excellence for continuing to push forward the IBM knowledge base in banking -- we continue to provide leadership in this industry due to the expertise on this talented team. Additionally, I want to acknowledge the contribution of intellectual concepts as well as diagrams that have found their way into public domain (though I believe Figure 3 is from Ben Baker, so thank you Ben). Finally, thanks to Nick Norris and Brian Byrne as many of the overall concepts and techniques come directly from their work around Information FrameWork and banking application solution development.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services
ArticleID=334400
ArticleTitle=Comment lines: Scott Simmons: Modernizing banking core systems
publish-date=09032008