Filename:
44085_NNSS ergänzen aus UPI_Konzept_v1.0_compressed.ppt

Purpose:
In Switzerland, a new Social Security Number (NNSS in German) was introduced to uniquely identify each insurant person. As the databases in all VISTA-Cantons initially only contained the old number and an NNSS could not be assigned to each case, many partners in VISTA could not be identified correctly and duplicate partners were created.

The customer asked for a solution to reconciliate the VISTA data with the database of the central insurance agency (UPI-Registry). As initial tests have proven that normal SQL scripts would run into timeouts due to performance reasons and the amount of data, I created the mentioned concept which uses an iterative, status-driven approach which would allow an execution over several transactions.

The customer appreciated this concept for the traceability and flexibility of this approach.
 

Filename:
TOD999_PV-Overview + Handover.doc

Purpose:
This document serves as a handover document for new PV architects. It explains some complex and important topics in a summarized form, addresses open issues and workarounds and provides links to important documents and tools. With this document, a new PV architect should be able to get a complete overview of all relevant tasks in PV.

For the "Invalidity Assurance" (Invalidenversicherung, IV) business, the customer decided to buy an existing solution ("GILAI") from another provider (GLOBAZ) and have it integrated into the VISTA context. At the beginning it was only clear that PV data "somehow" needs to be replicated to GILAI. That was the point where the customer came to me. First, I drafted a concept which required a decision about the replication mechanism. Central Architecture, me and the customer agreed on my suggestion to use a very similar way like which was already in place to replicate to the billing system (Abrechnungssystem, AS). The other possibility to replicate data in the way the Back Interface (BI) does for the legacy systems would have been more complex and RDC had no know-how about it because BI was developed in LDC only.

After this decision, I defined milestones for this subproject, considering the target release date and the team's capacity. Then, I invited architects from GLOBAZ, SVA users who knew the IV business and the product manager from IGS to Zurich in order to have a common understanding of the solution and to finalize a mapping table. GILAI has a very different data structure than VISTA, but on attribute level we were able to map each required attribute from GILAI to a corresponding field in VISTA PV. In this meeting we could also reduce the complexity by reducing the required mapping tables.

In another meeting with GLOBAZ and IGS, we could agree on the data access on VISTA, also considering data security by using a federated database system. After this clarifications I could further refine the planning and define all "features" (subtasks for different development teams):

• PV feature to implement the replication batch
• Another PV feature for the possibility to have an instant replication via button click
• DB feature to create new tables and views
• CS (Common Services) feature to extend an existing clean-up batch

Each feature contained effort for analysis, implementation and design and was planned according to available capacity for each team and their cross-dependencies. As the replication batch was dependent on new constants (Code Management values) and the new tables the DB team had to start with it's feature. The next subrelease was used to implement the replication batch. With this subrelease, the customer could already start with some testing activities, whereas the instant replication button and the clean-up batch had lower priorities.

In IK, most of the batches have been designed with priority on business correctness and not on performance. Also, for a long project phase the customer tested with a "medium-size" mandator only (Canton St. Gallen SG) where many test cases have been executed successfully with this workload. But as the biggest mandator (Canton Zurich ZH) went live, we experienced performance issues like batch time-outs and rollbacks.

After many incidents in production and negative feedback from mandator ZH, IGS accepted my suggestion to have changes to improve the performance for the batches with the biggest workload. I have identified several batches and suggested a priority, assigning the mass booking batch as top priority. I created the following Change Features:

• IK Feature to redesign the mass booking batch (modelling, coding)
• BC (Batch Controller) Feature to update the batch plan (new batch definition)
• OS (Output System) Feature to update the error list document

I planned the development and target releases according to the timeline when IK would have a local landed resource from RDC. I could convince the customer about this dependencies and target releases, as I also mentioned the possibility to have the possibility to sit together with the developer and directly address inputs, questions and corrective measurements. Plus, we could directly develop against production data on SIT (System Integration Testing) environments.

Together with another architect and the developer I identified the biggest bottlenecks and defined corrective measurements, e.g. loading only IDs during the "calculate workload" process instead of entire Data Entities (DEs). I gave an example of another batch from PV where we introduced a workload splitting mechanism which would prevent timeouts. And, referring to a current production issue, I suggested to exclude the list printing task into a separate new batch.

The "external" features (BC / OS) were delivered on time which also allowed a first version of the new batch in an early subrelease. As promised, the customer could test this first version with a huge data load and immediately address small correction measurements. The new batch was set live successfully and almost more noticeable, we were finally able to process a hanging mass booking portion and deliver the required documents to the customer.

Based on this positive outcome, the customer agreed to have more batches reworked in a similar way.

Beside my normal job roles I am the delegate of the VISTA release manager on IBM side. Along with tracking the implementation state of defects and changes, the most noticeable task is executing the Finding Clearing Board (FCB), which is a telco twice per week.

In this meetings, the product managers and lead architects present new defects which were found recently and have to be planned for an upcoming release. In this calls the key is to identify the risks, severity, business impact, workarounds and efforts of each defect. All of these facts have to be considered to suggest the final target release. For low and medium severe defects the target release is often quite easy to agree with. Critical bugs are a different story, however.

It happens that a defect is too severe to have it implemented with the next official release (which could be delivered up to three months later). In such cases, an emergency interim build (iFix) is required. As this is connected with high efforts on all sides (development, infrastructure, build team, service provider and test management), these iFixes need to be negotiated with all parties.

In this role I had to manage many iFixes. My responsibility was to get a confirmation from IBMs build and development teams about a delivery date and time. Sometimes the customer wanted a very early delivery which required overtime for several affected resources. Or the timeline was only reachable with weekend work which needed to be negotiated with the management in RDC India. On the other hand, I could agree in the name of IBM to deliver a very big package of defects but gaining one or two days of development and testing time.

There were also defects which had no visible impact on the end users at the SVAs, but generated many automated "event monitoring tickets" for IBM AMS. In such cases I also requested to deliver a defect earlier than planned (i.e. as iFix) in order to prevent floods of AMS tickets.

Despite the additional effort for iFixes, the client satisfaction is impacted very positively for each successful iFix, as we can prove to fix very important bugs in a short time.

VISTA was set live despite many open points, especially in IK. As IK is a data driven application sends and retreives data from and to other SVAs, even small bugs can cause  a massive amount of wrong data in production. Consequently, the IK ticket count for AMS was increasing since go-live.

Additional resources, an "IK-Taskforce" on Incident Management side, implemented changes and defects could stabilize the growing backlog trend. Also, at first the ticket backlog did not have any financial or contractual consequences. This changed however in March 2013, when it was decided to apply the service level agreements (SLA) for IK tickets, too. This required negotiations with several parties.

First, I could convince the IGS management that we can accept and handle ticket resolution times within the SLAs, but we would require a special treatment for the "old" tickets, otherwise dozens of tickets would escalate at once, with a heavy impact on the financial side. My convincing argument was that it would be of no benefit for the mandators (end users), as tickets can only escalate once, and then IBM had no further commitments on such a ticket and would concentrate not to escalate new tickets.

