When I was a child, I was a big fan of scary movies like The Creature from the Black Lagoon and The Blob. Even now, I find myself drawn to these stories of fright, although I never imagined I would ever encounter anything even remotely as scary in my real life.
Well, in my role as the solution architect for the IBM® Worldwide Banking Center of Excellence, I have in fact borne witness to an occasional client situation that could chill an architect to the bones. I want to share with you some of the more frightening (and incredulous) things that I have encountered while helping banks develop core banking modernization strategies. I’m not talking about ghosts, goblins, or other creatures here, but something far scarier because they really exist: worst practices.
The actual statements I share with you below are evidence that bad things are lurking in the shadows of some organizations. My objective is to drag these bad things out of their dark hiding places and into the light to help you identify whether similar gremlins might be ready to bring havoc your way.
Occurrence: "We can document nonfunctional requirements later – just focus on the functional design now."
During a meeting on Internet banking solution design, an architect at Bank A raised concerns that their end-user login required over 25 separate hops to authenticate access for external customers. The architect voiced concerns on performance as well as availability. A core member of the bank’s IT security team responded that the security architecture was fixed and the project architects should "leave security to the experts" and "just focus on the functional design now."
Why this is scary:
The key dilemma is that architectural decisions on both functional and nonfunctional aspects (including security) need to be analyzed early in the project, and on a project-by-project basis. As part of the solution design, architects need to focus on all nonfunctional aspects of the solution. Although the security infrastructure might be viewed as fixed, the requirement to assess and evaluate other approaches is essential as part of a complete solution design. In the case of this specific situation, the team continued to evaluate other approaches to resolve the security performance issues and eventually implemented a security appliance as part of the solution.
Occurrence: "As your key ISV, we intend to support all of your requirements ... We have a flexible solution and can implement new functions easily."
During a strategic core banking project for Bank B, the ISV (independent software vendor) made this rather startling comment. It became clear that the package was being enhanced and extended as part of the actual project implementation with the specific client.
Why this is scary:
On one hand, the ability to adapt packaged applications to a client's needs is a key feature; however, the enhancements went much further than simple adaptations. We see this situation often due to rushed RFP (request for proposal) evaluations, and we urge clients to make sure that the requirements are clear, and that they are thoroughly validated in the evaluation. We recommend the use of appropriate tools to support requirement definition, and additionally to use these tools to support requirement validation. During the evaluation, organizations need to ensure that the vendor responses fully articulate the product capabilities versus offering implied promises of future capabilities.
As an additional concern, we find baseline changes in core banking applications (especially those done directly by the client) often lead to version lock-in with an inability to upgrade with new releases; as a result, it is imperative that clients evaluate upgrade aspects as part of solution design.
This client learned a valuable lesson at a high cost: 18 months after the start of the project, the IT executive team canceled the project and the bank is now looking at alternative approaches, using IBM as a trusted advisor in this process.
Occurrence: "We need to add two more functional requirements to the upcoming release -- but they are small changes."
A key stakeholder at Bank C raised this point in a design session with the project design authority. The bank was in the midst of service-enabling their in-house CICS®-based core banking solution to provide integration with a third party banking package.
Why this is scary:
Core banking modernization projects (and large complex IT projects in general) require rigorous planning and disciplined project management to be successful. Baseline change control is mandatory given the huge number of dependencies in core banking projects. Although exceptions will need to be made, exceptions must be managed as part of the formal governance and project management processes. Managing and coordinating change requests can be difficult – clients should use appropriate project management tools and methods to ensure baseline project control. In this specific instance, the stakeholders did not recognize that changes (however slight) translate into time, money, and risk, and this behavior continued unabated.
The bank eventually abandoned the project due to ongoing slippage in project delivery – an effective project design and governance authority would likely have changed this unfortunate outcome. IBM is working with the bank to establish a more rigorous project management function to prevent this from happening in the future
Occurrence: "Can we map our CICS transactions directly to services in our SOA solution approach?"
During an engagement deploying CICS Web services with Bank D, this question evidenced that the bank was not following any service design methodology.
Why this is scary:
Over time, the bank had built over 3,000 CICS transactions ranging from simple data lookups to complex transactional functions. Prior to our engagement, the client had decided to implement CICS Web services for the commonly used CICS transactions without assessing business or technical requirements. Essentially, the client was moving directly from asset analysis to implementing the candidate services. We recommended the adoption of SOMA (Service Oriented Modeling and Architecture) to support the service design in the project, as well as using it as a reference methodology for the organization. Specifically, we focused the client on the steps in service identification to ensure identification of candidate services, and the use of the SOMA Service Litmus Test methodology to ensure the correct services were being realized.
The outcome of this customer story was positive; we enhanced the client's approach to service design. As a general rule, you should not sacrifice good service design in order to mitigate time-to-market challenges.
Occurrence: "Can’t we just use our existing messaging technology to support content management requirements?"
During the design of an account management solution, this question was raised as Bank E was defining document management requirements. Given their use of IBM WebSphere® MQ and skills in user interface development, the developers initially proposed writing a custom lightweight content management solution.
Why this is scary:
Although the team developed a feasible SOA-based design for the solution, this approach was not the correct way to address this type of requirement. The key criterion for evaluating in-house development is TCA (total cost of acquisition), but in their haste to resolve the TCA challenges, the bank did not evaluate the scope of the content management requirements or the long term implications for code maintenance.
We continue to see organizations developing custom solutions for infrastructure requirements simply to mitigate costs. In our advisory role on the design team, we convinced the clients to avoid building content management capabilities. Instead of developing a custom solution, the bank implemented a vendor-based content management solution to support these requirements. Even though the selected solution offered significant functions over the actual requirements for the project, the vendor solution provided long term cost savings from both a maintenance and development perspective.
Occurrence: "The service specification is the WSDL. As a developer, this is the only documentation I need to develop the service."
At Bank F, one of the key developers made this statement during a design review discussion of a loan processing solution.
Why this is scary:
One key aspect to service design is that services must be well documented as part of the development lifecycle, and that the design should define functional and non-functional requirements, including service interaction aspects, service level agreements (SLA), service ownership, service policies, service composition aspects, and other related metadata. In short, service specification is more than just WSDL. Additionally, the service design needs to be managed as part of the overall governance authority and the development organization needs to have active involvement in this process.
The challenge raised in this example was an issue with the design process (or lack of) and a requirement for tooling to support service design and asset reuse. The result of this situation was the adoption of a broader service design approach and the introduction of a service registry and metadata management tooling to enable more complete service definition – which led to an optimized service design and increased asset/service reuse.
Occurrence: "System test requires too many resources and is very painful – we don't have enough hardware to do it right."
An IT executive at Bank G made this very candid comment during a review of their SOA-based core banking project.
Why this is scary: It was clear that the bank had a major problem: it had seven environments to support (unit test, integration test, system test, user acceptance test, stress/performance test, and so on) with over 30 packaged and in-house applications with different databases. We recommended the introduction of automated provisioning solutions and suggested enhancements in test scheduling and requisition to increase efficiency. These changes solve the immediate challenges but not the long-term ones. As a result, this client is now assessing the implementation of a development/test private cloud.
Core banking transformation projects are very complex and we believe that implementing virtualization and manual provisioning does not fully address the risk and resource management problems. Going forward, we anticipate that implementation of test/development clouds will become a preferred architecture as many worldwide banks seek to implement or modernize existing core solutions.
It is clear that there are a number of lessons to be learned in terms of core banking projects – or any large IT project -- we are seeing around the world. Most large banks have implemented large scale SOA projects, and, as a result, have already encountered (and resolved, in most cases) many of these challenges. Many mid-tier banks are now grappling with these challenges, and so hopefully this article has helped to point out some key issues to be considered so you can prevent your solution design from becoming another scary story.
As for me, I am glad to say that I still enjoy a scary story from time to time – which is a good thing because they certainly keep my job interesting!
technical resources for developers: Banking industry
IBM Banking Industry Framework
Redbook: Case Study: SOA Banking Business Pattern
modeling and architecture: How to identify, specify, and realize services for your SOA
IBM developerWorks WebSphere
Scott 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.