The lure of hitting that impossible milestone date is a powerful magnet. Ignore the cries of the Nay Sayers. The road is strewn with roadblocks and wrecks. The novice go-getter is easy prey to many distractions and the paralysis that large programmes can perpetuate.

Applying logic and rationale to the impossible tasks ahead will even break the strongest and resilient of consultants. However, it is only the Results oriented go-getter that will lock on to the desired end-state and work tirelessly to achieving the objectives.

All excuses and roadblocks are swept aside and strong leadership skills are required to build the momentum to achieve the seemingly impossible. It will not feel like fun during the heat and battle of war. There will be barely time to have a cup of coffee or even find the time to have lunch.

Every task is high priority. The criticality of delivering on time will be the mission impossible. The weeks will fly by and at the end of each week the go-getter will deliver tangible and measureable results that others will acknowledge as a small but true step forward.

Projects will be attracted to the go-getter and seek the guidance and formula for achieving such success. This is a fantastic place to be and if you can adopt such a results oriented delivery mindset whilst maintaining the trust and credibility to be considered the type of person that others will share a joke and beer with, then you may be doing a good and thoroughly rewarding job!

This was an obvious disadvantage for Oracle as the strategy to offer freeware was pointless if very few could actually get to enjoy the ride. Things appear to have moved on. Oracle have now taken a major step towards simplifying the availability and usability of their product portfolio by introducing a series of VM templates which are fully pre-installed, pre-configured applications and infrastructure all packaged into a single instance that can be uplodaded into a virtual machine running on VMware. All of which is free!

For example, an Oracle VM Template may include a single virtual machine, with a single Oracle product such as a single-instance database or WebLogic Server or multiple VMs with multiple Oracle products to facilitate rapid deployment of even the most complex composite applications such as E-Business Suite, JD Edwards EnterpriseOne,PeopleSoft HCM, or Siebel CRM.

Initial experience of this technology is that it is still relatively complex as it’s all based on Linux. However, it is certainly a great deal simpler than having to install the application stack from scratch.

It is a step in the right direction and will likely increase the accessibility of the Oracle portfolio to more developers and technogeeks. We look forward to increased productivity and less time installing the array of inter-dependent applications and infrastructure in favour of faster time to investigate the applications of the technology.

This is a great move and one that I will be exploring in some detail for a range of Oracle products that are freely available for download and evaluation. Geek heaven!!

The complexity of a project and the technical challenges cannot be underestimated. However, a large proportion of contributory factors is very tightly linked to the lack of discipline and rigour associated with the management and traceability of requirements. There is an important discipline that many quality delivery organisations follow that we can call the Application Delivery Methodology (ADM).

Every major corporation has a project management methodology and lifecycle. Unfortunately, very few people understand it and more importantly very rarely does the method assist in simplifying or improving the quality of project deliverables.

The purpose of our ADM is to standardise on a common set of artefacts for all business critical projects across the enterprise. In this article I investigate the importance of the tools required to support and manage the analysis and design phase of projects by managing the creation, maintenance and traceability of the ADM project artefacts and their inter-dependencies.

Traceability

The ADM has been created to primarily follow the waterfall design approach and more importantly the logical process model for the analysis and design phase of a project as depicted in the diagram below. It is important to note that the definition and alignment of test related artefacts is considered to be critical and within the scope of analysis and design phase of the project lifecycle.

The diagram above identifies the core project artefacts that will be produced to drive the enterprise towards the creation and delivery of a high quality software solution. In general, the IT department will adopt the role of overall design authority for the technical solution and will work with in-house resources, external suppliers and third parties to deliver a robust, scalable, extensible and integrated quality solution on a fixed price basis. The approach is equally applicable to bespoke build, COTS integration or change enhancement to an existing system. Furthermore, the rigour of the proposed approach is equally applicable to application development and infrastructure engagements.

The diagram above identifies the standard set of artefacts (see boxes) and the linkage between these products (see lines). The left hand column depicts the requirements specification artefacts (e.g. BRS, FRS, and DDS) that will be produced by (i) the business analyst team, and (ii) the design team. The right hand column identifies the associated validation criteria that are aligned with the requirements specification artefacts by the test team.

At a logical level, the diagram above depicts the inter-dependencies between artefacts. It should be immediately clear from this diagram why IT projects are so inherently complex to manage as the inter-dependencies and hence impacts of decisions within any given artefact can have a profound effect vertically and horizontally. Given that each artefact is targeted to capture the requirements and acceptance criteria of a unique set of users, it is clear that any mis-interpretation or gaps in the artefact will lead to a mismatch in expectations. Experience suggests that where this mismatch is significant, the project will identify defects and incur costs to realign the solution to the original business requirements.

ADM and Traceability

The ADM defines the standard templates for artefacts and more importantly the rules for capturing requirements and specifications in a pragmatic, unambiguous and rigorous manner which is readily understandable by the target audience and easy to interpret for test and verification purposes. However, it is absolutely key that the selected tool provides a simple way for managing traceability and linkage across artefacts and even within artefacts themselves.

Why is this important? The purpose of any IT engagement is to deliver a costed solution to the business requirements and achieve a defect free sign off to the User Acceptance Criteria. However, in order to achieve this, the analysts, designers and testers must work collaboratively to increasingly finer level of detail to decompose the problem statement into a functional/logical definition of the solution and ultimately into a detailed/physical representation that can be implemented.

The traceability and linkage across (i) the conceptual business view, (ii) the functional logical view and (iii) the detailed physical view is very complex to manage and hence appropriate tooling and governance must be put in place to make this a practical proposition.

For example, at a high level we require (i) vertical traceability from the BRS to/from the FRS, and similarly (ii) horizontal traceability from the BRS to/from the User Acceptance Testing (UAT).

The complexity of the analysis and design phase and the approach to decomposition is depicted in the diagram below which highlights the extent of documentation and linkage that will occur within even the simplest of projects.

This diagram is simply showing another view of the relationships and dependencies described earlier. For example, the horizontal relationship between the BRS and UAT (BRS ↔ UAT) is depicted at the top part of the document: from the BRS, one is able to derive a number of User Acceptance Tests; each user acceptance test can be linked to a requirement in the BRS. Also shown in the diagram vertical linkage between types of testing UAT↔System Test↔Integration Test↔Unit Test. The linkages highlighted in red show intra-domain linkages where there are horizontal inter-dependencies across FRS n and FRS n+2. Similar relationships and hierarchies will exist in the testing domain.

Many organisations when faced with the prospect of managing this number of artefacts will often raise the white flag of surrender and decide to pursue a RAD based iterative approach. This approach is commonly unacceptable within most corporations and experience has taught us that this approach is a false economy and abdicates the responsibility of this analysis to the developers whose decisions and interpretations are made in isolation during code construction and under extreme time pressures to deliver software to a tight schedule. This will almost always result in increased cost and delays to the final solution delivery. As the complex network of dependencies between analysis / design requirements and test is non-trivial, any attempt at manually performing this task becomes unmanageable without the use of appropriate tooling. The end result of such an approach is inevitably increased risk and exposure to stringent rules and regulations.

Whilst the ADM may appear to be forcing a waterfall approach to application delivery, in actual fact it is highly adaptable to an iterative and agile delivery model. As the methodology is rolled out and experience is gained in scoping and decomposing business requirements into the identified project artefacts, projects can be delivered iteratively and in a more agile manner as a number of thin inter-related tuplets (BRS, FRS, DDS) that form the basis of an independent work stream.

Summary Views

