A conversation with Frank Martinez about governance and tolerance

Jon Udell: Hi, this is Jon Udell. Today's podcast is a conversation with Frank Martinez. Frank founded Blue Titan Software which was recently acquired by SOA Software where Frank is now Executive VP for Product Strategy. SOA Software's strengths were in the area of control and governance. What Blue Titan brings to the table is more along the lines of mediation and tolerance. We talked about how these two complementary themes played out not only in the context of WS-STAR or WS-Heavy kinds of services but also in the areas of WS-Light services like, for example RSS.

Frank Martinez: The focus of SOA Software's business, prior to the Blue Titan acquisition, was really the control business -- governance and security, particularly run-time governance, policy enforcement. The result of bringing the two companies together is that we now span a set of capabilities not just around control business but also around the tolerance business.

What we're all hearing is that people are coming to the opportunity around service orientation from different trajectories. Some people are coming at it from the perspective of environments that are strongly typed. On the other hand there are folks that saying "I want to solve a set of problems that are dynamically typed."

Being able to span that continuum is becoming increasingly important if you're going to deliver on this.

Jon: At the soa.com site, there's a description of policy enforcement and enablement mechanisms. Is that describing Blue Titan or is that describing pre-existing...?

Frank: That's really describing pre-existing capabilities around service manager stuff, yeah.

Jon: So the Venn diagram overlaps in some ways. There were forms of mediation that were being provided formerly, and now there are additional forms of mediation.

Frank: Yes. And there are additional forms of policy enforcement as well.

Jon: Right.

Frank: The most obvious overlap is really between what's called the stand-alone management point or proxy management point and the Blue Titan intermediaries.

Jon: Uh-huh.

Frank: And what we're doing there is consolidating those capabilities.

Jon: Do you think that it would be helpful at some point to try to converge the terminology?

Frank: Oh big time.

Jon: If you look at this through a Layer7 lens, or through a Blue Titan lens, or now Blue Titan and SOA Software combined, or an Infravio lens, you come to words that either are or are not the same, talking about concepts that either are or are not the same.

Frank: That's exactly right.

Jon: Miko Matsumura at Infravio wrote to me a week or so ago about some sort of interop initiative, which I take to be partly about just this kind of agreement on what are we talking about.

Frank: Yeah, so Miko probably wrote to you about SOA Link.

Jon: Yeah, yeah.

Frank: We're one of the participants in that as we are in a variety of different interop initiatives. There are a couple of different things that are kind of mixed in there together.

First and foremost is "what in the world is policy?" Let's just start there. There's the kind of explicit definition which is a class of metadata that defines constraints which are intended to be shared as part of interchanges between different participants in an SOA ecosystem. In other words it's 'on the wire'. It's what you represent on the wire or what you expect other people to consume or to be understand and then do with what they need to. Right?

Jon: Ok.

Frank: I think that we all have had a more liberal definition of policy. We are clearly all building systems that are much more configuration-driven as a result of moving metadata around. Not all that metadata is really well suited to be shared with other people. So there's some clear boundaries that need to be applied there.

With respect to the entities, what I'll call the policy ecosystem entities, there should be some clear definition around what is policy implementation point versus what is a policy enforcement point versus what is a policy definition point. There's a vocabulary that we should all come to agreement on.

And then the third aspect is interop side. So let's call the first two items aspects of a reference model and the third is, if you were to apply that reference model: who has capabilities in what part of the reference model and do you interop with the other players that are in other parts of the reference model? I think that's much more what the SOA Link side of the equation is all about. We can all respectively walk into customers and say, "Look this product that has this set of capabilities is in this part of the reference model and is in this part of the SOA ecosystem, works with this other stuff that's over here."

Jon: It seems that the sound bite for SOA Software and Blue Titan is "governance plus tolerance." Right?

Frank: Yup.

Jon: I think that that make sense in a sound bite kind of way. But I wanted to get back to some things that we've talked to before: tolerance, the radical acceleration of service consumption, the broadening-out of service consumption.

