How SOA Really Works

Pretty frequently, I talk to people who are really smart, articulate and who tell me things that I could never hope to fit into a feature for the magazine. I want to start featuring them here. Hossein Moiin, vice president of technical strategy for T-Mobile International, is one of those rare people who can go deep on the technology but also pull back and put that technology into a business context and a strategy context. Notice how he talks about his SOA. It’s not merely in the context of reusable internal integration—this is a two-pronged architecture that is as focused on external revenue-generating opportunities as it is on internal integration. That is a critical strategic emphasis that seems to be missing from many SOA efforts today. Notice how he understands the different speeds, sophistication levels and adoption tolerance of technology processes versus business processes and management processes. I think we tend to assume that they can all move at the same speeds and have the same degree of sophistication. The truth is business and management processes lag far behind the sophistication, speed and adoption rates of technology processes. Let me know what you think.

Q: How did you map out the SOA for T-Mobile?

A: We designed four planes or four layers, if you will: applications, access, consumption and support. So what we’ve done is we’ve gone holistically into these four planes and said, what are the processes, what are the functionalities, required within each of these planes to deliver the whole gamut of communication information, entertainment and even transactional services to our end users?

Now what we’ve done, based on that, is broken down these areas, these four planes, if you will, into further layers.  So start at the very top:  four layers; go down a little bit deeper into it.  You end up with a number of network-specific and network-agnostic functionalities. So within the application plane, you end up with streaming video, video clips; voice itself—voice calls is one such application—etcetera.

Then you build those applications and combine those applications with the core capabilities of a mobile phone company, which include things like presence and location, messaging, browsing capabilities. As well as ability to charge for the thing, to build databases and data warehouses regarding the customer interaction with the ecosystem. And not to forget, you need the right network and the right devices.

Each of these exposes in one way or another some key functionality which can be utilized by the application. And the goal of our service-oriented architecture is to understand and articulate the capabilities of each of these planes and sub-planes in a manner that can be used by external and internal application developers, so that they don’t have to rewrite the code and reinvent the wheel.

I’ll give you an example. For instance, many devices have very different characteristics. Simple characteristics such as screen size and, related to display, color or black and white pictures is an important characteristic for a set of application providers. Another one would be probably the speed of the downlink guaranteed by the network or provided by the network. These features, if they are not made available to the application developers, need to be discovered and then used by the applications themselves.

T-Mobile’s infrastructure has all this information available. It’s just that it’s not exposed properly and at the right level of abstraction. So what we did was we said, “Okay, we want to have a viable and vibrant ecosystem. And that ecosystem will be composed of the users with their devices, the mobile phone company and his or her internal applications. And the third parties, who will provide most of the content.

So within this framework, what we’ve done is, we said, “What are business processes that we need to follow? We need to have a contract with the third party. We need to have the right handset with our end users. We need to have the right functionality within the networks and the supporting infrastructure. And we capture all of this information and business processes that really are nothing more than contractual agreements, but they need to be translated and boiled down into actual services that are then delivered to the end user. And this is the basic idea behind our SOA.

Now we, like other providers, have realized that Web services play an important role in this game; however, they’re not an end unto themselves. They are not complete as of today. They’re getting better all the time, but they still leave some holes to be filled. And these holes will be filled whenever possible by standards.

So we can take some examples to be more down to earth. Let’s say, for example, that we want to do a deal with [Big-Eared Mouse, Inc.] to send cartoons to our phones. One of the key elements of our overall end-to-end architecture is a third-party gateway. This third-party gateway allows the third parties to interact with the services provided by T-Mobile. So it does a number of key functions. One of them is, it authenticates and authorizes the third party so that the end-user, when they interact with this third party, are secure from things like viruses or malfunctioning software.

The second thing it does, it allows the third party to discover those functionalities and services provided to the outside world. The third thing that it does, it dispatches a request and gathers information from the third party and sends it to the appropriate units within T-Mobile. It gathers the internal responses, and sends it back to the third party.

And it also allows the content that’s moved from the third party to the end user to have additional checks along the way. For example, suitability for adult consumption. Because we made a promise to the U.K. government that we will not allow adult material to be viewed by underage people. And we know how old our users are, because they have a contract. So this is one of the key and very specific elements of our architecture.

And the functionality that it performs is truly based on a service-oriented architecture. And as you can see, the services that it provides are authentication, authorization and even accounting. In addition, it does access control, allows for discovery, allows for dispatching and gathering of responses, and ingestion of the content.

There are many other elements like the third-party gateway which are embedded in our system. And basically all of them expose APIs so that they can be used across the board. Meaning that they can be used internally or externally. And if they need to be used externally by other members of the ecosystem, then there will be access to this third-party gateway.