The selected tool must be able to easily generate a matrix view of requirements such that a detailed conceptual, logical and physical view of requirements can be traced horizontally and vertically allowing a collaborative team comprising of business users, business analysts, project managers, designers, developers and testers to get a consistent view of the inter-dependencies of requirements across the project. This is a very powerful feature that provides a framework for decomposing multiple views that spans organisational boundaries.

The generation of summary views must be derived and maintained from a consistent master repository which is professionally managed for configuration and change control as a group wide asset in much the same way as any productionised business application.

Business Requirements Traceability

Any tool must be easily configurable to apply appropriate business rules and a hierarchical labelling structure to all information contained within the repository. Specifically, the generation of unique identifiers to Business Requirements is absolutely key as this will be the primary key upon which all downstream requirements will be cross referenced. From the table above, we can see how a physical representation of the desired traceability can actually be displayed. This model allows for linkage of the BRS to inter-related BRS Identifiers and derived FRS and DDS. Furthermore, the linkage to testing is captured at the UAT.

It is highly likely that our standard tool for capturing and managing test requirements will be based on a product such as the Mercury Test Director suite. Hence, any tool that we identify must be able to support bi-lateral integration.

We would expect the tool to provide this view as an active navigational aid to browse to the desired level of detail and with appropriate drill down as required.

Functional Requirements Traceability

The FRS view is identical to the BRS view, however, the context is from the perspective of the Designer and hence the FRS is the starting point and associated System Test.

Detailed Design Traceability

The DDS view is identical to the BRS and FRS views, however, the context is from the perspective of the Designer/Developer and hence the DDS is the starting point and associated Integration Test and Unit Test.

ADM Tooling

The following UML diagram is a meta model of the information and concepts described above. As the meta model shows, there are many 1-to-many relationships between the various artefacts and we will be looking for tools that seamlessly manage these complex associations between the many project artefacts.

Until we have selected a tool, we will assume that:

· All requirements will be captured in Word and imported into the tool

· All requirements will be uniquely identified and referenceable through an auto generated tag or a "link"

· All requirements will be linked to an associated requirement and the linkage can be easily navigated up or down

· Using the method, the following documents will be generated and be fully traceable:

- Business Requirements Specifications

- Functional Requirements Specifications

- Detailed Design Specifications

- User Acceptance Tests

- System Tests

- Unit Tests

Traceability (vertical and horizontal) amongst these deliverables will be mandatory. The tool must provide an easy and robust mechanism for managing the associations and the tool must:

- Provide impact analysis reports e.g. to e able to quickly determine the impact of a requirement change

- Warn about and manage deletion of artefacts. Obviously, removing an artefact with dependant artefacts needs to be managed and handled correctly

- Provide different views on the data e.g. tree view, where starting from a requirement say, one can “drill” down into the associated artefacts such as analysis, tests (UAT, system test, unit tests) and

- Provide coverage reports i.e. have all expected artefacts for a requirement been produced and their status (e.g. complete, signed off, work in progress, …). The tool must highlight outstanding artefacts.

Summary

The successful rollout of the ADM requires appropriate tooling to support the easy and intuitive approach that we have defined. Specifically, the use of standard templates and the management, navigation and traceability of those artefacts across collaborating teams and organisations is considered to be very important. Whilst the identified tool must have a rich set of features, it is critical that it easily and flexibly handles traceability as described in this document and provide natural integration with the Mercury Test suite of applications.

Traceability ensures completeness, that all lower level requirements come from higher level requirements, and that all higher level requirements are allocated to lower level requirements. Traceability is also used to manage change and provides the basis for test planning.

The primary mission of EAI is to decouple and simplify the integration effort required to deliver the information required to support business processes across the enterprise of packaged and legacy applications. The business value of EAI is the speed and agility to integrate existing systems and applications the business and commercial pressures require rapid business transformation and the introduction of new processes and products.

Commercial EAI development frameworks define the enterprise integration processes which simplifies and reduces the amount of resources required to maintain, develop, and scale systems, as well as allows for the adoption and usage of standards bodies and schema repositories that define business process interaction.

Several EAI solutions exist in the marketplace that satisfy the requirements of EAI. Many companies are realising the benefits of EAI as a corporate architectural component that will allow them to bring to market their solutions faster. Other clients consider EAI for a specific project to solve a single issue – eg the integration of a few specific systems.

Spaghetti: Point-to-Point Architecture

Traditionally, systems integration took the form of one-to-one connections. A company looking to connect two systems together would develop an interface that would allow the two systems to talk to each other (and only each other). This approach allowed systems to be connected on an as needed basis and was a fairly inexpensive method. There was no additional software that needed to be purchased in order to facilitate the connection. However, each new system that was added would need to have interfaces built between it and any other systems with which it would need to communicate. These custom connections were not very flexible, and only allowed the systems to transfer data that was predefined in the interface. This architecture is often termed as a point-to-point architecture.

Lasagne: Hub and Spoke Architecture

EAI solutions primarily utilise a Hub-and-Spoke architecture, and are based on a central hub with many spokes (interfaces) attached to it. The hub is flexible, allowing any attached system to communicate with the any other attached system. This model requires the procurement of new software to act as the hub and the construction of new connections to it. The hub and spoke architecture allows the hub to perform functions, such as message queuing, routing and data translation, as well as facilitates real time collaboration and communication between business applications (processes and workflow).

Imperatives should be aligned to a business strategy and derived from the business requirements as well as data gathering during the technology selection and due diligence phases. Imperatives give an indication of the problems and challenges faced by the business and serve to define the solution and final road map.

Imperative statements do not seek to measure the degree of gap (eg inconvenience of the problems/issues identified) nor the potential benefits associated with their resolution and, therefore, no attempt to sequence or rank is necessary. Such activity is accomplished in other project artefacts.

Imperative statements should be used to form a basis upon which to evaluate any technology solutions during the critical RFP process. As such, it forms an important benchmark to assess how many business gaps or problems can be mitigated by a chosen implementation path.

The imperatives relevant to a core banking transformation can be organised around the following themes:-

Channel Effectiveness GAP: Existing channel infrastructures may impose artificial limits around a customer’s ability to self-service either from an account registration or account servicing perspective. This forces traffic into more expensive channels (e.g., branch, call centre) which are likewise limited by their ability to one-and-done events and instead act as order-takers for back office functions. Business events do not get resolved at source and typically do not follow a least cost route. FIX: Enhance channel experience, customer channel (and channel switching) choices, self service/self selection capabilities and increase one-and-done rates (STP).

Customer Centricity GAP: A finite amount of customer data is distributed across multiple systems and platforms – it is often incomplete or inconsistent. Whilst there may be an element of customer data centricity, it hasn’t been possible to fully deploy this to the customer, web, call centre or back office. With data distributed in many places it is a challenge to operationalise the value of that data in terms of sales opportunities or risk management (i.e., moving from “reactive” to “proactive” use of customer data to deliver a differential service to customers). FIX: Enhance single customer view, deepen customer insight and improve real-time interactions.

Product Flexibility GAP: The product sets that are available offer finite functionality. The ability to introduce new products or modify existing ones is constrained by the limitations of legacy systems (leading to extensive time lines). The ability to innovate is hindered by a lack of product manufacturing flexibility. There is no potential to bind products together into combined offerings using existing technology. FIX: Enhance product manufacture/distribution capability, enable bancassurer bundles and improve product time to market.

Process Improvement GAP: Process improvement and optimisation is limited by systems capability – these systems force a way of working that may not necessarily be aligned to the target operating model. The consequence is that events are not completed one-and-done, instead requiring single or multiple hand-offs. Many processes are paper based when they should be electronically handled – this can lead to errors and corrections that are time consuming to fix. FIX: Enhance processes through automation, compression of end to end duration, removal of paper based activities, and error mitigation.