Frank: Sure.

Jon: For example, RSS enablement is something you and I have talked about.

Frank: Yup.

Jon: For people who don't have that context, review what you mean by RSS from a service enablement perspective and how that broadens consumption of services. And how, working back to governance, that can be brought into a control system as well.

Frank: Sure. Let's kind of take a step back. So, how are we seeing RSS used today? Well we're seeing it used in a variety of ways. The most common usage that we're seeing is to syndicate unstructured information, primarily in the area of the blogosphere. What has grown directly out of the earth, organically, is probably the most scalable unstructured machine to machine ecosystem on the planet. It just works.

Jon: I'm not sure scalable is exactly the right thing here. I mean it's scalable because it is web technology and so it's no more or less scalable than any other system of HTTP clients and servers would be, right? I would say the word might be popular.

Frank: Yeah.

Jon: It's popular. It's extremely broad, almost certainly the broadest XML application on the planet.

Frank: Yes.

Jon: The one that has the most reach, the one that involves the most people, the one through which the most information is flowing. So the interesting question is, at a time when there still is debate about the broad uptake of "conventional" or "WS-Heavy" kinds of services, this is obviously an interesting and useful dynamic. How can we harness this...

Frank: That's right.

Jon:...and exploit the grassroots nature of it but at the same time bring it into the kind of control structure that, from an enterprise perspective, we want.

Frank: Yup. So let's walk through a couple of those items here. You're talking about WS-Light versus WS-Heavy. What makes them both WS? Well, there's a couple of things. One is, if you look at most web service environments today, they leverage web protocols. We leverage HTTP. The other thing that's common is that we're leveraging XML in both cases.

I don't think anyone would argue that those two items have become incredibly popular. When you add to that REST style or WEB style interfaces that have been exposed by some of the more popular services on the web, people like Yahoo!, Google and Amazon. We start to get a picture that these are styles of consumption which enable very, very broad reach.

People see RSS flowing in or out of their enterprise. Different types of applications, in some cases it's just people subscribing to people's blogs. Then there started to be applications of RSS in an enterprise context, particularly around new styles of applications. Not just necessarily using RSS for unstructured information exchanges. But could RSS potentially be utilized for application to application interchanges in the scenarios where you had information intensive applications? That's number one.

Number two, where those information intensive applications had some tolerance in terms of standards in terms of staleness for some of the data. We have lots of applications like that in the enterprise today.

Jon: Maybe most.

Frank: Yeah. I would say that those applications where you actually need real-time, transactional integrity of the data probably make up a very small portion.

And so given that with Network Director we were really in the business of mediating and moving the interesting shapes of XML in a controlled fashion between and across enterprise boundaries, what does that mean?

Well it means stuff like: how do I integrate my internal RSS feeds with my existing enterprise identity, access and security management systems? Because most of the information interchanges that we have today within most enterprises have to be secured. They have to be governed. They have to be done in role-based contexts or exposed in a role-based context. And that presented a pretty interesting opportunity for us to leverage capabilities that we had already built into our intermediaries and into our mediation structure for solving that class of problem. That's a natural class of mediation for us.

There are some very interesting applications within the intelligence agencies.

Jon: Uh-huh.

Frank: Where people are saying, "What we need to do is to be able to have very low barriers for very broad-scale information syndication and we have a series of enterprise systems that we'd like to expose those capabilities out of including the application logic. But as we do it, let's make sure that we don't violate the integrity of either the privacy constraints that we have or violate the integrity of the information security constraints that we have."

Even more importantly, "Let's make sure that it's properly targeted to whoever it is that's consuming it. Let's make sure that it's the right stuff for the right person at the right time." In other words, this broad scale consumability doesn't come for free.

There's another problem with this stuff, it grows like mushrooms and before you know it you've got hundreds of feeds that you're subscribing to. Well, how do you filter particular types of topics for particular types of roles given particular types of situations? It's the attention problem applied to the enterprise.

