There is great risk involved in making strategic decisions to change a complex organisation`s technical architecture, without detailed knowledge of the systems affected. Yet few strategic decision-makers have easy access to this detailed knowledge.
Faced with this dilemma, IT strategists at one of the leading South African banks were about to launch into the important task of deciding which data in the organisation would be pulled out of the numerous systems, and consolidated into central master files.
The master file strategy was crucial to ensuring that important data in the organisation was stored in a single location where it could be updated and accessed via common modules. For example, if a customer master file were implemented (replacing a number of localised customer data stores in systems used by individual departments), this could ensure that updated contact details received in one branch would be available for use across all departments and channels. Not only would this improve the integrity and accuracy of the information, but it would also simplify the process of updating data being utilised by numerous systems.
A lack of data to support decision making
The Bank was using IBM`s Information Framework (IFW) for the banking industry as a basis for defining the master files that needed to be implemented. IFW proposed that, ideally, there were nine data concepts that merited master files.
However, to decide on the extent to which the IFW master file approach was to be rolled out at the bank, IT strategists wanted a key question answered: "What impact is this master file approach going to have on the bank`s current systems, and what is it going to cost us?" The trouble was that there was no single source of information in the Bank that provided a sufficiently comprehensive view of the current architecture.
The lack of availability of a current architectural model and up-to-date, consistent systems documentation was a persistent problem. This not only hindered IT strategists from making informed decisions, but meant that project teams were tasked with doing current systems analysis ad nauseam. System experts were in the unfortunate position of having to repeat their knowledge of the current systems to a constant stream of project teams.
Having decided that documenting the current architecture and systems was a must, there were a few key concerns:
* How could the vast and complex system architecture be documented quickly and concisely?
* How would we bridge the gap between various perceptions among system experts as to what constitutes a logical system in a mainframe environment?
* How would we ensure that the systems documentation was maintained in a constantly developing environment?
BSG digs into the detail
Because BSG are well known for their thorough approach and attention to detail, they were approached to investigate and document the current technical architecture in a format useful for strategic decision-making, as well as project work. The BSG team developed and applied a structured approach to efficiently and systematically uncover the details around what systems existed in the Bank, what functions they performed, what interfaces they had to other systems, and what data they contained.
BSG consulted relevant technical system experts to gain the necessary understanding of each system within the Bank. Rigorous analysis revealed that system experts were not in agreement about the interactions between their systems and those "owned" by other stakeholders. Neither did all agree on what constitutes a "system" in their mainframe system environments. BSG played a key mediatory role in ensuring that communication between all system experts was productive, and that it ultimately led to an agreement regarding logically defining systems and definitively identifying the interface details between systems.
The team needed to bear in mind the various audiences that would ultimately be using their work when documenting the findings of the exercise. The agreed upon approach was to perform analysis at a "mile wide, but inch deep" level. The documentation covered a huge number of systems, but the detail behind each system did not need to be drilled down to the lowest level. Thus system documentation contained the necessary level of technical information, but was presented in a fashion that would be easy to understand for a business stakeholder.
Some of the key deliverables to come out of the exercise included:
* System Write-up Documents (detailing each system and its interactions with other systems)
* Detailed As-is Architecture Landscape Model (detailing all interfaces for each system. The low-level detail of this model means that it is more relevant to technical stakeholders.)
* System Context Diagrams [detailing all external (i.e. external to that system area) interfaces for each system area. These context diagrams provide a high-level overview that is more relevant to business stakeholders.]
* IFW Data Concept Matrix (detailing which of the IFW Data Concepts, e.g. Involved Party, Product, Arrangement, etc. are found in each of the Bank`s systems. The intention of this matrix is to guide detailed analysis teams, for each of the potential master file implementations, to specific systems of interest in their analysis).
Wrapping up
At the end of this exercise, BSG shared their insights gained during the project, leaving the Bank`s Architecture division with a solid knowledge base and practical recommendations for the maintenance and ongoing use of the information gathered. Consequently the Architecture division have commenced development of a repository, which will allow the work to be easily updated and thus kept relevant. A modelling tool has been employed to allow users to manipulate the information to retrieve the specific views and data subsets that they require.
By attacking the problem with a structured and determined approach, the previously unmapped territory of the Bank`s systems had been translated into an orderly repository of documents. BSG`s delivery focus and attention to detail have ensured that the work can be used to inform strategic changes in the Bank and reduce analysis time on IT projects.
Share
Editorial contacts