Transaction Optimisation GAP: Transaction processing is handled by legacy core applications that are over 30 years old. They have known limitations around decimalisation, number size, data entry validation etc that result in operational volume through error fix and reconciliation. Additionally, the limitations of existing systems make the application of fees and interest a complex and manually intensive activity for some sectors. FIX: Enhance transaction processing with reduced manual data entry, improved routing and automation of events.

Risk Mitigation GAP: Risk and controls frameworks, whilst robust, are dependent upon manual intervention. The emergence of the faster payments world, and increased volatility within the credit markets proposes that current risk management tools require enhancement. FIX: Enhance risk and control frameworks through automation of manual checks and improved risk insight.

Distribution Efficiency GAP: It is a challenge to distributed information to customers via the lowest cost route. This is not helped by existing limitations with respect to consolidating and combining mailings and communications, or mitigating wasted communications. FIX: Enhance delivery options towards lowest cost routes and improve communication quality.

Information Intelligence GAP: MI and report management is disproportionate to the size of the organisation. Data is stored in different systems and distributed across multiple locations causing MI complexity. There is a common held view that there is no single consistent version of truth. FIX: Enhance customer and operational management information insight, create a single version of the truth, supported by streamlined report delivery.

Management Effectiveness GAP: The cost of maintaining regulatory compliance absorbs and ever more significant share of available investment and maintenance funding. This cost of compliance is directly linked to the complexity of legacy systems. FIX: Enhance responsiveness to regulatory change and mitigate ongoing cost of compliance.

Exceptions Mitigation GAP: Exceptions processing is a manual, labour intensive and paper based activity. FIX: Enhance error/warning insight and mitigate back office exceptions.

Infrastructure Stablisation GAP: Major application components that comprise the legacy core banking solution are developed in or running on legacy infrastructure. This may include unsupported software, licences and hardware. Channel components (in web and branch) may suffer from performance issues (degradation and outage) that causes customer inconvenience, complaints and compensation. FIX: Enhance platform resilience to performance issues and risk associated with heritage/unsupported technologies.

These themes can be further extended by drilling down into each theme to provide detailed imperatives based on specific types of business constraints. Contact me if you find this article interesting or require support in this field.

The main principles of patterns can be formalised and applied to almost any discipline. In particular, an architecture design pattern is an abstraction of a design or part of a design that can be applied to create a solution to a problem and more importantly a solution that can be reused.

In this context, a pattern is the description of a solution to a recurring problem within a strictly defined context.

Our clients are often face with the challenge of designing and delivering complex technical solutions faster, simpler and cheaper in order to meet the demands of their business. This is often a big ask and introduces some key challenges for technical teams:

1. The need to deliver technical solutions to business issues much quicker

2. The technical solutions are complex and hence open to risk

3. The demand for key skills and expertise are often over-stretched and in limited supply

These risks can be mitigated by using appropriate tools and methods, however, they must be complimented with patterns in order to continue mitigating risk whilst addressing the issue of delivery speed, quality and cost.

The development and use of design patterns will meet these challenges:

• Patterns shorten the advise phase because clients are presented with design solutions
• Patterns shorten the design phase because they are captured solutions to problems

Patterns mitigate design risk because:

• They reuse designs that have already been implemented and therefore are validated designs
• Technology patterns are linked to template specifications and component patterns strengthening the interface between architecture design and build

The context of each pattern defines the constraints, forces and limits of the pattern. The very nature of a pattern, essentially a “snapshot” of a solution to a problem or set of problems, means that each pattern has a limited life-span and must be updated and modified as problems change and new problems emerge. Patterns need to be versioned and their relationships maintained.

The picture above shows how various levels of Patterns representing different levels of abstraction will be related. The hierarchy that is expressed in this example starts from a business pattern of a Customer. In this case the constraint of the pattern Customer focuses on the need to manage the identification of customers. The architecture pattern Directory has been related to this business pattern, which describes a solution to a particular recurring problem of identifying and managing people. There happens to be FOUR available technology patterns related to the architecture pattern Directory of which the Novell NDS pattern is of interest.

Clearly, patterns will also be related at the same level. In supporting a particular business pattern, as in the Customer example above, there will probably be a need to aggregate architecture patterns to address a specific business requirements. Additionally, as multiple versions of a pattern exist within a particular level, so those versions need to be connected to understand the trace from one version to the next. To be most effective, some automated tool to support the capture and version management of patterns should be used.

Patterns do not describe process

Because patterns are a snapshot of a design solution to a problem and therefore rich in content nothing will be captured about the process of that design. .

But patterns are employed during a design process

The use of patterns in a particular project life-cycle however, will have to be integrated into our existing and proposed process oriented methods.

Business problem may have been identified such as “How to take payment from a customer through a web browser”. Or a technical issue such as “How to ensure that nobody can snoop a customers payment details when they send them through a web browser over the internet”.

To solve the first problem a web-based payment process would need to be designed, for the second a private key/public key infrastructure may need to be designed and developed. Both solutions can be captured as patterns and reused by other projects.

Patterns have standard notation

Patterns will also have a standard template, see below for a proposal of the format:

Name(s)	The name and a short summary of the Pattern
Contact(s)	Subject expert on pattern
Problem	The recurring problem the pattern addresses, including a discussion of its associated forces, within context
Solution	The fundamental solution principle underlying the pattern including a detailed specification of the structural aspects of the pattern
Dynamics	Typical scenarios describing ‘run-time behaviour’ of the pattern
Implementation guidelines	Guidelines for implementing the pattern
Variants	A brief description of variants or specialisations of a pattern
Known uses	Examples of the use of the pattern, taken from existing systems
Consequences	The benefits the pattern provides, and any potential liabilities
Related Patterns	Patterns at other levels that are related, i.e. Business, Architecture and Technology
See also (links)	References to patterns that solve similar problems, and to patterns that help us refine the pattern we are describing

This template will allow the inclusion of other media besides text.

Patterns need to be rigorous

The context of each pattern will be used to capture metrics that measure things like the scalability of a solution and the limitations of a solution. Each pattern that is captured from will need to be validated and reviewed. Both the context and the validation process should ensure that patterns are not misused and that the consequences of deploying a particular pattern are understood by the architect.

Who will benefit from patterns?

Patterns will become the essential tool for designing and delivering the complex architectures needed for complex IT programmes. This is because of the aggressive timeframes and price constraints that clients are facing. Many architects, system engineers and some program managers have expressed interest in the potential of patterns.

Many design and development organisation are constrained by the suitability of their methods and toolsets. The architecture design cycle is perceived as being too long and does not address re-use effectively. Additionally, there is a perception that delivery tends to err on the side of bespoke development and not enough re-use of component based delivery increasing both delivery timescales and overall delivery risk.

This is an interesting subject for any consultant or knowledge engineer as the amount of data sitting on the average desktop computer is phenomenal and can offer a very rich source of content that can be harvested to solve the next big problem.

The range of desktop search technologies already available to rapidly index and accelerate the speed with which we can search for specific nuggets. The most obvious examples are Microsoft Search which is embedded within recent releases of the Windows operating system and the browser based Google Desktop.

Whilst these technologies are very powerful and indeed helpful, they are far from perfect as the result sets that are retrieved for any search are usually huge and makes it impossible for the user to review the complete set of results. At best, one can expect to review a small sample of documents before getting distracted and losing focus on the intended search theme.

Retail organisations that operate large product catalogues have a very smart way of simplifying the search for products for their customers by making use of meta data to segment the search population into a range of views to rapidly reduce the product options such that a customer is able to make a comparison and eventually a purchasing decision.