Jon: With combinatorial security implications.

Frank: Absolutely.

Jon: Which are, no matter how you slice it, non-trivial. But beyond RSS there are broad classes of RESTful, lightweight services that are in need of the kind of control and governance that we also would like to be able to apply to WS-Heavy kinds of things.

Frank: Absolutely. RSS just happens to be one of the RESTful types of services that's in need of these types of capabilities. But yeah, I think you nailed it right on the head.

Jon: So, from that perspective, can you spell out a concrete example of one of these more lightweight kinds of HTTP, REST, POX styles of services which is in need of intermediation. And talk through the kind of mediation that can be applied.

Frank: Well I'm going to come at it actually from the other angle. There is no shortage of services today that have WS-Heavy semantics and sit inside of enterprise. One of the problems associated with that is that they can't be consumed in a RESTful way outside of the enterprise.

Jon: Yeah, that's the flipside of it.

Frank: And I think that's much more of a real-world, concrete example. In other words, the reach has been somewhat constrained because of the impedances that exist between more RESTful or POX style models.

Jon: But if you can hit the thing with an HTTP request...

Frank: No, it's more than that.

Jon: Right, the subtext here is that you've wrapped these policies around it.

Frank: Absolutely.

Jon: It's not just firing an HTTP GET at the thing. You have to present a compliant client-side interface that is going to be able to negotiate the policy.

Frank: Yeah.

Jon: Isn't that really the issue?

Frank: Absolutely. So what we start to do is look at some of the concerns as we start to move up the stack. We say "Ok, what are some of the ones that we want to be able to mediate?"

Clearly, security models, so if you want to actually allow consumers that can simply do channel based security using HTTPS, with an HTTP GET using POX and be able to communicate with that same service on the backend, being able resolve that against a WS-Security model that exists for that service on the backend. So that WS-STAR service is expecting to receive a set of WS-Security headers, right?

Jon: Yeah.

Frank: Well those aren't going to be sitting in the message when it comes over in a POX invocation.

Jon: That's right.

Frank: It's being able to resolve those impedances. Being able to resolve synchronicity impedances -- the server that sits on the backend may actually be exposed asynchronously, it may be a process that is exposed asynchronously. And one of the operations on that process may be what you're exposing via an HTTP GET.

Well it may be simpler, from a programming model perspective, for the developer who wants to consume that service to consume it synchronously using a set of HTTP GET over a POX file invocation without having to succumb to the complexities of an asynchronous programming model.

So being able to insulate the consumers of those services from the semantics that they do not have the natural inclination to be able to support. I think that is part of the greater opportunity here. The greater opportunity around this is: don't force people to have to engage with you under the terms and conditions that you are prescribing in your environment, to allow them to take advantage of your capabilities in their native context.

Jon: There is the inverse scenario as well, right? Where you endow the relatively unsophisticated service with a more robust wrapper of security and policy.

Frank: Absolutely. I may have a POX service, and what I want to be able to do is, I want to be able to allow clients with more sophisticated WS-heavy capabilities. For example, addressing, or security, or reliable messaging semantics, or asynchronous communication.

An example of that is transactional systems that have historically been synchronous. Exposing those services directly over the web to a variety of different clients, which maybe sitting inside a partner organization, and doing that synchronously, may actually do things to the system that the system was never designed or intended to support.

Take a set of CICS processes running on the mainframe exposed directly to POX over HTTP. That may not be the ideal scenario. You may want to throttle some of the more advanced capabilities. As an example, let's say that it is much more useful for you to take those process running on mainframe in the CICS space, say it's account data or trade validation data or order management processes from public provisioning prospective in telco space. What you want to be able to do there, you want to be able to expose them to a broad number of clients, provide elasticity -- potentially through mediation of asynchronous to synchronous style of message exchange pattern, then be able to queue those messages up. And as you queue them up, allow those synchronous systems that sit on the back end to gracefully de-queue them at their own speed.