The commitment I had to give as IK application leader was to further negotiate with IGS product- and incident management about important and urgent tickets. We agreed on the following process: IGS would define small lists of tickets which should be prioritized from the backlog, i.e. moved into the normal operating mode including SLA resolving times. For each tickets in these lists I would (after the team's feedback) propose a date, when we could achieve a final resolution respectively on which date the normal SLA countdown would start.

For some tickets I could even arrange a quite late resolving date, as I could argument that the required effort to resolve a ticket would be much lower with a new release.

The outcome of all these negotiations are positive for all sides: tickets are resolved considering the real severity of the end users, and in a way and time frame to which both IBM and IGS have agreed. And so far, IBM didn't have to pay any financial penalties due to escalated tickets.

After a project phase in VISTA (VISTA Delta Development), I additionally took over the role as application lead for the applications PV, IPV and BI in the new project phase "VISTA Change Project" and "VISTA Rollout". These were project phases with a rather strict budget and expectations from customer side. The tasks and challenges for my applications were:

• Identify and prioritize important changes
• Analyze and plan them according to the available budget and resources
• Request additional budget / resources in case of important new changes
• Track the overall progress plus the detail states of each changes
• Keep to the budget
• Include defects in the calculations / planning
• Report the status of the application to the management weekly

As all these applications were relatively small in respect of the resources, big changes got also a massive impact on the release planning and budget. The rollout of mandator Liechtenstein (LI) had an additional risk: LI needed to support payments to accounts in foreign countries, something which was not foreseen for the Swiss Cantons. The technical restrictions resulted actually from the legacy system which was not able to support them.

This new requirement came very late from the side of mandator LI, but they announced that they cannot go live without this Change. The rollout deadline was fix, but I could successfully request an additional build before rollout. This allowed more testing time and one more iteration for fixing Defects. Technical problems with the legacy system were mitigated on an organization level: instead of a huge modification in the Back Interface (BI) logic, I analyzed which error messages respectively event tickets are to be expected and how Incident Management and the Legacy team could address them.

In the testing phase we found out that the data PV passes to the billing system (Abrechnungssystem, AS) were not compatible for certain countries. As I could prove that this is not a mistake on our side but a restriction coming from the SAP module, we offered to correct the cases in a new Change, to be delivered in an interim build (iFix resp. iChange) before go-live. This could be performed within our capacity, the budget had to be increased only slightly and the entire requirement could be delivered successfully on time.

By the end of 2010, IBM and IGS have agreed to initiate a test automation subproject within VISTA. The target was to create a suite with a huge list of automated AIT test cases which could be executed "on mouse-click" over night for release verification activities.

I have been identified to take over the lead for the PV test automation. The identification of test candidates and the organization of the preparation activities and handover to the test automation team were under my responsibility. In this time I reported to the VISTA test manager and my application leader.

In a team meeting we decided to establish a common tracking sheet for all applications. As all testcases were registered in ClearQuest Test Manager (CQTM) and could be flagged with different states, the Excel sheet was extended with the functionality to get the latest state of each testcase directly from CQTM.

After the capacity for PV had been defined I could start with the identification process. This was generally done by prioritization based on the testcase description. In this step a number of old testcases could also be marked as obsolete.

One of the first challenges we encountered was the fact that all AITs were written in German only. I definitely did not have the time to translate them to English for a handover to RDC. I addressed this risk by taking profit from a landed resource: in regular sessions, we went through some testcases; I explained in English what the testcase is about while she was taking notes. After each session, she could independently rewrite the testcases in English and assign them to the test automation team.

A second phase of this subproject was a workshop in India, in which testers from the SVAs were accompanied by IBM architects, in order to support and review the automation progress. The management set high progression targets which IBM should present to the customer. In order to achieve these targets, I identified groups of test cases which used the same set of dialogs, because "preparing" a dialog for automation was one of the most time-consuming task. Before the workshop started I already communicated which dialogs should be prepared first. Like this, the PV team could reuse these components and progress very quickly. Finally, PV has overachieved the targets.

To ensure the quality, we made daily reviews of the testcases; for the test coverage I mapped the use cases with the test cases and defined a minimal coverage rate. Based on this result the remaining automation candidates have been assigned for further processing.

PV contributed considerably to the overall test automation target, which was a critical point for the acceptance criteria and an important requirement for the Go-Live of VISTA.

My first leading role in IBM was being application test team leader (ATTL) for PV. In this role I reported to the application leader and IBM's test manager. I supervised two testing resources in RDC and testers from the SVAs.

PV had a collection of around 500 application integration tests (AITs) which I had to maintain. The maintenance included to check if business rules have changed or any other development made test cases obsolete or candidates for an update. For this we ran a complete regression in a team with four customer testers and me as coordinator. I defined daily and weekly targets and assigned testcases across the team in a mutual understanding.

I let the team helping each other in a collaborative environment but tried to address their queries with priority. The progress was good and PV had an up-to-date regression suite as outcome.

A similar task was required when the automation of AITs started. I had only one tester from an SVA but also a landed resource from RDC and two test automation architects in India. Before a three-weeks workshop in India could start, we had to prepare many things, most obvious the translation of the German AITs. We could prepare enough AITs for the workshop itself and we could therefore optimize the work distribution during the three weeks in India. PV has overachieved it's targets.

When the former application leader left the project I also inherited his duties and managed defects, changes, capacities and reports for the management for which I used ClearQuest, SharePoint and reporting templates from the project. I kept the established communication ways with the customer and RDC with weekly meetings and calls.

Despite some fundamental changes, PV remained to be a stable application and a team which delivered changes in a good quality.

For VISTA, 2012 was the year of the "accelerated rollouts": each month, a group of new mandators (SVAs) went live with the new system. During this time I was the deputy of the application leader. In his absence I managed the capacity planning, tracked the development progress and any risks for successful live-deployments.

With each new SVA in production, the required AMS effort for handling tickets and defects from production increased. In Q4/2012 the current application leader left the project and I took over, among my other roles as architect of IK and PV. During this time I put a high attention on the incident management. I established a biweekly short "standup meeting". As preparation, I went through the new tickets and added them in a tracking list. During the meeting, all team members provided inputs to these tickets. We marked the tickets as known or unknown problems and assigned them to the Architect who had the best background knowledge and who could resolve it with the least effort.

For known problems we listed the corresponding defects or changes. As this list was public and after some time everybody knew about open defects/changes, data corrections or at least which team member already worked on a similar problem and could provide help or take over a new incident.

Of course, the development tasks could not be ignored, as IK still had many changes and defects to implement. On one side, the RDC team had to be managed. I used weekly calls with the lead developer in RDC to ensure LDC and RDC plans were matching.

When IK encountered an increasing number of not-reproducible defects (on AIT environments in India) and changes with issues, I requested and initiated a landed resource for IK. The benefit for the entire team was enormous: problem scenarios from the SIT environments could be debugged and analyzed on the same systems. Changes could be discussed and handed over face-to-face and in a fraction of time. Additionally, the developer could provide valuable inputs for ticket analysis.

My role also expected a close contact with the customer, respectively the Product Manager of IK. We agreed to have a biweekly (short) meeting to ensure we both have the same understanding of the priorities. Additionally, we discussed and prepared the weekly status meeting for the management. We achieved to established an honest, productive communication between us and the spirit to face challenges as a team.

As IBMers we continuously need to overachieve the client's expectations. Understanding his business is the key for a productive collaboration. Important is also to think out of the box and react to business requirements, which might be formulated via a change request in a very condensed form. In earlier phases of VISTA we had examples where changes needed to be reverted partially, as some dependencies had not been considered.

As a lesson learned, I targeted a flexible implementation for the bigger changes. Often this could be achieved via code management parameters. Even though PV does not have much business logic, as one of the most central application a wrong parameter could influence the entire system.

One example of configurable - and therefore future-proof - changes was the PV notification. In short, if something changes on the basic data of an insured person in PV, a message should be triggered to the business applications which could then handle such events automatically or creating a note for the users. In the conceptual phase, it was unknown which applications would implement this concept at all. And if, many details were open at that time. Considering these uncertainties the implementation had to be able to be compliant with future business decisions in this context. Therefore, the notification logic in PV addressed all undefined points with parameters. Second reason for it was the different organization of the SVAs. Whereas for some SVAs PV should.inform the pension business when a person got married, it might be obsolete for other mandators. We delivered a solution which could handle entirely different usage profiles of the SVAs, from excluding one dialog or batch from triggering notifications to entirely turn off this mechanism - and be it only temporarily.

I used similar approaches for other changes with a big impact, like the integration of another system (GILAI) into VISTA or foreign payment addresses in Liechtenstein (see CC3 & CC12).

PV has also proactively suggested some changes, which we believed could be of great use for the customer. I understood for example the high usage of payment addresses - as paying out the insured persons is one of the core business of the SVAs. As the SVAs still use some legacy systems for some business applications, all payment relevant data has to be replicated from VISTA to legacy. As replicating bank basic data was not in the initial scope and manual database operations were required in case a bank changed or got created, I could analyze the effort and impact to add this functionality. Unfortunately, the efforts were too high for the customer, so the feature had never been implemented, even though the costs would have been compensated already.

At least, we could help the customer to optimize the manual process and even outsourced part of it to RDC, enabling a time- and cost-efficient way for a core business process.

Understanding the IK business of the SVAs is as challenging as important. IK is an extremely data oriented application and business. But the structure, the quality and quantity of IK relevant data is just the beginning. It is rather the origin and target of the data that is sent from and to the IK application which is important to keep in mind: IK is a data receiver and provider from and to all other SVAs in Switzerland / Liechtenstein.

Simplified, the IK application of one SVA sends (among other) income data to the central compensation fund (Zentrale Ausgleichsstelle, ZAS) which by itself distributes the data to all other relevant SVAs. The other SVAs might or might not use VISTA. Delayed answers, unprocessed requests and data in a wrong format or wrong from a business point of view exposes the erroneous SVA to the entire social insurance system in Switzerland / Liechtenstein.

As lead architect it was my responsibility to assist the customer in setting priorities and to show him risks and chances in this core business. For example by suggesting optimization changes for the data export batches or by prioritize AMS tickets in this aspect. Sometimes this even meant to disable validations which would actually be correct, but are not followed by ZAS itself and can block a business process.

In order to supervise all data import and export batches I provided an extensive monitoring SQL to the IK team and also to IGS batch operation. This enabled both parties to have a common understanding of the system status and a discussion base for the way forward in case of aborted batch runs.

But also SVA-internally the data flow had to be monitored. Actually, IK can also be described as a cross application, as it is the main input provider for the pension (RE) business and some legacy applications. Knowing about these dependencies is essential for having a stable IK business - and at the end correctly paid-out insurants.

As described earlier, VISTA was initially planned to be deployed in three phases (E1 - E3). After several delivery issues and delays it was decided to discontinue the phase 2 and 3 applications, freeze the development and ramp down these modules in 2008. The module "Contribution" (Beitragswesen, BW) was one of the affected application.

In July 2011, IGS has asked IBM to provide an offer and solution approach for finishing BW. The target of the solution should be to replace the current BW application on the legacy system and to have it integrated into the VISTA context. The offer should cover the following points:

• Effort estimation for the BW legacy replacement of 4 sub modules
• Cost estimation for implementation and support till go-live (SIT, PPT, rollout etc.)
• Schedule for scope refinement, ramp-up, delivery and testing
• Assumptions and preconditions
• Technical solution outline and variants

I joined this proposal to draft a technical solution for integrating a submodule of BW into VISTA. It matched my experiences in data replication functionality (like the Back Interface BI in VISTA), as a similar approach was to be considered for this proposal.

To get a basic understanding of BW and to identify the required components for the new solution, I got in contact with a former BW architect. With his input, I worked out a possible solution (plus an alternative), let it review by the leading central architect, estimated the required effort and integrated my part into the final presentation and estimation sheet.

In May 2012 the IBM AMS VISTA Management asked all Architects to provide suggestions for new changes which should extend or improve the current system - and to generate new business for IBM.

I was able to provide the following list of possible changes:

PV

• Extended support for foreign banks and bank fusions
• Usability improvements for French and Italian speaking users
• Redundancy cleanup redesign / finalization
• Extended validity checks for historized objects

IK

• Printing fallback mechanism in case of missing employer information
• Provide letter salutation in case of documents for non-natural persons
• Improve the handling of multiple-assigned billing numbers
• Redesign crucial batches to improve stability and performance

The total estimated effort (i.e. business for IBM) was approximately 100 person days.

In the meantime, some of these changes were accepted and assigned to IBM. I continue to provide further suggestions for changes for each AMS ticket which describes a problem but which is not a defect per definition.

As a member of GBS Switzerland I attended regular meetings (All Hands Meetings, AMS Roundtables) to be informed about the organization structure and business updates from the Service line.

I learned that GBS is one of the two major divisions of IBM Global Services - GTS is the other one. IBM GBS is the world's largest IT consultancy service firm and accounts for around 1/5th of IBM's global revenue. It is currently divided into seven service lines: Strategy & Transformation (S&T), Business Analytics and Optimization (BAO), Application Innovation Services (AIS), Application Management Services (AMS), Mid Market, SAP Applications and Microsoft Applications.

I followed organizational changes with great interest, e.g. when IBM Switzerland and IBM Austria together formed the "IMT ALPS", which was later on consolidated with IBM Germany into a new "IMT DACH".

Within VISTA I could collaborate with colleagues from other service lines and countries (Germany, Austria, India), and could also work on a typical project handover from AIS (development) to AMS (maintenance).

IBM is a leading company in Global Delivery (GD). As a worldwide operating enterprise, IBM makes heavy use of outsourcing parts of projects and business into countries with lower cost rates. An additional benefit is the huge pool of employees with skills in almost every relevant topic. IBM has delivery centers in Brasil, China, India, Romania and further locations.

Organizing a GD project is challenging as many GD troubled project showed in the past. Very often the root cause are cultural differences and resulting gaps in expectations, communication, quality and delivery excellence.

In order to address these problems, IBM Switzerland initiated a new approach with the "India Program" in 2007:

• Send a number of Swiss application developers to India for around one year
• Work in Indian teams as “normal” application developers
• Learn about India
• Return to Switzerland
• Take over leading roles in projects with India
• Positive effect for customers and IBM

I was one of the 11 assignees to participate in the India Program. After some cultural awareness courses we got technical training in Kolkata, India, together with Indian new hires. Then I was assigned to a GD project by MAERSK, Denmark in a Java developer role. In this time I could gain hands-on experience about GD methods and approaches, challenges, solutions and last but not least about the Indian culture.

After returning to Switzerland, I was co-author in the Swiss GD community (https://w3.tap.ibm.com/w3ki07/login.action?os_destination=%2Fdisplay%2FGDCS - not online anymore) where we documented our experiences and best-practices for future GD projects. These experiences also helped me to work in the GD setup of the VISTA project.

In the rollout phase of VISTA, the mandator Liechtenstein (LI) came quite late with the requirement to support payments to foreign accounts. This change required some fundamental modifications in the program logic. As lead architect for PV it was my job to deliver a working solution on time, i.e. before go-live of LI.

First, I set the limits of the scope for this change: LI, IGS and me agreed to support foreign payments of type IBAN only. Then I met with the PV product manager to draft the solution and finalize the specification. On Wikipedia I studied the different formatting definitions of an IBAN in different countries. This was one of the key problems: the current implementation used an automatic lookup to get a handle to an existing bank object in PV via the encoded clearing number in each Swiss IBAN (the digits 5 to 9 of a Swiss IBAN define the clearing number of the hosting bank). This is different for other countries, so it was clear to me to parametrize the solution.

I put the IBAN definitions into the VISTA code management structure which would eliminate hard-coded entries. The RDC developers could then implement the changed logic of the bank lookup mechanism based on the IBAN. In a first build we could test the solution, and it was working fine within PV. But the first system integration tests (SITs) with the billing system (Abrechnungssystem, AS) and extended analysis showed some incompatibilities with SAP. So I sat together with the AS team; we found out that some information on the Wikipedia page was wrong and that the PV method for the lookup of banks has to be extended.

The PV product manager from IGS and I discussed a possible solution. My suggestion to re-use a manual lookup of banks for some countries was accepted and communicated to LI. I updated the specification and configuration and instructed the PV developers and testers accordingly.

As we were working on a new requirement IGS assigned a new change to IBM, which could be delivered on an interim release (iChange) - which was late, but still on time and without following Defects.

One big benefit of VISTA compared to the legacy system was the usage of business roles and the extensibility on them. A first concept to inform the business applications if something relevant changed on an insurant's basic data was partially implemented in an early project phase already. However, it soon became obvious that this first approach would be too complex to understand, use, implement and maintain. It was therefore decided to start from scratch.

I started by interviewing the subject matter experts (SMEs) and lead architects of the business applications about their requirement. This was helpful but also difficult, as these applications were under development, resulting in many open points. However I could already outline the new concept in UML diagrams, use cases, interface definitions and in a technical overview document. In this phase I already involved the lead developer from RDC who also shared his ideas. The central architecture board finally reviewed it closely. After some rework I wrote an additional document which reflected the business side. I could present a short overview to the customer, who gave the green light for implementation.

I assigned individual features for the DB team, batch team and the PV developers and testers. Defining the code management configuration was my job and also a precondition for further steps. After some development builds all features were implemented and we could start testing - at least to the point where the notifications were created. The business applications started later with their implementation of the notification handling, which meant some supporting activities of this concept.

In 2011 the first business applications could completely get rid of the former manual "notifications" of PV and many time-taking tasks were completely automated.

Since go-live of phase E1a I was involved in VISTA AMS, which support and maintain all VISTA mandators. During E1a, the SVA's dependency on legacy data was much higher than in phase E1b, as all business applications used the (replicated) basic data from PV legacy. Therefore we put high attention on the VISTA Back Interface (BI) which replicates VISTA PV data to the legacy system (EDV2000).

BI works as a combination of DB2 processes, interface tables and regular batches on VISTA and legacy side. Some small differences in the business rules between VISTA and EDV2000, certain data constellations and some open defects prevented a proper replication in certain situations. In this cases, event tickets were created automatically, indicating some lines of log files only, though.

I was responsible to analyze these events in detail and initiate the required follow-up steps: data corrections as RfS (Request for Service), create defects or request changes or providing possible workarounds. For the analysis part I had read-access to the productive VISTA databases. This allowed to analyze the current data constellation as well as its history (journal tables). I could however not access the EDV2000 database, so I could not see what finally arrived on the legacy system via SQL. As a workaround we had restricted VISTA user accounts, allowing us to create BI reports with the client. These reports gathered data from VISTA and EDV2000, showing the connection and to some extent also the errors.

After some time I found many similar tickets and resolutions for them. In most cases, an SQL had to be included in a template, which was then executed by the DB2 provider (T-Systems). But even though I gained experience and speed in ticket resolving, the increasing amount of mandators and some cases which requested corrections on VISTA and EDV2000 side resulted in an increasing backlog of automatic and manual tickets.

To improve the ticket situation I organized workshops with the IGS DB administrators of EDV2000. This reduced some dependencies and delays, as the result of a data correction could immediately be verified. The productivity in these workshops was great and resulted in a high client satisfaction.

With go-live of phase E1b also the application IK had to be supported by IBM AMS. Similar to the experiences we made in E1a (BI / PV), we generally continued with the same processes, but more ITIL based. Only a limited time should be spent for a first "diagnosis" of an incident tickets for an initial categorization (known or unknown problem). Based on this first action we requested (for unknown problems) problem tickets for a deeper root cause analysis.

One typical example for the required tasks was a group of tickets, opened by the customer based on the observation that generated documents were not archived in the external system (ELAR Advanced). The general flow of documents is:

• The business application (e.g. IK) creates a request for the Output System (OS)
• OS calls the data extractor class for the specified document to retrieve the business data
• The business data is combined with the template elements to a complete document (PDF)
• The ELAR Interface (EI) is called to initiate the transfer and the archiving of the final document in ELAR

Now the ELAR administrator observed that many documents ran on errors and were not successfully finalized. For each document type he requested an analysis and correction measurements. An initial analysis started in EI, showing that some mandatory fields haven't been set. The root cause for this had to be found in IK, though.

I verified this initial position with queries over the EI tables, to get the keys to the OS request data. OS is structured in a rather complex way (key-value pairs for each element of a document), so I first needed to filter and structure the data in a readable form. The SQL queries got more complex, but also more configurable, resulting in quick summaries of the data constellation in VISTA, OS and EI.

From these results I could conclude that the problem was invalid partner data of referenced employers. I could conclude the analysis by requesting RfS for the data corrections and by suggesting a change which would allow an adapted logic to handle with such data constellations.

A long-lasting problem in VISTA PV were duplicate partners. To some extent, duplicates have been created by user errors or migration issues, but the main root cause were automatic reconciliations from other applications. With the introduction of the new Swiss social security number (NNSS) the reconciliation batches of the application IK and IPV relied on the uniqueness of an NNSS over all partners. But some special concepts of IPV and IK and a specification fault enabled these batches to generate hundreds to thousands of duplicate partners inside PV.

For the SVAs it was very difficult to handle duplicate partners: sometimes, the business roles for one partner were distributed to two different partners. In other cases, one insurance business (respectively business roles) was assigned twice to one NNSS (but two identical partners). This led to duplicate administrative work, in the worst case these insurants received letters or even payments twice. Often, a manual cleanup was difficult or even impossible.

After the root causes had been fixed, I was asked to provide a solution concept for a data cleanup. This concept consisted of two mechanical iterations, considering the distributions of the business roles. The remaining amount should then be communicated in a list form to the SVAs manual data cleanup. The customer approved the concept and also asked for a time schedule.

The script had to distinguish between multiple scenarios, each iteration consisted of many sub tasks and control steps. Also, the effect on follow-up batches had to be considered. For the biggest mandator (SVA Zurich), after the two initial iterations I discovered an additional possibility for a reduction of duplicates, which reduced the amount again significantly.

The scripts ran successfully on all mandator's systems. In Zurich, the duplicates could been reduced from around 25.000 to approximately 300, which was - after I provided a detailed list - easy to handle for SVA employees.

VISTA was in the phase of "accelerated rollouts" when some urgent pre-migration tasks of one mandator (SVA TG) were still open. TG was already live with VISTA phase E1a (basically PV only) in which the data dependencies for the business applications (on legacy) were not that strong. For a successful go-live of SVA TG the PV data on production had to be completed first with three tasks:

• Assign correct civil-state-since dates to all partners
• Assign correct country of living-since dates to all partners
• Assign correct NNSS (new social security number) to all partners

As input, the customer could only provide a list of IDs and values from legacy only. I had to map these values to vista data, provide SQL scripts for importing the modified list files and the follow-up processing. Like for other mass updates in PV I had to consider the effects on follow-up replication batches which could not handle updates in too big portions and find a way to split the workload. The real challenge however was the time. The migration team could not provide the input files before the "work freeze" before go-live, and the script had to run before some other migration tasks.

A special effort from my side over nights and the weekend was required to deliver the solution. Fortunately, all three scripts have been executed successfully and on time. The project manager from the customer side sent an appreciation mail to me afterwards (see file compliment_steger_spezialeffort_20110524.png).

PV is a cross application in the VISTA context, having 276 Interfaces for general usage or customized for the business applications. PV is an important data provider for them and the dependencies have to be considered and understood both in development and operation.

During the development phases of VISTA it was important to maintain the the interface overview documents. The interfaces have been structured into several groups, mainly according their assigned business applications. This allowed to use very specific functionality which could be defined and maintained by their owners without interfering others. Obviously, also many interfaces were specified for general usage which were used by all applications.

Working for some Back Interface (BI) Changes and while analyzing AMS incidents helped me to better understand the system relationship. PV data is not only used by other VISTA applications, but also of great importance for the legacy system. For example, if a payment address could not be replicated to EDV2000 the insurant could not be paid out.

Different replication mechanisms had to be applied for similar reasons to other systems like SAP, ELAR Advanced and later on GILAI. Being involved in the development of these system bridges was a big benefit for later addendums and support activities.

However, the most visible example for PVs system context is probably the notification concept which I made the specification for. During interviews with SMEs and later on in the testing phases I could closely follow the effect of a relationship update on a partner in PV and the consequences in the pension application.

PV is a core component in the VISTA context, which itself is only one component of a very complex system context. This fact however does not diminish its importance.

As already described in (CC7), IK can also be described as a cross application as a main input data provider for the
pension (RE) business, some legacy applications and other SVAs. In IK it was essential to keep the system environment in mind.

The data exchange via the central compensation fund (Zentrale Ausgleichsstelle, ZAS) is probably the most apparent part in IK to demonstrate the interface tasks of the application to the entire business context. Simplified, IK communicates with the ZAS Assistant (ZA), which is responsible to format, validate and transform VISTA data into the XML format in interface tables of the ZAS Collector (ZAS Kollektor, ZK). From the ZK tables, the XML structures are imported and exported from/to ZAS, which is outside of the VISTA context, but the central element in the business flow for the information flow between the SVAs.

I have worked with many different XML structures and verified in some cases the compliance of VISTA with ZAS. I defined business rules to cut some VISTA data structures to a certain amount of characters in order to be able to export booking information without validation errors. It was instructive to see that a too long name for an employer could be the reason for validation errors, unprocessed transmission to ZAS and therefore pensions which could be calculated for an insurant, whose business is actually at another non-VISTA SVA.

Similar attention had to be assured when I extended the data definitions for data exchange from/to Legacy, e.g. for the Contributions application (Beitragswesen, BW) in EDV2000.

Specifying Changes for IK always meant to check the implications on other VISTA applications, legacy and ZAS.

Problem description:
In VISTA, partners are either created manually or via some reconciliation batches. Around 20% are imported from an external source (ZAS). In this case the name of an insurant is stored in capital letters in PV. With the inclusion of external applications the customer requested to change these cases in proper capitalization. However, the DB2-internal function INITCAP could not be used, as this function was introduced with DB2 9.7 only, but VISTA was using version 9.5 at that time.

Options:
A research showed the possibility to use User Defined Functions (UDF) in DB2. A search for existing assets resulted in two ready-to-use files:

IBM: http://www.ibm.com/developerworks/data/library/samples/db2/0205udfs/
External: http://www.zinox.com/node/13

Decision:
Both assets would serve the same purpose, but the version from IBM provided more samples and seemed to be used more frequently. Therefore I decided to go for this asset which was working perfectly.

Problem Description:
The application leader of IK created an Excel sheet to track AMS tickets and combine them with known changes and defects. In this absence and after he had left the project I took over this asset for further ticket tracking.

Assets:
Kategorisierung neue Tickets 2012-10-02_GB.xls

Purpose:
With this work product I could compare new tickets against existing ones. I used it for stand-up meetings with the team to discuss, categorize and assign new tickets. Ticket data could be copy-pasted from the ticket dump, one worksheet checked for duplicate entries. Also, it allowed a quick way to search for known problems respectively existing defects or changes.

Filename:
VISTA_Architectural-Workflow_Apprentice_20120905.ppt

Purpose:
To demonstrate the job role "IT Architect in a GD environment" as part of a day for IBM's apprentices I held a 2 hour presentation to 3 IT apprentices. The target was to give them an impression how a typical day or task could look in a Global Delivery (GD) project.

Filename:
IGS Training VISTA PV Notification_20110616_compressed.ppt

Purpose:
For internal training for the product managers, the customer requested that SMEs or lead architects.would hold an education session. In this presentation I explained the new topic of the PV notification concept. The presentation file should be archived and therefore of a high quality regarding the comprehensibility. All the information on these slides should be correct, but simplifications should be used for complex topics. Therefore I used many diagrams instead of specification details and added some more technical details in a backup section only.

Filename:
VISTA_PV_Zahlungsanweisungen_Adressen_0.4_d.ppt

Purpose:
After many mails from and to the migration team (IGS and IBM) addressing a problem regarding a migration issue with payment addresses, I decided to hold a presentation for all involved parties, describe the problem, propose a solution and target to define a way forward. This session alligned all parties and for future incidents on this topic the agreed process could be applied.

The Scope Refinement phase in VISTA was a very collaborative and innovative time. Suggestions for changes could be submitted easily on a SharePoint team room where they were reviewed by a "Change Management Board" (CMB). In parallel, phase E1a was already live and some experiences from production could already  be included in such proposals.

I saw that duplicate partners would lead to massive problems and high efforts to cleanup wrongly assigned business roles. Besides these high efforts also the financial impacts in case of multiple paid-out compensations could have been critical. Therefore I decided to propose a solution in which the SVAs could resolve such issues by their own without any requests for service.

IK knows the concept of "mini partners" which are actually normal PV partners created by IK, having no address and an an IK business role only. They are created if no existing partner can be found based on the social security number (SSN). However, many partners didn't have an SSN or only an old one. This led to the fact that most duplicates consist of a "normal" partner with any business roles and an IK mini partner.

My proposal described a concept, how such partners could savely be merged: the IK role and the SSN of the mini partner would be attached to another partner (often having already different business roles), the SSN deleted from the mini partner and finally the mini partner would be terminated.

For capacity and prioritization reasons the proposal was not approved by the CMB, but the concept was not done in vain: parts of it could be re-used later for data cleanup activities.

My concept of the integration of the external system GILAI into VISTA (see CC3) was accepted by the customer and in development. This batch-driven solution could however not guarantee an "immediate" replication of VISTA data to GILAI. For technical reasons we could only guarantee to run the replication batch every 5 minutes, but even this time could not be guaranteed in case of high workloads. The 5 minutes maximal replication time was accepted but not optimal and compromise only.

Then I thought about the possibility to trigger the replication manually. It was however not possible to start a batch on demand as this would interfere with the existing Batch Job Plan (BJC). But when I had another view at the process chart I found that GILAI only consumes data from some target tables and is not dependent on any processed steps before.

I made a short proposal about including a button on the GUI which would then trigger a "shortened" replication to the target tables, circumventing all batch dependencies. The attributes of the currently active partner would be written to the target tables, ready to get captured by processes of GILAI.

The customer liked this approach for two reasons: cost efficiency by using already existing tables and services from the initial concept and the removal of batch dependencies and to offer a guaranteed "immediate" replication if required. IGS handed over a new change feature to IBM for implementation which has successfully been delivered.

In PV there are important partners like SVA branch offices whose addresses and payment addresses are referenced by many partners for payments or correspondence. Changes on such objects are therefore crucial and should be checked before a payment process. Accordingly, before each bigger payment run I observed increasing AMS tickets requesting information like "How many insurants have a payment relation with branch office X?" or "Please send a list with all addresses which are references by more than 20 insurants and which were changed during the last 2 months.".

In some cases we could not provide the list on time. Also, each SVA wanted such lists minimally different and there was no standard process for this tasks. I thought about integrating such a reporting functionality into VISTA, thus eliminating the dependencies of the SVAs on other parties and offering the possibility to create such reports on demand.

One VISTA module offered the possibility to create printable documents: List Generator (LG). LG was mainly foreseen for the business applications and not used by PV at all. However, LG is application independent and can be called from every application. I suggested to define a template for the most important attributes and integrate a new list type for PV into LG.

As LG offers a parametrization for each list, I could make a small proposal for a change which would meet the different requirements from each mandator. The costs for this change would be equalized after a few months already. IGS assigned my proposal as new change to IBM, offering a good service for its mandators and reducing IBMs effort for AMS tickets.

Banks and payment addresses are very important objects in VISTA, as paying out the insured persons is one of the core business of the SVAs. As the SVAs still use some legacy systems for some business applications, all payment relevant data has to be replicated from VISTA to legacy.

Replicating bank basic data was not in the initial scope of the BackInterface (BI). A complex manual process had to be established  in case new banks had to be defined in the system: the SVA had to create the bank in VISTA, create an AMS ticket with the details, IBM AMS then prepared and forwarded a template to two legacy teams which also had to create the new bank in legacy applications. They returned some database keys from legacy, IBM updated the form, sent it to the Service Desk for handing over the form to the hosting provider for executing an SQL which created link (keymapping) between VISTA and EDV2000.

Even though the steps were not complex, the total execution time for this process was easily two working days. Usually requests for new banks came just before payment runs, therefore these tasks were often time-critical.

I suggested to analyze the technical requirements and provide an effort estimation for integrating banks into the BI replication. The customer was happy to have the possibility to compare the costs and assigned an analysis change to me. For this I drafted the technical solution and estimated the efforts in detail. However, the efforts were too high for the customer (he assumed that BI will be a temporary solution only for a relive short time), so the feature had never been implemented.

Nevertheless, the Analysis was paid and I could later optimize the manual bank process at least - and even outsource the IBM part of it to RDC India.

In the conceptional phase of VISTA the International Bank Account Number (IBAN) was not yet in use in Switzerland. Whereas early Changes for PV introduced this payment type in VISTA, it had to be disabled as this type was unknown in legacy (EDV2000) and such payment addresses could not be replicated via the Back Interface (BI) to EDV2000.

When the Swiss Post announced to use IBAN as default payment type and charge CHF 5.- for each transaction to non-IBAN accounts, the need for an integration of this new payment type in PV, BI and EDV2000 became a high priority change request; the financial impact on the SVAs when not implementing this change was obvious.

I split the change into two separate features, one for PV and one for BI. But first the solution had to be outlined on a high detail level as I had to consider the needed modifications in EDV2000, too. BI uses fixed-length strings in interface tables which are polled by legacy batches. I defined a modified string format and let it review by the Architect for EDV2000.

At the same time I specified new interface methods for PV and BI to enable the transfer process for IBAN payment addresses. Also, VISTA code Management (CM) values and hidden GUIs had to be enabled again. More complex however was to define new validation rules and a logic for retrieving the correct bank basic data to an IBAN.

The concept for these parts were reviewed by the leading central architect of VISTA and all involved developers. Then, the implementation could start: DB and CM Changes were targeted for the same sub release, completing all preconditions for the model update, GUI modifications and the new Java logic.

For this change, an early testing involvement of the legacy side was important and helpful: defects could be found and fixed in an early pre-build.

Because the application "Contributions" (Beitragswesen, BW) is not integrated in VISTA but is still operated on Legacy, the BW employer roles incl. correspondence addresses are missing in VISTA PV. In Legacy, these information are stored in a table. While VISTA batches import employer data, the connection to the correspondence address in PV is missing. The customer asked to have this information imported, too.

For this change I made an impact analysis first: I listed all business rules, GUIs, Interfaces and processes which would be involved. Based on this I could make suggestions for the SIT (System Integration Test). A time schedule could also be concluded from this analysis, as several components needed to be in synch in each subrelease, leading to a final build which would fulfill the customer's expectations.

After I assigned all features to the developers and other architects, I tracked the progress on a daily base and updated the current state in a change tracking sheet. I had to handle a fault on the customer's side (the legacy definitions had an error and required updates on the Java code), but this was relatively easy to handle, but required consistent documentation changes in the use case and test data.

We could deliver the change on time, but the very last tests showed a problem when the new parameter was null. This defect required a patch (iFix) as the regular build was already gone. Nevertheless, it was before the Go-Live of this release and had therefore no impact on the production business.

Filename:
50611_ZG_Raiffeisenbank_Dünnerntal_v2.1.doc

Deliverable type:
Standard process form for incident management

Purpose:
As banks were not replicated to EDV2000 (legacy), a process had to be established in case of new banks needed to be introduced or changed in VISTA. This process involved 5 stakeholders and several manual steps. I could establish a standard form which all involved parties could understand and take the appropriate actions. I further optimized it in a later phase and adapted it to a new incident management organization. It was even possible to outsource the IBM tasks to RDC India. The form is still in use for several bank changes per week.

Filename:
IGS Training VISTA PV Replikation.ppt

Deliverable type:
Education material

Purpose:
I was asked to hold a training session for the customer's product managers addressing the replication mechanisms of PV. The presentation should also be usable as a quick reference documentation, internal trainings, on-boarding etc., therefore I used the most important information in the normal presentation slides but added a set of backup slides with further details.

The time between the implementation of the PV part for the new notification concept and the implementation of the business applications' part was almost 2 years. The business needs for the customers respectively the business applications were not finalized for a long time. Consequently, before the entire concept could go live, the Architects, SMEs, product managers and end users of the SVAs had to deal with unclear requirements on one hand and a tough schedule on the other hand.

In this phase I got the task to lead a small subproject for the notification concept. My main tasks were to align all teams (PV, RE, HE, EL) to have a common understanding, gather the final requirements from the SVAs and detect open points in the implementation and address them in defects and changes.

I set up a weekly meeting to present the progress to the management and discuss next action points. Usually small sub teams were formed after the meeting to analyze new findings or to test implemented defects or changes. The contribution each team provided were new testcases and updated tracking sheets, from my side I tracked the new defects and changes and a merged tracking sheet for the management.

The new notification concept could go live successfully on time.

Reviewing changes was almost a daily work for me in VISTA within PV and IK. The first review usually took place before the real work had started: the customer specified the business requirements in SharePoint for an initial analysis. Besides providing an effort estimation and a technical specification, I had to challenge the customers requirements first. I encountered multiple cases where the business requirements contracted some established functionality or the desired solution would have had negative consequences. In such cases it was good to clarify these points in an early stage already.

For the effort estimation I involved RDC developers who generally used a specific template to calculate the effort. In many cases the outcome however was not realistic, therefore the provided values had to be questioned critically before the final offer could be given to the customer.

Before a change was assigned for development I leaded a handover telco with RDC to clarify open questions and to ensure a common understanding. Of course I was also available for questions which were raised later on. Normally the next review part from my side affected the AIT test cases provided by the RDC test team. This ensured a sensible test coverage before code delivery.

I asked the developers to show the new functionality in a spot check, using phone and remote desktop connections. In this sessions I could get a good impression about the change and already address first findings.

In some cases it was also required to assist the developers with a code review which also explained some troubles the developers or testers were facing.

Since go-live of VISTA phase E1a I was involved in the AMS incident management process. Generally the customer's tickets came in as incidents. After a short diagnosis (known or unknown problem) we requested problem tickets for deeper analysis. The result then usually leaded to data cleanup activities (Request for Service, RfS), defects or changes.

For PV I would like to give one example:
Like partners, addresses have to be replicated by the Back Interface (BI) from VISTA PV to Legacy PV. If a partner or address cannot be replicated, for example due to different business rules on VISTA and Legacy, an automatic ticket is triggered during the error logging. In several cases however the user changed an address but the change was not replicated to EDV2000 - but no error had been logged. In the BI reports I saw that all VISTA updates were "processed", but without effect.

At that time I was rather new in the BI context, so I involved the lead architect for BI in the analysis. Together, we found out that the address had been created by the migration and had a special key mapping (a table which combines the technical keys from VISTA and EDV2000). As this address belonged to a payment address only and was only created to establish the same structure both in VISTA and EDV2000, such addresses were defined to be treated in special way by BI: all VISTA updates on the address would be "ignored" and directly marked as processed.

Together with architects from the client we discussed this topic. We had the option either to change the behavior in BI or accept the current state, mark it as "accepted issue" and a find a workaround. We decided for the latter, documented the root cause and created a work around instruction document for future cases.

For IK, I was involved in the AMS incident management process since go-live of phase E1b. Since beginning, IK had a high rate of incoming incidents, one reason for it was IK's data driven nature and it's status as a cross application. I would like to give one complex problem type for IK as example.

As other applications IK creates documents, which is performed by starting an OS-request (OS = Output system) first, providing some basic data like the name of the template and then let OS call the specific data extractor for the document which fill the template with business data. The Elar Interface (EI) in a later process captures all completed OS requests and send the generated documents (PDF) to ELAR, optionally also into an archive.

An increasing number of OS events, error entries in the EI tables and users complaining that in some cases documents were not printed or archived leaded to the request for a deeper analysis of the root causes for it. For the IK documents I took over the analysis. I asked the SME for a pre-analysis of the errors for the IK documents, also, I asked the OS architect for some analysis SQL queries. With the input from them I already knew that the problem in 95% was a missing parameter in the OS requests. Without this parameter ELAR could not further process the documents.

This variable is retrieved by PV through a look-up service which returns the correct value if all dependencies can be resolved. Otherwise, null is returned, leading to the missing parameter in the OS request. I crated a complex SQL which linked all dependent objects to one table and could conclude that it was a data problem. In almost all error cases one of the dependencies was broken. For the other cases the dependencies were all correct at the date of analysis. Therefore I extended the query to search for historic data, too, using DB2's journal tables. In these cases, the problematic data constellation was existing at the printing date, resolved later on, but the OS requests were not updated (as such a functionality does not exist).

I could solve the problem tickets by describing the problem, suggested a change for an extended look-up service in IK and providing data correction scripts in follow-up RfS tickets.

For the incident analysis in IK, the entire team created and collected a huge amount of SQL queries. It was however not always easy to find, modify and execute the scripts without losing much time.

Together with a colleague from another business application I created analysis scripts which would provide a quick overview of the IK data and some dependent objects by providing a social security number (SSN) only. We made .BAT files which were able to execute an entire chain of SQLs by a single double click and an SSN as input. This enabled the team to have an entire partner report in one file. Additionally, it provided a method to test batches by taking a report before batch execution and afterwards and then comparing the reports side-by-side.

The scripts however required a full DB2 installation which I suggested to all local team members and to the RDC testing team. Before most of the team members used other products like SQuirreL or DBVisualizer only. Of course, they are still in use and the DB2 installation is just an addendum - a time-saving one, however.

Some colleagues reported a strange problem when they accessed some tables on a certain release. In a forum I found that the possible root cause was an incompatible DB2 version with some client systems. In this case I asked to install a different DB2 version - which solved the problem.

The VISTA project setup uses many IBM software packages and licenses:

• IBM Rational ClearCase (CC) for project artifacts
• IBM Rational ClearQuest (CQ) for tracking Defects and Changes
• IBM Rational Software Architect (RSA) for modeling and coding
• IBM Rational Manual Tester (RMT) for defining test cases
• IBM Rational ClearQuest Test Manager (CQTM) for tracking the execution of test cases
• IBM DB2 as database application

For my work as architect and application leader I made extensive usage of all these products.

When the test automation subproject started, IBM additionally set up

• IBM Rational Functional Tester (RFT) for designing new automated testcases

During my stay in India for the test automation workshop, I also supported the test architects in capturing the VISTA GUIs and creating correct automation scripts in RFT.

The customer migrates to

• IBM Rational Team Concert (RTC), mainly using it for testing artifacts

I intend to use the web front-end, too for an effective collaboration with the customer.

VISTA used the IBM Unified Method and each of its work products. For PV I worked mainly with APP 030 work products.

As previously stated (CC15), PV is a cross application with extensive usage and provision of interfaces. The core documents for the definitions were the interface definitions which were split among the business applications. Each application had its own interfaces, allowing a high level of individuality and independence. I specified and updated many services for the business applications and kept track, which application uses which interfaces.

Of course there were also common interfaces used by many other application. I had to keep them up-to-date and could provide support for the applications about which interface to use and what to consider about them.

In the APP 030 context also the entire PV notification concept found it's place, especially by providing a complex service to analyze the notification entries in detail. As this service provided current and historic PV data and the interpretation of the returned objects was tricky I supported the architects and SMEs in the correct usage when the business applications implemented their part of the notification functionality.

Like for PV I also worked in IK with many different work product types of the IBM Unified Method. Here I want to focus on the two work products I used most: APP 130 and APP 300.

IK has 221 detail Use Cases in 17 groups. Working on changes, defects and AMS incidents required to consult and update these documents carefully. They were the main tool to decide about defect vs. change, and as architect I had to support the application leader and customer's product manager in such decisions.

Handing over a change to RDC required me first to define the new logic in the specific use cases. Implementation was then based on the use cases and the second main work product group: Business Rules (APP 300).

The business rules clearly decided about go / no go for the user's actions. In IK as a cross application, communicating with external systems and other SVAs the compliance regarding the common business rules was essential. Like with use cases, I always updated or created the business rules first before assigning changes to RDC. Also, they provided a mean to identify the required test cases.

In VISTA all work products and source code files were maintained by Rational ClearCase (CC) Together with Rational Software Architect (RSA) I used it on a daily base:

• Create / update work products (see AI11)
• Update VISTA code management XML files and run a verification build with an ANT script
• Retrieve the latest code (or a specific branches) of PV or IK for code analysis
• Check-in/out source code for BI development
• Create new baselines and rebase activities (in VISTA 2 main streams with sub streams were used in parallel, code changes needed to be synched among these streams accordingly
• Create / update testcases for Rational Manual Tester (RMT)

In my role as Java developer in the SPECTIVE project (during my assignment in India) the library management tool to be used was Microsoft Visual SourceSafe (VSS). Together with Eclipse as development tool I used it intensively for my development activities:

• Check-in/out source code files
• Run ANT build scripts for creating a local build
• Synchronize updates on one file from multiple developers
• Maintain work products (use cases etc.)

Among many other changes, the new PV notification concept is probably the best example in PV where I created a new design from functional and non-functional requirements.

In a first step I gathered the requirements from the lead architects of the business applications in order to retrieve a map of all PV attributes which are relevant to be notified for their business. These requirements were refined later when the applications implemented their notification part. From the customer I got some non-functional requirements in terms of batch run times.

As architect I transformed all theses requirements into a complete design, summarized in a technical (in English) and a business (in German) conceptual overview documents. These documents contained state transition tables, interface definitions, configuration parameters and sequence diagrams.

The new design could be implemented and set live successfully.

An example where mostly non-functional requirements were involved was the change to optimize the PV search performance.

The PV search is probably the most central functionality in VISTA and is also used out of other business applications. The users however could enter every possible search combination which at the end created a very non performing SQL query, sometimes affecting the entire system due to "long runs" on the DB. In a workshop I proposed to prevent some time-taking search combinations in the GUI. Additionally, I could set field prioritization: if the user entered a social security number (which is unique), then all other attributes would be ignored, leading to a simple search SQL.

Before I gave the search design for implementation, I documented the approach and the specific prioritization levels for the fields in a common understanding document which was later the basis for acceptance testing.

Additionally, I let the DB team analyze the existing indexes on the PV tables. We were able to remove some unused indexes and introduce new ones for frequent parameter combinations.

The PV search performance is now much better and no "hangs" have been recorded since then.

Custom Application Development is the former AD 2.0 method which was used (among other processes) from the UMF framework to define the VISTA System Delivery Lifecycle (VSDL). This process was engineered to satisfy the special needs of GD and was heavily used during the whole delta development in VISTA. It describes the work products to be created and the responsibilities of each project-member in the various development stages.

I understood the components from this method and was able to efficiently work together with RDC and the customer using the established assets and tools.

During and after the scope refinement phase we applied Agile software development method. In this phase I tried to fulfill all of the Agile Manifesto. In brackets [] I mention the concrete situations and actions in VISTA.

• Customer satisfaction by rapid delivery of useful software
  [Testcenter offered early and extensive testing sessions with end users]
• Welcome changing requirements, even late in development
  [Planning of changes according to their priority and not submission date]
• Working software is delivered frequently (weeks rather than months)
  [New releases every two weeks]
• Working software is the principal measure of progress
  [Progress measured by the implementation of changes and defects, not budget or time]
• Sustainable development, able to maintain a constant pace
  [Many test phases like AIT, SIT, Change Testing]
• Close, daily cooperation between business people and developers
  [Architects, testers and product managers in the same room (test center)]
• Face-to-face conversation is the best form of communication (co-location)
  [Informal meetings with exact the required persons to discuss specific topics]
• Projects are built around motivated individuals, who should be trusted
  [Most of the team members having experience of several years and the will to reach the Go-Live targets]
• Continuous attention to technical excellence and good design
  [Bi-weekly meeting with all architects (Central Architecture Board)]
• Simplicity - the art of maximizing the amount of work not done - is essential
  [Focusing on important changes]
• Self-organizing teams
  [Application leader are also SMEs, architects act as stand-ins for application leader]
• Regular adaptation to changing circumstances
  [Constant replanning of changes and defects, taking over additional responsibilities]

In the SPECTIVE project I used Telelogic FocalPoint, a system for management of product and project portfolios. In this project it was used to assign changes and defects to a developer, tester or back to the customer. I had to estimate the tasks which were described in the item and - when the effort was approved - start the implementation. I also updated the status and spent effort at least weekly, as it was the main tool for tracking the overall project progress.

In VISTA I daily worked with Rational ClearQuest (CQ) as the main tool for managing defects and changes, but compared to the SPECTIVE project, in a much activer role. For both PV and IK I was responsible to assign defects and changes without delays to the correct team member. And I had to track the progress of each item myself, especially in the role as Application Leader. As each item also got a sub release assigned, I needed to supervise them all regularly and take the appropriate actions if a release could not be achieved.

ClearQuest information had to be kept in synch with other management tools like SharePoint and TrueAct (for incident management). With TrueAct the end users could submit incidents from production for analysis to IBM or other stakeholders. Many times the analysis of an incident resulted in new AMS defects or new changes. In both tools I needed to put a cross-reference: the service desk needed to know when a defect would be implemented and the ticket owner would get his problem completely solved. The TrueAct reference in CQ enabled me to get additional information to a defect, respectively a "live" example from production.

The application BB (blind expenses / Blindenbeihilfe) was implemented as a small web-application outside of VISTA but uses VISTA PV data. In particular, BB does have to administer correspondence- and payment-addressees within PV. The application gets its data from PV through a DB-synchronization where everything of importance to BB is read from the VISTA-DB and transferred to the BB-DB. I had to make sure that BB can administer the relevant data within VISTA PV.

First I needed to outline the solution in a concept. Within an ARC 118 change case document I described the initial situation, the technical components to be changed (CM, GUI adaptions, a new ELAR WorkPerformer, new use cases and business rules and new privileges).

Secondly, I defined the required tasks and responsibilities for all component changes which involved activities from the architect, developers and testers. The sequence of these activities were also aligned by using several features and a tracking sheet. I had to start first with my activities due to some technical dependencies. The RDC developers started with the next sub release, but the testers could already start with defining test scenarios for this change.

Before the developers checked in the code for the next build, I held a spot check session with them and the tester to verify the most important points are working. When the developers executed the AITs and re-assigned the change to me, I could wait for the official build and meet with the team leader from the client. Together we executed the SITs and change test cases from the customer. As no problems occurred and all test cases passed successfully, the new functionality could be delivered for production.

With go-live of phase E1a I had to deal with incidents from production. These incidents were the trigger for analyzing the root cause of the customer's problem. An AMS incident could lead to code changes, either as defects or Changes.

Especially in IK with its exposure to other SVAs it sometimes happened that a Defect was too severe to have it implemented with the next official release (which could be delivered up to three months later). In such cases,
an emergency interim build (iFix) was required. As this implied high efforts on all sides (development, infrastructure, build team, service provider and test management), these iFixes needed to be negotiated with all parties. The delivery manager from IGS however first needed an impact analysis on business and system level.

When all parties agreed on a specific delivery date, I had to assign the defect quickly to RDC. Here, a lot more tracking and interaction was required compared to normal defects. I immediately worked on the definition of test cases which would be required for acceptance. Other than for normal defects, an iFix activity has to work on the first try as we would directly patch the productive system. Therefore I often also held a handover call as we did for complex changes to assure a common understanding. Before RDC marked the iFix defect as "implemented", we verified the solution in a spot check session, for very critical defects also together with the customer.

Finally, when all tests passed successfully, we could deliver the patch. But I also had to make sure that the synchronization to all development streams would be adhered. For this I created synchronization defects and assigned them to RDC to assure the fix would also work in the upcoming regular build.

In the test automation sub project I was responsible for a constant progress on automated test cases for PV. Before, during and after a special workshop in India I tracked the progress with several tools and metrics.

One tracking sheet listed all test cases from Application Integration Testing (AIT) in PV. In a first phase I marked the automation candidates with a flag in the sheet, respectively I organized an Update in Rational ClearQuest Test Manger (CQTM) on a special field to indicate the state of an automation candidate (like Auto_Planned, Auto_Ready, Auto_Implemented). When a new AIT was automated or ready for automation, the team updated the status in CQTM accordingly; the tracking sheet could be updated on button-click for all items at once. With this I could already show a rough progress state.

For the 3-weeks-workshop PV had separate targets (50 new automated AITs in 15 days). In order to track this target I counted the new AITs each day and forwarded the results to the VISTA test manager, who made a separate tracking sheet for the workshop - and I could communicate to my application leader that we have reached the target after 9 days already.

The overall progress tracking needed to be refined however, as there were short and very complex AITs involved. Therefore I introduced a complexity factor, based on the number of steps in the AIT. This provided a much clearer picture and allowed a better planning. Additionally, in order to consider AITs with small defects or AITs which were not even translated I set a completion factor for each AIT (e.g. 90% if a small step was failing). All these measurements led to a very accurate automation progress tracking.

In my role as application leader for PV (and stand-in for IK) I tracked the development progress of these applications and reported it in a weekly status meeting to the management. The progress was mainly measured by implemented changes and the completion rate of all changes, respectively. To track this metric I used a tracking sheet which retrieved data from ClearQuest (CQ). From the fields "current / estimated effort on analysis, implementation and testing" I summarized the information to simpler statements like "16 person days open for release SR14".

One of the difficulties lied in the mapping between releases and quarter years: the "dates" of a sub release could hardly be matched to fixed calendar dates, because a release might be set productive at a specific date like March 31, but from IBM side the changes of this release were "completed" almost one month before (in the remaining time the customer executed their tests and build activities started). This fact was important to consider, as the customer ordered an amount of effort to spend per quarter and not release. Therefore I needed to calculate very carefully which changes could be implemented when, how many defects we could afford and how the entire team can work on billable items - considering the capacity and availability of each team member.

All these data had to be simplified every week, but it helped a lot managing the applications: I could immediately answer customer's questions like "Can we order an additional change in Q2?" or "Which changes should be taken out of scope for the next release, if we increase the team's capacity by 5 person days and order the big change XY instead?".

The BackInterface (BI) was developed and maintained in Switzerland and not in India. I implemented several Defects and Changes for BI with IBM Rational Software Architect (RSA).

Using the modeling perspectives and the "Vista transformation plugin" for RSA I could generate components (following the model driven aproach) and its code in a consistent way, avoiding to code hundreds of lines just to have the default headers and methods created.

Using Apache Maven I had a standardized way to configure and build the application in an easy way, assuring all required projects and plugins were loaded in the correct version.

Another RSA plugin I used in VISTA was Code-Style-Checker which served the uniformity of the code and reduced implementation errors.

As part of my "Giveback" in 2012 I planned and implemented "Bluepages Contact Sync", an Android App which allowed to take over contact details including profile pictures from IBM Bluepages to the phone's contacts.

For this project I used Googles Android Software Development Kit (SDK), consisting of a debugger, libraries, an Emulator, documentation, sample code and tutorials. The officially supported integrated development environment (IDE) is Eclipse using the Android Development Tools (ADT) Plugin.

Using these the functionality of this toolset allowed me to extend a sample project, apply different configurations and build, upload the App to the Emulator and run the debugger for it on mouse-click.

For the BackInterface (BI), an entire test suite had been created over time. When I implemented changes and defects for BI I extended and updated this suite with new JUNIT test cases and assured a high test coverage of the BI code.

The test suite allowed to execute an entire regression, build verification or combinations of a logical sequence of JUNITs. I could run and supervise the program flow and the data processing of new or modified methods and verify that the rest of the program would be unaffected.

For analyzing incidents from production I just had to modify the test data and run some JUNITs in debug mode.

My own Android app "Bluepages Contact Sync" (See AI4 & [Giveback]) was developed with the Android Development Tools (ADT) for Eclipse. Testing the application confronted me with several challenges:

• The Emulator could not connect with the IBM Intranet
• Android exists in many versions and phone producers tend to customize the pure Android system, leading to new features but also some incompatibilities
• I had "only" two different physical Android devices for testing the app in "real world"

To circumvent the intranet access problem I downloaded the HTML pages of several different Bluepages search results, anonymized the data and uploaded the files on a private web server. In the app I defined two "profiles" which I could change on the fly. In the "test"-profile the app just used different URLs to my web server instead of the real Bluepages.

The problem with the different Android versions could be mitigated a bit with the ADT, offering to run the app in many different Android versions. The biggest difficulties I had to overcome was that a core component (the contact framework) changed significantly between Android 2.x and 4.x. Plus, the contact app on the devices are very often customized.

Using log messages (which could be turned on and off depending on the profile) and an app to send the phone's log files to a computer (SendLog) and having the app installed on two different real devices I had everything in my hands to analyze bugs which occurred on one device only with real data from Bluepages.

When I had to create complex data corrections and mass updates which involved business logic, I usually had several options to choose a language. One would have been to use a new or modified batch, write the logic in Java and integrate it into VISTA. Benefits would have been to use existing services and business rules checks, but having the disadvantage of dependencies to the build plan and additional effort e.g. for the batch team.

Therefore I tend to use DB2 functionality: DB2 expands on the definition of a stored procedure by allowing you to code them in just about any language you may need. DB2's external procedures provide an option to implement more complex logic than SQL can support, using languages such as Visual Basic .NET (VB.NET), C, C++, C#, COBOL or Java.

So again, I could choose which language to use, often it was a decision between SQL and Java. Normally, with SQL no control flows are possible, which would be a clear argument for JAVA. But DB2 offers to use conditional and loop statements (if-then-else, while, for, ...) as in other programming languages. Arguments for JAVA would have been a full-featured exception handling model and object-oriented principles. But for my purposes this was not a requirement, and because a stored procedure in JAVA requires a compilation task and SQL does not, my choice for SQL (making use the conditional statements) was justified.

When I dived into Android programming and started on my Giveback-project "Bluepages Contact Sync" (see AI2 and [Giveback]) I had to choose among many environments, tools and languages:

• Android Software Development Kit (SDK):
  The "official" development kit based on Eclipse using JAVA)
• Native Development Kit (NDK):
  C and C++
• App Inventor:
  Web-based visual development environment for novice programmers
• HyperNext Android Creator (HAC):
  HyperNext is an interpreted English-like scripting language
• The Simple project:
  Simple is a BASIC dialect for developing Android applications
• Qt for Android:
  C++ and QML
• PhoneGap
  Use HTML and JavaScript code to function like a mobile app
• ...

Out of these tools and programming languages, I eliminated PhoneGap quickly. Even though the compatibility (HTML and JavaScript) and ease-to-use were arguments, I had to deal with internal phone functions which were not accessible by this combination. The NDK would have allowed to create high-performing native applications in C, C++, but I knew my app wouldn't become very CPU heavy. Also the tool setup seemed to be more complex. QT for Android using C++ and/or QML was interesting, as it offered good portability features (for example for iOS). But, at that time, the available documentation, sample code, libraries and up-to-date feature list for the official SDK for Android using JAVA was the main motivation to start with the Android SDK and not with QT. Additionally, my skills in JAVA are better and required less introduction effort.

While most of the development work in VISTA had been outsourced to RDC India, the Back Interface (BI) remained to be developed and maintained in Switzerland for various reasons. I implemented several changes and defects in the VISTA framework (which is based on JAVA Spring / Hibernate). For modeling changes I used the VISTA Transformation plugin (see AI4). For updating the unit tests, I programmed new JUNITs for the existing test suite.

I adhered the VISTA coding standards, which are based on the "Oracle Java Coding Standards" and could be verified with Checkstyle, a plugin for RSA. I could further improve the code quality by using a Programming Mistake Detector (PMD), which is a static ruleset based Java source code analyzer that identifies potential problems.

In my spare time I support the website for a local community. Initially, I programmed the entire website in ColdFusion Markup Language (CFML), HTML, CSS and Access databases. As the site needs to be migrated to another host which does not support CFML but only PHP, I started to develop an entire Content Management System (CMS) in PHP. The requirements from the community to this website were very specific and could not be covered with an existing open source solution.

In order not to reinvent the wheel again I decided to use a framework which supported many basic features like forms, templates, security, session handling and more. My choice was the PEAR framework for PHP, which is open source and served my needs perfectly. I followed the existing coding standards (http://pear.php.net/manual/en/standards.php) in case other users want to use or modify my CMS: it is available in a beta-version on SourceForge (http://sourceforge.net/projects/boomcms/).