The classification and taxonomy for the product catalogue makes use of a hierarchy of dependencies between categories, products and associated searchable attributes. For example, if I am looking to purchase a new computer I would look for the Electrical Category and then be presented with the option for Computers. The search and available choice of computers could then be filtered to a narrow choice based on attributes such as brand, price, disk size, memory, processor and so on. Companies such as Endeca.

With desktop search the results are free form and unstructured. The availability of new technologies such as Tag clouds (like the one shown on this website) are a step in the right direction and help simplify knowledge management. The use of font sizing to highlight frequency of occurrence of a tag offers a simple and yet powerful visual filter of popular themes. However, it does not overcome the earlier problem of producing a large population of search results and hence does not narrow down and speed up the search process towards the best possible set of documents.

I expect that the next wave of desktop search will move towards the multi-dimensional structured search capabilities that we see on retail websites. By segmenting the contents of our desktop to a structured network of inter-dependent topics and content, users will be able to rapidly filter and hence discover knowledge that would otherwise be buried and lost.

The solution is a hybrid that combines (i) the fast and automated indexing technologies that are currently able to rapidly highlight every file that contains a search word with (ii) the tag clouding technology that is pervasive on websites.

The key to any big and complex problem is to apply thought and creativity to decompose the problem into manageable chunks. Put another way: filtering! The indexing capabilities of the modern desktop coupled with the visual filtering capabilities of multi-dimensional tag clouding could be an exciting step that would allow us to navigate the darkest corners of our file system.

Reuse reuse reuse. That is the key to greater productivity. For every problem or question there are several possible solutions. There is no need to reinvent the wheel. As a consultant, we must learn to tap into all available knowledge sources to help kick start and add impetus to projects where schedules and costs are under constant pressure.

The measure of success will depend on how the strategy lends itself to support the business, IT and service partners. The process flow above shows the steps that must be adopted to define an aligned business and IT strategy.

These core consultant attributes are:

1. Flexibility – will they listen and adapt to your needs?
2. Dependability – will they turn up each day?
3. Productivity – will they deliver the desired outcomes?
4. Likeability – will they fit in and energise your organisation?
5. Affordability – will they provide value for money and within budget?
6. Availability – when can they start?

By focusing on these key attributes and assigning appropriate weightings to suit their specific needs and priorities, hiring managers can simplify the selection process and allow for faster and more effective project resourcing.

These findings are based on a combination of client based consultancy engagements and a review of core banking system vendors.

Our in depth knowledge of technology best practise for System Integration and Business Strategy Innovation enables us to to offer an independent advisory service to CEO’s and CIO’s to implement a technology strategy that will position their organisation for the next wave of growth.

We can assist you to efficiently and fundamentally narrow down the search for the right technology solutions and architectures to simplify your investment decision making based on a well-informed pool of knowledge and expertise.

We can provide your organisation with considerable benefits in the area of system selection and implementation, including:

■ a broad spectrum of services and in depth experience of every phase of the system selection process;

■ an exceptional track record based on the successful implementation of many different types of package solutions;

■ different application maintenance options on vendor solutions;

■ leading-edge capabilities closely attuned to current and future industry changes;

Should you require any further information or assistance in this area or any major technology change programme, please contact us for an informal discussion.

Contents

1 Background. 4

1.1 Emerging Markets Strategy

1.2 Core Banking Technology

1.3 Technology Trend

1.4 Retail Banking

1.5 Corporate Banking

1.6 Emerging Markets

2 Core Banking Domains

2.1 Payments

2.2 Savings

2.3 Loans

3 Core Banking Solutions

3.1 Package Vendors

3.2 Recent Developments

3.3 Commercial Factors

3.4 Outsourcing

3.5 Future Direction

4 Methodology

4.1 Business Case

4.2 Benefits Tracking

4.3 Governance

4.4 Portfolio Management

4.5 Change Management

4.6 Work Plan

4.7 Resourcing

4.8 Architecture

4.9 Partnership

5 Summary

1 Background

“Continued growth through product innovation and acquisition will be constrained by a malaise of systems that are difficult to integrate and too costly to scale.”

The top retail banks in the European emerging markets are expanding into foreign markets and face challenges to integrate their acquisitions

1.1 Emerging Markets Strategy

The dominant banks in the European emerging markets are enjoying significant success and growth. The market leaders are consolidating their dominant positions and seeking to increase their assets, revenues and net incomes by triple digit amounts.

In developed markets facing product saturation, banks are fighting a battle to retain clients. In emerging markets where there are large segments of underbanked and unbanked customers, banks are competing to acquire customers through extensive reach, innovative products, and superior service.

The bank CEO is faced with offering a full range of retail banking products to match the competition and differentiate through excellent service. Innovative products must cover the spectrum of savings and deposits to loans and credit cards.

Having enjoyed the knock on effects of the boom years and achieved stellar performance milestones, many banks are pursuing acquisitions of new market segments in their existing territories and a new business footprint in regional neighbouring territories.

The rapid expansion has focused on establishing a broader branch network for retail banking products and the steady growth of the corporate banking sector.

Many CEOs now realise that expansion and growth highlights new challenges for their management as the existing operating model does not scale and weaknesses in infrastructure and processes start to hamper their limited resource pool.

Whilst many emerging markets acquire and increase their branch network, they will very quickly realise that the branch is the most expensive of all customer delivery channels. This cost is seen as a burden and many banks quickly focus on the integration of bank data and reconciliation amongst disparate and geographically distributed branches.

The management of credit and operational risk across the domestic and regional cross border locations is critical in maintaining transparency and visibility of the banks positions, volumes, trends and profitability.

Dominant country retail banks enjoy a near monopoly on the number of accounts held. Many recognise that they must continue to innovate and generate new and profitable business in order to stay ahead of the new entrants.

The major players are shifting their focus from a large pool of unprofitable accounts to a business model that is driving to generate greater value and profits from their core customers.

The new entrants are entirely focused on selling an integrated mix of profitable products to maximise their return on investment. The near monopolies are acutely aware that they will lose business through a process of attrition and be saddled with carrying a large population of dormant or unprofitable accounts. The effect of this baggage will be increased overhead costs and / or a lathargic pace of change.

New entrants are positioned to operate in a nimble and selective manner to attract profitable fee income and new sources of client deposits.

The opportunities for expansion and growth in home and regional markets must be tempered with the deepening credit crisis and the prospect of increased inflation which will have a knock on effect on regional economic growth and employment.

1.2 Core Banking Technology

The technology architecture of the bank will play a pivotal role in simplifying and standardising the way the bank competes for new business and revenue growth.

A capability of the bank is the core banking systems responsible for processing and posting transactions in the domains of payments, current and saving accounts, loans and securities (such as performing current and deposit accounting, maintaining loan accounts, holding securities positions, clearing payments).

Many emerging banks have a core banking systems that have evolved from a relatively small client base. As mergers and acquisitions of rivals have increased the asset base of the bank, this has also introduced a mix of core banking solutions into the overall technology portfolio.

The integration and scalability of the end to end core banking systems will prove to be increasingly complex and expensive to manage as the number of accounts and product types increase.

The competitive pressures will demand tighter integration across multiple delivery channels. The core banking applications are a mission critical component that impacts every aspect of the business of banking.

Replacing a core banking system is often an unthinkable option for risk averse senior managers who can only see the prospect of a time consuming, disruptive and expensive system integration project. The core banking system is the backbone infrastructure that handles all customer transactions and any glitch can grind the bank to a halt and tarnish it’s reputation in the process.

Technology innovation is an essential driver for business change as it offers to streamline the speed and flexibility of banking services through automation and reliable real-time handling of core banking processes. The integration of technology components and an information security architecture can be used to provide a single view of the customer and product catalogue to give the business the flexibility to cross-sell and gather business performance enhancing intelligence.

