A Year in the Life...

I am coming near to the end of my assignment as a Data Architect at Türk Telekom. I have been in Ankara, Turkey, for just over a year now and it has been quite a year; not only because I have experienced and greatly enjoyed the rich Turkish culture, wonderful food and amazing heritage sites, but also because of the work I’ve been doing on Türk Telekom’s “Program Bir” (Programme One).

When I arrived in December 2009, Program Bir, a multi-year, multi-release, complete top-to-bottom re-engineering of Türk Telekoms OSS/BSS, was in the definition phase and the contract for the development and integration of the first release (Release 1) had yet to be let. My new colleagues had done great work with the application architecture and business processes using the TAM and eTOM, but for the data they had done little more than stating that Program Bir would be using the SID (Frameworx Information Model).

The first thing I had to do was “Install SID”, and I don’t just mean downloading SID from the TM Forum and loading it into a modelling tool. Installing SID is lot more complicated than that; some of the steps involved are:

1. Define how the SID is to be extended, and identify using the eTOM and TAM those ABEs that will need to be extended.

2. Educate the architects and analysts in the SID vocabulary and important structures.

3. Guide and negotiate with them and the SI on the interpretation of the SID (see my previous blog entry, No Absolute Truth)
   

4. Tailor the SID and its interpretation it to fit the role it is being used for which includes defining concrete subclasses of some of the abstract classes such as PartyRole.

5. Extend the SID to take into account the Turkish environment, such as ID cards and Turkish addresses and state structure as well as providing structures to cover the gaps in SID and to store important business information that have no attributes defined in SID.

6. Define the Master Data Management for all SID ABEs within the scope of the Release.

7. Define a set of design principals to be applied by the architects, analysts and especially the SI in their use of and changes to the SID covering all the above and giving guidelines on simplify the physical implementation of the model.

When the “Installation” was complete Türk Telekom’s version of SID, called the Common Data Model (CDM), was ready for use, and my job as the Data Architect could get underway.

Program Bir (Release 1) is all about integrating new COTS applications for CRM, Order Management, Network Inventory and Network Management with the many legacy systems that currently make up the OSS in Türk Telekom. All the applications, both new and legacy, were to integrate through a new SOA architecture and an Enterprise Service Bus (ESB).

So, rather than implementing (or reusing the legacy) point-to-point interfaces every application, old and new, is now to communicate over the ESB. New SOA Services were defined by the SOA Architect, and my opposite number in the SI and I pulled the information for each service from the SID (or rather the CDM) and mapped it to an XML structure. As each application that was to be a user or provider of that Service has to map their API, or legacy interfaces to the XML message structure I was fully involved in workshops and meetings throughout the long hot Ankara summer.

The mapping method we used was an Excel spreadsheet projected on the wall showing the basic XML structure. This was a pretty low-tech approach, but it worked, and was well suited to the mass data mapping meetings which seemed to work in the Turkish culture. It would have been simpler to use a tool like Progress DataXtend to do the mappings, but that wasn’t available and everyone was comfortable with Excel, even if its use required a lot of manual effort cross-checking and cutting and pasting mappings and was fraught with version control issues.

Once the two rounds of mapping meetings with each of the major systems owners were over, all the mappings had been issued and approved, and every application had defined how it mapped to the SOA Services’ XML message structure the work of the Data Architect might have been considered to be complete. But there was a vital step still to be undertaken, and one unfortunately, didn’t appear on the SI’s project plan.

I call this step “Business Value Mapping”. We had mapped the attributes in the API’s and legacy systems’ databases to the XML model, but we hadn’t talked about the meaning of the data in these attributes and values that the data could take, and what these values meant. The SI said they usually did this in the integration phase, but I insisted it was done before the detailed design was signed off. There were a lot more very hot (not just because of the climate) meetings as everyone got to grips with this problem. This pain has paid off, I believe, as the integration of the applications over the ESB during integration testing went very smoothly.

Also during detailed design stage a lot of work was done on the Product Catalogue. This was a very satisfying task as marketing and the product managers got to love the SID Product Model. They quickly learned how to use it and how to build reusable Product Specifications that can act as building blocks for future products.

During coding and testing stages of Release 1 I was often required to act as referee on the interpretation of the model and the mappings to the message model. Now as we enter Acceptance Testing I am helping to define Release 2.

But, now it is just about time for me to go and find another project somewhere else, and I can leave Program Bir and possibly Turkey sure that I have helped built a firm foundation for the data architecture of subsequent releases.

They did it “My Way”!