Jon: Right.

Frank: Along with that you may also want those external clients to be able to actually send you a message with a WS-Security header that contains a SAML token. You may want to resolve that internally to channel-based security, as an example. Thereby ensuring that you can have more application-level security infrastructure that you leverage with those external parties, while internally not having to extend your channel-based security to support everybody on the planet.

Jon: These are kinds of mediations that a lot of SOA vendors are providing in WS-heavy space, if you will, but the proposition here is that the same broad range of mediations, are also more broadly available a variety of transports and implication styles and...

Frank: Web service programming models. That is the key. The key is the programming model impedance resolution. How can you do this, right, and not only provide the capabilities within the web services framework of specification. We, basically, have done three things that are really hard. The first of which is providing implementations within the web services framework. The second of which is provide mediations between different versions of specifications that are in that framework. The third thing is be able to actually resolve impedances between web service style programming models.

Jon: So to switch gears, completely, I went and looked at Prosper and that other peer-to-peer banking service that you mentioned.

Frank: Zopa.

Jon: Yeah. Thought it was absolutely fascinating, and not at all from a technical perspective, but more from...actually, last week I was mentioning the Yochai Benkler book 'Wealth of Networks'. The key takeaway for me was something that I intuitively understood, but hadn't heard it articulated in quite this way. The value of loose coupling, in the human domain, is that it creates a new economic capacity in the world. Because formerly, when human beings entered into economic relationships, into work partnerships and collaborations, it always required relatively expensive and durable social structures. It was never the case that people could transiently affiliate, to come together, do work, and then maybe or maybe not maintain that affiliation over time.

You hear this meme in IT contexts. One of them is: IT is moving in the direction of the Hollywood model. It's not just outsourceing. As my friend Andy Singleton likes to put it, it's the just-in-time assembly of software components on the one hand, and of talent on the other, around a project, just like Hollywood is always..

Frank: It is just-in-time capability composition.

Jon: Yeah. Exactly. I think a lot of people, when they hear the term 'social software', they think about it in terms of socializing: sharing photos and having fun together. That's kind of the message right now, but I don't think it has at all sunk in that there is what you just described. This just-in-time ability to compose working relationships or partnerships or collaborations amongst people, to pool not just knowledge -- but in the peer-to-peer banking case, for people to become dynamically composed co-op banks. because it is not at all a technical discussion.

Frank: You and I had been having a conversation around a talk I had gone out and done for for one of our very large financial service customers, and it was the notion of the emerging web, which is what you actually touched on. What are the dynamics of emerging systems? How do the work?

It's very much what we are starting to see. The web is an emerging system. It is the single most obvious instantiation for most people today of an emergent system. The context that I had shared with this particular client was, they have a robust set of capabilities in terms of processes, and in terms of infrastructure for both payment processing as well as for currency exchange and distribution across the globe.

And one of the things that was interesting to them was that here was Prosper, which is a manifestation basically of a market where people were coming together and collaborating to package a loan in peer-to-peer context. Frank and Jon get together and they make a third party a loan under the same terms, and Prosper provides the function of operating the infrastructure and packaging it and servicing it and so forth.

When you look at that, one of the key questions that I posed to this particular client was to allow them to build on you as a platform because they're obviously building their own parallel infrastructure to solve these problems. And when we talk about the economic efficiencies and the focus of social software being around a much more economically evolvable model, it's a question I think a lot of people have to ask themselves.

The question very large companies should be asking themselves today is how do you combine the well controlled, well governed, well defined process spaces you have today as part of your service orientation initiatives? And how do you leverage that into an edge-enablement architecture and infrastructure that allows a brand new set of economics and access to a brand new set of markets that you've never been in before.

Jon: Although I suppose now that I think about it, in the case of Prosper anyway, they are holding very tight control over the financial processes here, right? It's just an interesting kind of web 2.0-ish company doing a new kind of eBay-like thing.