As financial institutions quickly realise that their current core systems are an unacceptable inhibitor to expansion and growth, they will seek to for alternative solutions that will offer better return on investment and invest in technologies that can be supported with from a greater pool of people.

Decisions on this scale must be justified by supporting evidence of inefficiencies, escalating cost of change and increasing cycle times to deliver new capabilities.

Strategic renewal initiatives will be expensive and complex. The bank will need to take a ten year view on financing and reaping the rewards from such an initiative.

1.3 Technology Trend

Major tier 1-3 banks in Europe are racing to renew their core banking platforms and many have already started to rationalise and renew their application portfolio.

The driver for this transformational change is based on a strategy to globalise IT based on a common architecture and modular application portfolio which is ready-to-go for new change the bank initiatives.

The major drivers in the sector for core banking replacements are:

■ the severity of regulatory requirements and penalties;

■ the appeal of a component approach (SaaS – Service as a Service – and BPM – Business Process Management);

■ a strong focus on architecture for the industrialisation of banking, infrastructure and multi-channel enablement;

■ availability of resources to tackle back-office systems;

■ industrialisation and the shift to transaction banking for core banking back-office systems;

■ new cross-border mergers and acquisitions wave in the emerging markets financial services industry.

Beneath that there is also the prospect for efficiencies through business process outsourcing and selective application outsourcing.

The challenge for emerging markets is the rapid expansion of clients and branch networks through acquisition of regional rivals results in a complex mix of technologies that must be rationalised and consolidated to a common standard.

1.4 Retail Banking

The complexity for many banks in the retail or consumer domain are volume handling and mass products. As the number of clients increases and a diverse set of channels are offered with the innovation of new products, the once stable core banking platforms start to buckle under the strain and the cost of running the service starts to soar.

Being able to manage large volumes of data and the end of day processing loads is the main challenge for core banking systems. Emerging markets banks that once had the luxury of running many diverse applications off of a single production core banking platform are now scampering to offload non-core bank related applications off platform.

Retail banking represents the most significant source of income and the top performers must embrace the fact that a cost-effective and scalable core banking platform will become a key differentiator between market leaders and poor performers.

Based on the tremendous consolidation that we have seen in the European banking market over the past 15 years, we expect that the Emerging Markets will see a similar evolutionary pattern as regulatory and competitive pressures drive tremendous consolidation in the sector.

Those players that invest in the flexibility and capabilities of their core systems will be better positioned to absorb the change and accelerate the pace of sustainable growth. Unfortunately, many emerging banks lack the maturity or vision to invest strategically to overcome:

■ the lack of flexibility which is a source of pain for many CEO’s who are keen to drive growth and product innovation;

■ the technology influencers where the cost of supporting the banks growth strategy is compromised by the ever increasing total cost of ownership of an ad-hoc technical architecture;

■ the lack of resources and increased complexity of project implementation is a severe challenge.

1.5 Corporate Banking

The business processes for managing corporate banking clients is fundamentally different to the high volume processing of retail banking. However, there is some trend towards a single core banking system for both retail and corporate operations. Many banks are seeking to simplify and standardise the way they manage clients by removing duplicate applications and infrastructure towards centralised systems with central data.

Strategically, the corporate and retail banking operations want an integrated global view of the customer with the possibility for all departments to have transparent online and daily insight to all accounts globally. Specifically, in emerging markets, the small to medium size corporate segment and the opportunity for micro-loans represents a growth area that must be managed efficiently and quickly by the branch network.

1.6 Emerging Markets

The emerging markets have some very unique opportunities that are dependent on the flexibility and adaptability of the core banking solutions:

■ start-up banking activities in new regions will focus on buying small operators with an existing license to get a rapid entry and exposure to a new market. The internet offers an excellent and low risk delivery channel for banking services where a standardised and robust core banking system service is already available in their dominant market;

■ secondary markets in insurance, wealth management, brokerage and car loans will also rely on core banking solutions to support their finance activities;

■ partnerships with retailers to offer their consumers retail banking products to improve customer retention will increase demands on white label core banking services;

■ monopoly banks in their dominant countries are rapidly reaching saturation level in their home markets and must diversify to new geographies to sustain their growth and address the attrition of their customer base by new competition from neighbouring countries.

2 Core Banking Domains

There are business and technical drivers for renewing systems. The characteristics of legacy systems is that are complex to change and administer as they have evolved over time to meet the demands of specific products, geographies and customers. Often the legacy technology portfolio will require complex integration and batch interfacing to overcome the limitations of a fragmented and distributed architecture.

The business drivers for change will primarily focus on the limitations to growth and competition. Inevitably, many banks will reach a point of diminishing returns where the cost of change to the legacy outstrips the business benefits.

The emerging markets have a business model that relies on very basic products to fulfil huge growth targets. As a result, these markets are dependent on basic improvements to deliver automated processes with adequate reliability.

2.1 Payments

The efficient and cost-effective processing of payments is a major driver for renewal. In particular, end of day processing and book balancing is a major burden for emerging markets as successful growth is now exposing weaknesses in infrastructures and application architectures.

Mergers and acquisitions are forcing banks to create a unified and integrated payments architecture that can handle cash, debit, credit, internet and mobile phone payments in a fast, transparent and secure manner to limit risk and the opportunity for fraud.

The most critical issues for banks is to deal with the complex compliance and regulatory requirements across their entire operations. The ability to inter-connect and collaborate with wider range of business partners requires conformance to an ever-increasing set of standards and protocols.

Investment in a flexible architecture that can accommodate emerging standards for transport, messaging and security is critical.

2.2 Savings

The savings market is highly competitive with the preference for internet savings accounts steadily increasing as clients are able to seek out the best products and easily move their funds between accounts.

The pervasiveness of internet banking as broken down the barriers to entry and specialised niche players, that are subsidiaries of foreign banks, are cherry picking the most lucrative savers to attract low cost cash deposits.

Banks are being forced to increase their range of savings products and place greater emphasis on product development in order to contend with the competition.

In an increasingly risk-averse market, the need for savings products is forcing banks to cope with higher volumes over a wider product range and requires a greater focus on product, process and system development and adaptation.

2.3 Loans

As with the maturity and increased competition that is all too apparent with the purchase of car or house insurance, competitive pressures have forced many lenders have been forced to provide a core product with a range of optional features for the customer to select. In return for fewer features (and less flexibility), the customer can get a cheaper loan and the bank can differentiate it’s product pricing against the all-inclusive implicit product from the competition.

A further trend in the lending market is the role of intermediary broker channel and the additional burden this presents to the banking systems.

With improved market intelligence and information modelling, the personal risk profile of a customer becomes an important factor product pricing.

The implications on the banking systems of these competing demands are for:

■ more transparent and easy to manage product catalogue;

■ break-up of the lending product into optional elements and supporting business rules that can be included or excluded;

■ straight-through processing to meet the demands of the concentrated buying power of intermediary organisations;

■ the introduction of the personal loan as the availability of flexible credit lines are considered too risky;

■ introduction of risk-based pricing in line with the personal risk profile of the customer;

■ new products such as tax-friendly bank savings, which enable banks to compete with insurance companies in tax-friendly products.

3 Core Banking Solutions

The larger retail banks in developed countries are workflow and transaction-focused to deal with the ability to handle large volumes. Many banks that were supported by in-house developed systems, shifted away to package based commercial systems that were customised to their needs.

With the maturity of the IT market and the demand for scalable technology architectures in the domains of customer relationship management, human resources, payroll and many other areas of the business supply chain, many vendors emerged to offer package solutions.