Q: So let’s pretend I’m a developer at what would be a content provider that you guys work with.

A: So basically, if you have a developer at [Big-Eared Mouse] wants to work with us, the very first thing that we do is we have a set of APIs and set of documentation that we would provide them with. These documentations and APIs are a basic system description of our web services layer and sometimes beyond that, which they can take and tailor their code according to these APIs.

The next stage, once the code is done and tested entirely, is that it will be sent to us. We will put the code on our test systems. So these are exactly like our production systems except no one external can access them. These will be tested by both automated means as well as by manual means, utilizing various type of phones and devices that we actually use. So that if something is not right, we can actually let the developer in [Big-Eared Mouse] know.

And once those series of tests are passed, then that code is put onto the pre-production platform. We have normal releases scheduled once every other week or so.

Now in parallel to this technical track, obviously there’s a business track that needs to be followed. Meaning we need to decide together with [Big-Eared Mouse] what is the revenue share between us. It’s not entirely accurate to say that they sell the contents to us and then we sell it to the end user, but that’s a good model to work with.

So it’s probably not a bad idea to say that we actually are a reseller of [Big-Eared Mouse]’s content. And we add value because of the network, the device, the billing, etcetera. But we agree with [Big-Eared Mouse] at a final price. And then we take a cut of it, and we pass on their share after it’s been collected from the end user. And with that contract, there’s also the element of responsibility of [Big-Eared Mouse] as well as our responsibility.

So obviously there’s some financial responsibility, but also there’s some quality responsibility. So the content that [Big-Eared Mouse] sends needs to be, again, not a virus, not a malfunctioning software that does terrible things to your phone, etcetera. And we cannot fully guarantee, we have a way of identifying the offending party. If a third party’s content has been found to cause a virus on a customer’s phone, for example, because of the fact that we have a record of who’s been authorized, how it’s been accessed, etcetera, we can actually track it back to them. So we have not only a prevention but also an enforcement mechanism for all the safety and security that we need to provide.

So again, what’s interesting is, in the past, the process was more or less the same. And this probably goes back to the return-on-investment. And what happened was, we used to have the content from [Big-Eared Mouse] tested on many different platforms. Because each of them were independent, they did their own thing in their own specific way. And the content from [Big-Eared Mouse] would also be slightly different for each of the, say, national operators that we own.

So for example, in the U.K. and Germany, they would have two slightly different versions of the same content. So it’s the same cartoon, but to access the billing, to access the charging there will be some differences in the codes.

Q: Because the content is the same, but the code surrounding it is different?

A: Yes, exactly, because of all the differences in capabilities of national operators. So what we did was in the case of charging and billing, we built a service on top of it which exposes a unique interface to the third party. So the code is internationalized. And all the differences are internally handled by this third party gateway.

We have around 1,000 content providers working with us, some on an international scale, such as [Big-Eared Mouse], Time Warner, Bertelsmann Group. And others based in countries or local cities are very small content providers. Perhaps in Czech Republic or Germany or U.K., you will find that more than half are small content providers.

Q: So what’s in the documentation you’re sending to the content providers?

A: It tells them what are the functionalities that we provide, what are the APIs to interact with our systems, and what is expected of them, and what is the process. The functionality fits into our four planes of applications, access, consumption and support. For example, the APIs for the billing functionality are in the support plane. And this other API is actually regarding the device, which is the consumption plane. So it’s there, but it’s not explicitly pointed out. Because that level of architectural discussion perhaps is not appropriate for developers. That was our feeling when we did this.

We do not advertise native APIs to the general public, so those are something that you need to talk to the engineering or development department of T-Mobile. And then we allow you to access them and use them.

Q: People are talking about enterprise service bus, both on the conceptual level and as a product that middleware vendors are selling; sort of everybody’s converging on this space from different places. Do you have something like that, that you have built or that you have from a vendor?

A: Within our information systems, we have a product from a vendor which effectively does our business integration. And this is a bus architecture. So basically what we do is, we build adaptors to this bus for various platforms, and the information is placed on that bus and exchanged among the various segments.

So this is actually, I guess, perhaps the only one that we actually use today. The rest of them are in a truly distributed manner, and they make point-to-point calls, or they go through a star system and a star architecture. So there’s a centralized place, and then that gets distributed and dispatched to the appropriate receiver.

Q: The idea that companies are buying these buses from vendors— Does this shoot another hole in the whole conceptual SOA framework, saying that you can’t really build this stuff on your own, and that there are too many holes in the standards for you to create a truly unique SOA without one of these tools?

A: To me, this is another implementation of service-oriented architecture.

1 2 Page 1
Page 1 of 2
Download CIO's Roadmap Report: Data and analytics at scale