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”!

No Absolute Truth!

This is a copy of a blog I posted on the TMForum Online Community website.

This is a slight detour off my anticipated series of blog posts... but I have been inspired by John Reilly’s comment on my last posting and felt that there is an important message that any one new to Frameworx must understand:

“There is no absolute truth in SID!”

This is a bit shocking (at first); after all, the role of an enterprise data model is to provide a single point of "truth"; to define exactly what classes/entities/concepts, the "things are of significance to the business, about which information is held" (to quote Richard Barker ex of Oracle and author of some excellent books on data modelling) are and to provide a

• rigorous,
• unambiguous,
• easy to understand

definition of each concept/entity/class (hmm, the SID could do with some work on some of its definitions which fail, ‘big time’ to meet these criteria).

So how come there is so much debated about what the SID means? As John Reilly pointed out in a comment on my previous blog entry, there are two interpretations of what a Customer Facing Service is, and this is not the only area of interpretation and debate as you can tell if you follow the comments in the TM Forum community.

The problem is not caused by definitions of the classes no matter how good or bad they are. The problem that the SID has got, in common with any other good canonical model, is that, as Abraham Lincoln said:

"You can't please all of the people all of the time"

Canonical, basically means flexible, and the very flexibility of the model allows, and in fact, encourages different interpretations. That is not a weakness, it is a strength and makes the SID a very powerful tool. The SID has to be interpreted because every enterprise is different and operates in a different market with different products/customers/regulations/competition/management. The SID has been defined to support every possible nuance of the Communications industry, and so there is bound to be different ways of using it and interpreting it, again this is a strength and makes SID powerful.

But, the problem with any powerful tool is you need to know what you are doing when you use it, or someone could get hurt. The SID is not a substitute for thought, or experience; you need to think hard about how you are going to implement SID, and what interpretations of model you are going to adopt and then document these and make sure everyone in your organisation understands your interpretation of the SID. To quote an old friend of mine:

"A fool with a tool is still a fool"

You must not be foolish with the SID. If you are you will fail and the systems you build with it will be as complex and as difficult to maintain as the legacy systems you replaced.

So how do you go about being wise? First of all realise that using SID "out of the box" will be difficult, if not impossible. You need to ask yourself "How and why are we going to implement SID?" I have often asked or been asked this, and have even thought about building a SID implementation methodology, but I have always 'run out of steam' or time and, to be frank, experience of enough different SID implementations. However I can share some basic principles based on my experience that anyone starting a SID implementation ought to follow.

1. "Education, education, education" to quote Tony Blair, a former British Prime Minister. Don't even try to understand SID without getting some proper training. I know this to be the case, as I did it the hard way. I struggled with the SID manuals and model for about 6 months before I truly understood all of it, and I’ve had a lot of experience with other Enterprise models. Don’t think because you can read a data model that you can understand SID without training.

2. Define why you are using the SID. What is the SID for in your organisation? Is it a model to be used to define the information in a particular application? Is it the 'language' to be used over the ESB/SOA? Are you focused on the Network side or the Customer side of the business? This will help you make some of the decisions about how SID is being interpreted. For example, if your business focus is Network Management, and perhaps ITIL then the 'bottom up' (2nd) interpretation of CFSs may be more useful than the 'top down' (1st) interpretation.

3. Get some experience. Even the best training course (like the ones from the TM Forum) is only going to be an introduction to the complexity of the SID. It will teach you how to understand the SID, and introduce all the Domains and important top level ABEs as well as drilling into the Party, Product, Service, Resource and Business Interaction ABEs, but when you get back in the office you are going to need an experienced guide to ensure you don't get lost and to help you when you stand at a decision making crossroads to pick the right direction - for your organisation. Where do you go to get this help? From the TM Forum Community! Don't be scared to ask questions! Otherwise think about getting someone in for a few days or weeks to help you launch SID in your business.

4. Concrete the abstract. SID is full of 'abstract classes'. You should review these and where necessary make some local concrete sub-classes. Why do this? Well it helps regulate and document these and allows the less data model minded to understand the model more clearly with concrete examples. There has been a lot of discussion on how to do this in the TM Forum Community postings, around Party Role for example. The bottom line is that you must make the SID your own. Create a new “Acme Telecoms Information Model” for your Acme Telecoms company that is an implementation of the SID model with your concrete classes, your extensions, your new classes. You will be creating new classes and making extensions to existing ones and improving the SID class definitions to meet the three criteria I listed at the start of this post (I hope). You must understand that all of these activities are allowed, expected and are probably mandatory (another blog post on this subject in the future... I promise).

5. "Education, education, education". You must educate the implementers of the SID. The people building the new app, or defining and building the ESB. They must understand SID and how you have implemented it. You should hold formal training for these people. It doesn't have to be a long class you can probably get the message across in a day or less. Then you must of course follow up and help these teams with all the design decisions and the data mappings they are going to have to do (again another blog on this subject in the future, I think).

6. "Education, education, education". The SID is a new way of looking at the business, part of the "New Generation Operation Support Systems" you are implementing. If your business users and managers are still living in the "Old Generation" world then you are going to have significant problems. You must introduce the Frameworx Customer-centric approach, the new product modelling approach, the account focus, the Business Interaction focus all or some of which are going to be very very different from the way your organisation used to work - which is why you have starting to use SID in the first place. Understand you are going to be taking important business leaders out of their comfort zone. They have used the old Billing/CRM/NRM systems for years; the corporate language reflects the way these systems work, and unless you change this language and open the business leaders minds to the new way of looking at their business you are going to have significant problems during the training and acceptance testing phases of your project where they or their staff will say "...but, this isn't how we do things here!".

I'm sure there are other things that must be done... but if you do these things then you are at least moving in the right direction.