Software and hardware innovation has created major market opportunities for companies such as Sap, Oracle and IBM. The core banking market has also benefited from this wave of investment and the ensuing mergers and acquisitions between the various technology vendors.

3.1 Package Vendors

The dominant vendors from the 1970-80s and available products include:

■ Fidelity: Corebank is a customer-centric, real time, relational database solution delivered as a set of integrated components that are then tailored to fit each bank. Corebank can be delivered in COBOL on the mainframe zSeries platform as well as in a J2EE environment on either UNIX pSeries or mainframe zSeries;

■ Misys: Equation, Midas Plus and BankFusion. BankFusion is a pure Java SOA-enabled universal banking which is an integration with SAP NetWeaver platform;

■ Fiserv: ICBS supports all retail financial products and processes including savings, current accounts, loans, mortgages, transfer orders, collections and document management. Available on IBM iSeries and pSeries server technologies;

■ TCS (TATA): BaNCS Core Banking is an integrated solution that automates all aspects of core banking operations across entities, languages and currencies. BaNCS solution is an open standards based platform, using multi-tier architecture with international messaging standards which can be implemented on HP-UX and Oracle database.;

New vendors that appeared in the 1980-90s included:

■ Sunguard System: SunGard’s Ambit serves the retail banking, commercial banking, treasury, and trade requirements of banks worldwide. These banks rely on SunGard for straight-through transaction processing across front-to-back office operations, with online, real-time processing capabilities.;

■ Accenture: Alnova is Accenture’s custom banking solution that covers all aspects of universal banking; it handles traditional business products as well as products designed for wholesale banking and wealth management, all in an integrated, browser-based environment that crosses multiple delivery channels.

A three-tier technological banking platform, running on Mainframe, Unix and Microsoft .NET platforms using the most widely known databases (DB2, Oracle, SQL Server);

■ TietoEnator: The Core Banking Suite manages deposit and loan products and credit and debit cards. The system is independent of target technology platform and can be run on IBM S370, UNIX, Microsoft NT and also different transaction and database systems. In addition, the system does not depend on any system development tools;

More recently since 2000 includes:

■ Temenos: T24 and TCB. TCB is a core banking processing engine for large, complex retail banking businesses and is well suited to a phased rollout of core banking lines of business. TCB is based on the IBM Financial Services Data Model;

■ Delta Informatique: Delta Bank is a Unix-based core banking application with retail, corporate, trade finance and treasury modules integrated in a centrally deployed multi-tier, thin-client architecture with browser-based access. Delta Bank can utilise either an Oracle or Informix RDBMS;

■ Callatay & Wouters: Thaler has been designed as an integrated solution, but can be implemented on a modular basis which can be run on SAP’s business-process platform;

■ SAP: Transactional Banking is built upon it’s ERP foundation and NetWeaver integration technology. SAP partner with many other core banking solution vendors;

■ Oracle i-flex: Flexcube core banking is an integrated modular solution backed by Oracle and J2EE architectures.

■ Infosys: Finacle core banking solution has an integrated CRM module.

3.2 Recent Developments

Increased competition in the core banking systems packaged solution market has lead to the availability of functionally rich turnkey solutions that was only available to banks with an in-house bespoke system development capability.

The maturity of packaged solutions has improved significantly as the products have been rolled out across a large customer base. The vendor technologies and organisation have matured to satisfy business expectations in terms of agility, time to market and operational support.

The functional capabilities of package solutions have reached an equilibrium and are consistently available across the major system vendors. The non-functional capabilities of the package vendors have improved considerably to handle larger volumes across all functional areas as a result of the technology architecture improvements that have been made possible through the advances in hardware and software infrastructure.

Many vendor solutions are based on multi-tier architectures and can be supported by a heterogeneous infrastructure that can be sourced from a range of hardware vendors, operating systems and database technologies. The banks have a choice of operational platforms and infrastructure for deploying core banking systems to suit their budget and scalability needs.

The advances in middleware technologies presents a unique opportunity for a flexible integration layer to decouple application logic from mainstream shared services to introduce fine tuned business rules and service oriented solution architectures. The role of middleware to offer greater freedom, flexibility and improved time to market will become an important differentiator for those banks that are willing to embrace the benefits of these technologies.

3.3 Commercial Factors

For many banks in the emerging markets who lack the experience of managing package vendors and the complexities of embedding and configuring a package solution, there are many commercial challenges that must be understood.

Whilst a package solution is feature rich and can be operated as a turnkey solution, the reality of configuration versus customisation can turn a dream solution into a nightmare.

All package solutions have a fixed cost element which can be priced as a perpetual license fee or a variable license fee based on the number of accounts. License costs can be complex and can be imposed on specific functions, number of accounts, number of CPUs and based on geographic factors. These costs can be significant and specific expertise should be sought to model the cost implications of the licensing based on a 10 year lifetime of projected business scenarios.

Software license costs will not take into account the cost of infrastructure in the development, support and production architectures that will need to be managed throughout the lifetime of the system. The non-functional capabilities of each vendor solution will play a pivotal role in the final total cost of ownership of any selected solution. These areas must be investigated rigorously during the selection process to get an accurate understanding of the cost of change.

All package solutions will require an element of system integration, configuration, customisation and consultancy. These costs will generally be quoted as a variable time and materials cost which can run for a period of 3 months to 18 months. Once again, these costs can be significant and will require strong technical and commercial leadership to get the best results from the chosen package vendor and minimise the costs and disruption to the business.

The role of a bank’s IT department should focus on all areas of the project lifecycle to ensure that the design integrity of the package solution is consistent with an established methodology and supporting governance. Specific areas that will take on heightened imprtance will be vendor management, business analysis, architecture, design and testing. Weaknesses in any of these areas will result in increased costs and project over-runs.

Some solutions can be described as open systems where the underlying data model and source code is shared with the client. Other package vendors do not offer this flexibility and will require all changes to be undertaken by their own staff according to their schedule.

3.4 Outsourcing

Some package vendor solutions offer outsourcing and hosting as an alternative to in-house management of core banking systems. Many banks have decided to focus on their core competencies and outsource their non-core – but nevertheless mission-critical – operations to best-in-class service providers. The joint offering of infrastructure and software, whether in a business process outsourcing (BPO) mode or a ‘Software-as-a-Service’ (SaaS) approach, is a potential route to market for some organisations.

This may be an option for smaller banks who are willing to sacrifice flexibility in return for a rapid start-up and reduced TCO.

3.5 Future Direction

We would expect that over time the market will consolidate and the dominant players will align with the architectures and frame works of the big players such as SAP and Oracle. Indeed, many providers have dependencies and collaborations with SAP and Oracle.

There are many benefits for closer integration with these technology pioneers who own a significant portion of the technical architecture of the package solutions. The long term benefits of any alignment is a consistent product roadmap which will result in a positive evolution of integrated business intelligence, CRM, financial accounting, reporting, risk management and so forth.

4 Methodology

The scope of this section is based on our experience of the most frequent pitfalls for clients who have embarked upon a package system implementation.

The specific areas of focus include project portfolio management and governance, resourcing, supplier management, architecture and change governance, capability bundling and rollout, business benefits realisation and operational readiness.

At a very high level, the most immediate concerns facing Banks will be around the execution of strategy and the shortage of in-house resource to shape and deliver the business change.

These challenges will be magnified where a major technology investment and change is initiated with an external partner. The operational exposure and risk of disruption to the business will be that much greater as staff must continue to perform Business As Usual and manage an external partner to deliver the new capabilities.

Historically, most organisations will struggle to deliver due to a lack of appropriate preparation, planning and resourcing.

Other areas for concern include:

■ Insufficient effort being made in prioritising, aligning and committing the Business and IT to deliver the desired transformation in capability.

■ The silo approach to projects will mean that too many activities are in the plan with key resources being spread too thinly.

■ Lack of contingency planning around the phasing and rollout of business capability and the interim architectures that must be supported during the implementation.

The timing of the change must be carefully managed to minimise the risk of delivering during a busy period and so placing the organisation in an unfavourable position. Late or weakened delivery of benefits from an implementation would leave the organisation entirely unprepared and unable to deliver a service during the busy period.

Any planning and phasing of requirements and capability must take these risks into consideration and prepare appropriate contingencies to manage the “what-if” worst-case scenarios.

4.1 Business Case

Many strategic projects are often founded on a must-do basis and lack a formal business case. This is very often the major cause for IT project failures, as it becomes impossible to prioritise effort and measure success.

Organisations that implement a major project based on gut feel rather than any underlying business or IT related business case will face huge challenges.

The business case is a critical deliverable that underpins the strategic business and technical direction of the bank. The lack of a business case is a red flag item for the bank that must be addressed immediately.

Entering into a package selection without a supporting business case is very high risk and inadvisable. The business case must justify all project costs on the basis of perceived business benefits and creating a clear plan to realise those benefits.

The vision and desired business outcomes must be known up front, rather than defined piecemeal during project implementation.

A business case provides a solid foundation for success and delivering the best value possible for the investment. Most organisations consider the business case to be obvious and an administrative overhead. Our experience shows that a business case is one of the most important deliverables of any major project and will significantly aid the downstream implementation phases to prioritise and deliver the project to maximise return on investment and minimise total cost of ownership.

Recommendation

■ The business case must be treated as a critical document that provides the linkage between business strategy and delivery capability.

■ The business case should provide the basis for making sound investment decisions and provide guidance on the relative merits and priorities of the proposed change.

■ The business case approval should be a pre-requisite step before committing to a final solution, technology or integration partner.

■ A good business case can only be created through strong internal sponsorship and participation from key business units.

4.2 Benefits Tracking

The difference between success and failure is often very difficult to measure in most organisations due to the complexity of requirements, business processes and lack of clarity on ownership and strategy.

What is clear is that making best use of limited resources to focus on activities that produce benefits to (i) people or (ii) performance is a simple paradigm that will steer most towards near-optimal solutions.

The key to achieving this objective requires the capability to consistently MEASURE improvements and use this as a driver for change.

The process of targeting, measuring and analysing performance improvements accelerates the pace of change by:

■ Increasing accountability and transparency

■ Creating a traceable basis for action

■ Improving the understanding of cause and effect relationships

■ Builds continuous improvement into change program

Without adequate regard to benefits and the associated benefits tracking process, the project will:

■ lack direction

■ be unable to assess the impact of changes

■ create a sense of dissatisfaction or frustration

It is imperative that the team fully understands, supports and drives the release of benefits. Benefits tracking is a continuous process that will allow the implementation team to manage progress in delivering benefits and intervene effectively where they are off track.

Recommendation

■ Establish a baseline for accurate benefits tracking to support and mitigate against the risks.

■ Any decision to invest in the replacement of a core banking system should provide early visibility of the KPIs and gaps that will be the key driver for managing the budgets for time, cost and resource.

4.3 Governance

Many organisations understand the importance of Programme Management and often have an adapted methodology for tracking the completion of deliverables.

Our experience shows that very frequently project deliverables lack in the required level of quality and often become shelfware that serves no purpose in the downstream project lifecycle.

Often, the silo based organisational structures result in poorly defined roles, responsibilities and accountabilities for the ownership and production of project deliverables.

The lack of formal governance and enforcement of standards regarding the detailed structure, content and peer review of project artifacts results in an inconsistent mish mash of project documentation which is often seen as an unnecessary diversion by most project teams.

The introduction of a formal governance approach to managing projects is a critical part of successful delivery and this is especially so if external partners are contracted to deliver major projects.

Discipline and structure in the day-to-day management and accountabilities of the technical delivery teams and suppliers must be established and formalised at the outset.

This is a non-trivial activity and requires considerable detail around actual processes and approach. Critical to this is to source experienced leaders to engage with the business and IT teams to measure progress, monitor risks and assess the impact of issues, operating at a level above that of the individual work streams.

Quality management is fundamental to achieving integration of the organisation and its deliverables, through adoption of consistent terminology, standards, procedures, techniques and methods.

Recommendation

■ Establish a Programme Office and define a robust and pragmatic delivery framework that is focused on adding value and one that sends a clear message to all partners that this organisation is mature and able.

■ Enforce a formal and disciplined structure to reduce the temptation to cut corners and ensure that decisions are made pro-actively, with leadership team buy-in and authorisation and ensure that people are operating within the recognised framework.

■ Formalise the role of the Programme Office as a hub for decision making, escalation management, risk management and all matters relating to prioritisation, budgets and resourcing.

■ Establish the Programme Office as the natural owner and manager of the business case by delivering to the principles of the business case with the available budgets and resources.

4.4 Portfolio Management

The delivery of this change programme will result in several solution work streams to deliver and manage the release of benefits. An integrated delivery strategy is crucial to the success of any programme where resource and budget are scarce. In addition, there is likely to be a high degree of interdependency between work streams. This is ultimately a positive as the creation of a new and standardised technical architecture will result in many shared components and common processes which when integrated and deployed into the organisation will be the major source of benefits. However, during the design and implementation stages and also during the interim stages of phased deployment, this will introduce significant tensions and challenges to the smooth running of Business as Usual.

It should be accepted that during the implementation of a complex cross functional programme of work the strategy may have to be adapted or changed. This is a key area that is often over-looked during an ITT process where the competitive responses are seeking to minimise scope and inter-dependencies in order to deliver on-budget and on-time.

Managing the internal portfolio of projects against this backdrop and making investment decisions in new infrastructure, applications or partnerships requires a detailed risk assessment and appropriate strategies defined to provide guidance to the governance body.

In addition, many projects will resist change and seek to work-around any inter-dependencies with a strategic solution that does not fit within the current scope, timescales or budget. It is absolutely critical to get a firm grip on these projects and there business sponsors to see the bigger picture and agree that in some cases sacrifices and compromises will be required for the greater benefit of the vision, strategy and desired outcomes.

Recommendation

■ We would recommend a detailed review of your ongoing tactical and strategic projects to assess the likely impacts and inter-dependencies on the proposed programme that is currently out to tender.

■ When major programmes are seen on the horizon, most projects will make assumptions and design decisions that certain key features of their project requirements will now be provided by the new technology.

■ Project architects who are often silo resources will not have the necessary facts or leadership qualities to navigate the projects and business towards more informed solutions during this period of uncertainty on the final supplier or technology selection.

■ The outputs from this activity would identify opportunities for cost savings and efficiencies that may otherwise be missed. It would also serve as a valuable input into the baselining process and identify strategies for dealing with any potential hotspots.

4.5 Change Management

The scale and reach of this project is significant and will require a change management approach to ensure there is alignment of people, culture and behaviours and to sustain the change. A change management methodology will focus on:

■ Creating high performance teams who can measure and deliver success.

■ Instigate necessary culture change by aligning aspirations and values to that of the new organisation.

■ Install a continuous improvement culture and mechanism using effective knowledge capture and ongoing learning.

Many organisations achieve some success at the communications aspect of the change but they very rarely follow through on the detail that is required to realise any sustainable benefits. Usually the risks and symptoms that surface at the programme level will include the following:

■ Any new business processes or amendments will not be sustainable and staff and business units will be tempted to return to the old ways of working thereby eroding the benefits of the new solutions.