Frank: Yep, absolutely. I think that aspect of it is in fact the part that's most interesting. That and the fact that as a result of this they've taken a function that has primary been within very tall skyscrapers for a very long time to actually being fulfilled primarily by individuals.

Jon: I suppose we can tie this back in some way like this. I actually looked at signing up with them because I thought "I should just put 1,000 bucks into this thing," because I want to see what happens, because I want to have some engagement with it so I'll pay attention to it over time, because I think it's a fascinating model.

When I went to sign up they wanted my social security number, obviously because they had to do credit checks. I asked them if they could assure me that they would not retain my social security number. And they couldn't really deal with that question. So, it gets to this question of, "I'm happy to have you mediate my relationship to the money, but I'm not sure I want you to control my relationship to the credit card agencies." If possible I'd like to have that be a more direct relationship and then have control over how you get connected to that. But that does suggest a model in which we have some kinds of service relationships.

Frank: There's a similar scenario that I've seen. For example, there are today some software-as-a-service solutions that are in the marketplace. And people have retro-fitted them with either REST based interfaces or with RSS based interfaces on top of an existing web service. Or that they'll provide you with some sort of RSS feed that's a view of information that sits behind a web service inside of one of these things.

The security model is that it's using HTTPS. I have to give them my credentials for that particular software-as-a-service provider. It's a completely separate party that's exposing the RSS feed. Same problem. It's like, "Well, wait a minute."

Jon: Well I guess everything is going to keep coming back to Hailstorm until we finally create Hailstorm. But this is that exact scenario. I would like Prosper's request to flow through me, for me to attach a one-time permission to do a credit check. I would like to know that that flows through me.

Frank: Yep.

Jon: If it doesn't need to be a real-time kind of thing, which this is a perfect example of something that doesn't, there's no reason that a message can't flow through me and take a day for me to catch up with and send it along. Right?

Frank: Right.

Jon: It doesn't have to be real time like a lot of things don't. Abstractly, I would like to have an XML message flow to me. I would like sign some attachment to that message for the use of some designated next hop. I would like a return receipt.

Frank: [laughs]

Jon: You know?

Frank: Right, yeah.

Jon: Are we getting anywhere with this kind of stuff?

Frank: I think we are. I think we are coming at it from a couple of different directions. You probably spent your fair share of time with Phil Windley and a lot of the stuff that he's doing around the identity management space. I think there's no shortage of people that are trying to solve this problem and they're trying to solve it in a way that scales. That is really the key.

Jon: Uh-huh.

Frank: Where my grandmother can use it and not necessarily even have to know how it works or what's going on under the hood. But by the same token you and I can use it and understand very well how it actually works and that it's legit. I think that's really the challenge. Making it work in a way that ultimately does give us individual control but by the same token allowing it to scale in way that for all intents and purposes for the typical application really makes it as ubiquitous as possible.

Jon: So this really does tie back to our earlier discussion, because in effect what I'm saying is I would like to assert policy.

Frank: Yep.

Jon: And I would like to assert that policy on the use of my social security number by Party A through me to Party B. It's a really interesting test case.

Frank: Sounds like one you might go after. [laughs]

Jon: Or you might.

Frank: Well, you know, we might.

Jon: That's what I'm saying.

Frank: There always needs to be an individual on the other side to help prove out that part of the use case. But yes, as far as the kinds of things that we're in the business of doing, we're in the impedance removal business.

Jon: Uh-huh.

Frank: That's fundamentally it. That's one half of our business. You nailed the sound bit earlier "it's tolerance plus governance." That's the business of SOA Software. It's those kinds of things that will allow the current and the next generations of the applications and processes and experiences that we're building to really be better for people.

Jon: Well it's certainly the case that I was impeded.

Frank: You were, weren't you.

Jon: Well thanks again and you have a good weekend. I'm aim to do the same.

Frank: Thanks.