Read part two.
Can we start with discussing the framework announcement IBM made this week?
Sure. Let me just describe what a framework is first of all. It's a software platform that represents repeatable usage patterns from which you might put software together to solve business problems. What's unique about our framework is that in addition to that software platform, which is off-the-shelf software that we have in our portfolio, we offer assets to solve industry-specific problems. For example, the Banking Framework for Customer Care and Insight, which we just announced, the assets could be a banking data model, or a set of analytics where you go after certain pieces of data about your customers to find out if they are a profitable customer or a loyal customer. What we're doing with the frameworks is we're combining many of these frameworks with our GPS [Global Professional Services] solutions. We are focusing on developing solutions for specific industry problems based on these frameworks.
What would be an example?
The Banking Framework for Customer Care and Insight is very much focused on looking at the content of the customer. This is a problem most of our clients are dealing with, not knowing who their customer is, not understanding their buying patterns, not understanding if they are good customers in terms of greater profitability or not, not being able to detect fraudulent activity in customer use patterns. There is a lot that they can't do and that is where this platform is designed to help them. How does that differ from what we could buy, for instance from Oracle, in terms of enterprise customer software?
Normally, what our competition would do is dictate from the application all the way down to the infrastructure, all the elements that you need to have to solve the problem. We don't dictate that. We look at your landscape and figure out what you already have. You may already have master data management. You may already have a database. You may already have a business intelligence tool. So those are pieces of the framework you may already have. It may not be IBM's technology. That's okay. We'll surround that technoloigy with technology that will help you get there. That's very much driven by our business partner relationships.
For instance with customer care and insight, there are unique business partners in the analytics space. They've been doing it for a very long time in banking. They are known in that space and very deeply entrenched with our banking customers. We don't want to go in and say: "We don't have a relationship with those guys." or "We'll replace something of their's with ours that's better." That's not our value proposition. Our value proposition is to say: "Here are our partners. They've already been through our certification program for our framework. So we're going to help you leverage their technology with this framework." So we supply choice where most other companies do not supply choice. In terms of these industry solutions, we have a concern about recent talk of domain specific languages (DSL).
Is that going to create a situation where everybody is doing their own thing and nobody can understand what anybody else is doing?
I think domain specific is important. I'm not sure the domain specific language is a new thought. I think we've been looking at domain specific language for a long time. How we look at it at IBM is very much role based. So if you're a chief marketing office, there's a certain set of semantics that you use. That's pretty much true of all of marketing. They speak a language that is different from the language architects speak, which is different from the language financial analysts speak. How we look at those domains is very much role-based. So that platform would have to reflect those semantics. I don't really think that's new. We've been doing that for a very long time.
I think what's new is how you approach solving problems. We look at it three ways: people, process and information. If you look at the entities in an enterprise they tend to hover around those three areas. They are either very people-centric because of the problems they are trying to solve, or they're process centric, or they're information intensive. I think you should look at solving problems across the enterprise and determine which of those three is the major area where the problem is being solved. That's the language that then becomes relevant. If it's information based, it may be all about customer. If it is people based, it may be all about employee. If it is process based it may be all about ERP. So it's not some independent little language. Our software, our frameworks have to look the way our customers look, and speak the language our customers speak.
Among your existing frameworks, do you have any rock stars in that group?
We have two. I took over this role four months ago and did an assessment of where these frameworks were in terms of maturity. The two rocks stars are telecommunications and retail. They are both really quite different in how they approach the problem. You see a tremendous amount of reuse among the capabilities that exist in software. In retail we started with the stores and then we extended it to look at multi-channel and merchandizing. In telco it's around DSS [decision support system] and OSS [operations support systems] and now we're starting to look at service assurance.
How did you build those frameworks?
Typically, the way we build the framework is you start with a domain. In retail the biggest problem was in the store. How do you get a relationship with the customer in the store? The store could be brick and mortar. It could be Web-based. Once you start thinking of the store beyond four walls you're in a multi-channel discussion. The natural segue is to solve the multi-channel problem after you've solved the store problem. What we found in doing that was the framework was very much the same. There were more elements of solving the store problem that would be in place to solve the multi-channel problem and the merchandizing problem. It makes sense. They are all inventory based. Building out the store integration framework, we ended up building a retail framework, which is the software platform for the very things that are tied together through common inventory. That's how I see this evolving. I believe that over time building domain-specific frameworks, we are going to see connections because our customers are connected. That's the greatest value of SOA. You can make the connections in a service-oriented way without having to make a physical connection that would make things very expensive and inflexible for our customer. That's the huge differentiator.
Will there be connections between the domains?
I was talking to a retailer not too long ago and we were talking about this data model that they were looking at that should be reflective of their business. But they said: "The only problem with the data model is a large part of my business looks like a bank, which is my credit card business. Another part of my business is services and I look a lot like a telco." The good thing for IBM is our data model is modular, so we could componentize it – again SOA – deliver on that. What that told me was the traditional retailer isn't going to exist any longer, that business models are evolving.
In part two of this interview, Parrish talks about success stories for the frameworks and explains IBM's strategy for thriving during challenging economic times.