 | Level: Introductory Scott Simmons, Executive IT Architect, IBM
03 Sep 2008 
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.
From IBM WebSphere Developer Technical Journal.
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
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
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
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
About the author | 
| | Scott Simmons is the Principal Architect for the Worldwide SOA Technical Architecture team and is 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. From an industry focus standpoint, Scott specializes in experience with many vertical markets including finance, supply chain, electronics and automotive solution architectures. Scott has been published in numerous periodicals including WebSphere Developer Technical Journal, Web Services Journal and WebSphere Journal. 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. |
Rate this page
| |