■ Teams and projects will resort to a silo and will struggle to deliver in a culture that aspires to be joined-up.

■ Leadership is not properly aligned and there is no process in place for ongoing re-alignment on strategy and behaviours.

■ Tracking of benefits is vague due to an ill defined baseline. The risk is that insufficient evidence of benefit release leads to continued inefficiencies going unaddressed.

■ Without empirical evidence, there is no belief and therefore buy into the perceived benefit.

Recommendation

■ We would recommend identifying a dedicated change management leader and appropriate support to perform the change manager’s tasks of process and cultural change, leadership alignment, benefits management and the creation of high performance teams.

■ Perform regular temperature checks to assess the organisations understanding and acceptance of the forthcoming changes.

4.6 Work Plan

This phase of the ITT process is not focused on reviewing or agreeing detailed work plans. As a result, any vendor pricing at this stage will be unrealistic as it will not relate to the specific requirements of Banks. A detailed project plan listing the major work streams, tasks, deliverables and milestones will provide valuable insights into where the hot-spots are likely to occur, areas of overlap and contention for key resources.

Aligning the plan with internal Business As Usual activities and the availability of key business and IT support staff must all be factored into the decision making process. The deployment and management of project resources requires careful planning to avoid delays and smooth progress to a detailed work plan.

Recommendation

■ Create a detailed project plan with clearly identified work streams and resources. At this stage, the resources should simply define role and skills. The plan can be used as a sound baseline for prioritising project activities and resources.

■ A detailed schedule should be refined as the ITT process matures and also used as basis for comparing the various vendors and their specific resourcing profiles. This will also serve to identify any major gaps or omissions from each vendor.

4.7 Resourcing

The overall success or failure of any project will depend on the quality of the deployed resources. The importance of detailed planning was discussed above.

The next level of detail in the planning must focus on the mix of internal versus external resources and specific skills that will be required throughout the key stages of the project.

Any gaps or lack of commitment in the area of resourcing will have an adverse effect on the project and the overall morale of the delivery teams. From past experience the usual pitfalls are:

■ Poor team selections made on the basis of availability rather than any formal skills or capability for the targeted roles.

■ Where external contract or consultancy resource is deployed, there is no formal succession planning or knowledge transfer.

■ Key members of teams are already heavily involved in business as usual and are unable to contribute fully to the programme.

■ Key resources are expected to contribute to the programme stream and in one case leading a large part of a stream without due consideration of business as usual constraints.

■ Resource recommendations by the selected partner have not been addressed adequately.

Recommendation

■ Clearly define the project team structure, roles and responsibilities.

■ Select team members based on skills and capability.

■ Where resource gaps exist identify cost-effective alternatives and put in place a contingency plan to address the gap and plan for succession and knowledge transfer.

4.8 Architecture

A critical part of any IT organisation is it’s Architecture function. This role is traditionally misunderstood and misrepresented. The role of a technical architect is to bridge the gap between business strategy and IT strategy. The architecture function typically falls into one of three areas:

■ a enterprise-wide role

■ a business or functional role

■ a project-based role

Most organisations are reactive to the business and generally find appropriate resources to support the project architect function. The enterprise and business architect roles are often spread out amongst key business or IT staff, but rarely the responsibility of an enterprise architecture function or a business architecture function. As a result, it is very difficult to enforce any governance or standardisation based on sound architecture principles such as a unified security architecture, or a common portal or content management system. Often each and every project will have specific views on this and will follow the path of least resistance to satisfy the requirements of the project.

The role of architecture is very far-reaching and defines the fabric of the information and security model of an organisation and the critical infrastructure components that support the business. In addition, the role of architecture shapes the way in which solutions are prototyped, designed, developed, tested and deployed. Getting this right can pay huge dividends and be a significant enabler of business benefits realisation.

Banks approach is radical and admirable in many respects as it aims to deliver a step change in IT architecture. Potentially this project could redefine the IT landscape in one swoop. As a result, I believe it also introduces some fairly significant challenges and due diligence activities to validate that the final solution will satisfy the current and future business needs.

Recommendation

■ Invest in an architectural framework to manage the transition from the as-is to the to-be architecture in a controlled and robust manner.

■ Select technology products based on capability and fitness for purpose to support your business requirements.

■ Select technologies and architectures that can be easily and cost-effectively resourced.

■ Identify architectures that eliminate duplication and redundancy.

■ Select technologies based on a clear total cost of ownership model.

■ Ensure that technologies are validated and proven before final selection. Ideally create competitive tension to identify the strengths and weaknesses of key architecture components.

■ Invest in an architecture function that can sustain and manage future changes and extensions to the chosen architecture.

4.9 Partnership

It is absolutely critical to select an overall Systems Integration partner who can then act as the single point of contact with overall responsibility and accountability for delivering the final solution. A partnership and collaborative approach where the roles and responsibilities of both parties contribute equally to the end solution is essential to the success of this programme of work.

It is also needed to ensure that the right balance of expertise and practical knowledge is used to build the solution. Too much external influence and the solution may not be the most appropriate to that environment, too much internal influence and there might not be enough innovation to make widespread change.

Based on previous experience, it is normally far better to engage with a technology and product agnostic Systems Integration partner to deliver the overall project rather than engage with the product vendor directly. This may seem bizarre, but the reality is that product vendors tend to understand their products better than they understand their customers. An integration partner tends to focus on the customer requirements and manage the delivery and client expectations accordingly.

From past experience, a product vendor lead implementation of a licensed turnkey solution that requires a complex and costly integration based on a time and material contract is a high risk strategy. The Bank must be clear that the end to end accountability of a working and production ready solution must be the responsibility of the chosen technology partner. Wherever possible the commercial terms should seek a fixed price delivery model to minimise risk and assign accountability.

Recommendation

■ Focus on an SI lead implementation partner as this should offer better value for money and lead to better knowledge transfer. Product vendors tend to focus on revenues through training, education and support. As a result they have far greater flexibility to cross-subsidise pricing so that the up front cost during competitive tender appears cheap, but often turns out to be far more expensive over the solution lifespan.

■ Adopt a partnership approach based on fixed price contract and some element of risk/reward for delivering key milestones and performance criteria. This is often an excellent incentive to identify a partner that is willing to engage on the basis of benefits realisation rather than delivering a solution that almost works!

■ Where possible invite the partner to identify tasks or areas where a time and materials based consultancy may be more appropriate. This will identify weaknesses or uncertainties in requirements and capabilities early on rather than during the implementation phase.

5 Summary

We believe there is sufficient information in this report to highlight where we see the greatest risks for Banks. These recommendations represent a best practice approach to containing these risks.

Banks should undertake a detailed diagnostic to investigate the areas identified in this report. This should provide a stronger foundation for success and state of readiness to:

■ Deliver and execute on the business case;

■ Provide project leadership and accountability;

■ Align culture and business processes;

■ Gain stakeholder commitment and participation;

■ Achieve clear and timely communications;

■ Prepare and work to an integrated plan;

■ Create the headroom and capacity to absorb the change;

■ Identify a partnership to build a new and robust enterprise architecture.

Without the right level of expertise, resource, alignment and commitment to this project, Banks runs the risk of not delivering in time or not delivering at all. Without the release of benefits from the project, Banks runs the risk of disrupting it’s business and alienating key stakeholders.

All of these areas are very tightly inter-related and getting the wrong balance will cause delays to the execution of the strategies and the unknown nature of the likely benefits to be released.

We recommend that the current resource and skills capabilities be assessed immediately with a view to putting in place the necessary contingencies to provide greater clarity around some of these areas. We believe that this approach will pave the way for making the correct choices and ultimately delivering the right solution on time and to budget.