About Miko Matsumura

Miko is responsible for Infravio's marketing operations and strategic planning.  He also leads Infravio's Open Source and Standards strategies.  He is founder and Chair of the OASIS SOA Adoption Blueprints Technical Committee and a co-founder of the Apache Synapse project.  

I caught up with Miko after he was returning from a SOA e-Government Conference.  And I was interested in finding out what the general level of understanding and the adoption of SOA Governance were. 

What is the level of understanding around automating SOA governance?

Matsumura: It is coming along; the good news is that everybody recognizes that it is an absolute requirement.  Everybody understands that governance, governance tooling, etc. is a flat out requirement.  But in terms of the maturity level of the understanding – it varies, people understand they have to have it, but some people are at different stages of adoption.  It was a really good mix of people; it wasn’t just like the usual suspects.  There were a number of folks like FDA’s, HUD and the civilian agencies are starting to get involved.  There is a huge potential for benefit to government and there was a lot of discussion of use cases that just make a lot of sense.

Is it going to take a long time for this adoption to happen?  There seems to be “no sense of urgency” around the adoption of SOA governance?

Matsumura:  I think there is certainly a sense of urgency around some of the benefits and one of the interesting things is that across-the-board spending is going up.  A recent study by Merrill Lynch surveyed 87 CIO’s, and indicated 87% of these CIO’s see Service Oriented Architecture (SOA) as being the next big thing, and a majority of the CIO’s interviewed indicated IT spending will be up in 2006, which is an improvement over the numbers when they interviewed and polled in January.  This is mostly a response from the commercial sector, as opposed to the government sector.  The reality is the spending is there, the strategic nature of it is there and I think people are beginning to see it properly; they’re seeing it as an almost decade scale transformation of fundamental IT systems.  So when you talk about urgency you see it is really a balance between urgency and importance.  I think people see it as important and I think it’s an iterative process for it to become core to their business.  I think what we are really trying to do is to help mature people’s perspective on what this urgency is all about, and how they successfully put up some value in SOA and use that value as a kind of a wedge to grow their whole program.

You are probably spending a lot of time educating people about SOA Governance?

Matsumura:  Certainly a lot of education is necessary just because the depth of understanding and learning that is required to build a mature infrastructure is fairly deep.  At some fundamental level we’re talking about enterprise scale, federated, and distributed computing which has a 20 to 30 year vision history.  It is something that everybody has been trying to realize over a long period of time.  What I find fascinating is that people are beginning to see some of the benefits coming within view and into reach.  Because of this there is a buzz and excitement, and I think there’s a lot of good activity happening.  In terms of the adoption lifecycle, some of the finer points of how to do this properly and how to get the most value of it are definitely an educational process.

What kind of factors should a Customer consider about SOA Governance and what would you like to communicate to customers who are interested in SOA Governance?

Matsumura:  I’m really interested in communicating some of the fundamentals about why this is an important topic and I’m really trying to communicate a little bit about fruitful ways of thinking about the topic.  One of the things we discovered in engagements is that there isn’t a canned set of answers and that answers are use case specific, situational and it depends on a bunch of dimensions that are critical.  People usually ask us “what they should do”.  What you should do varies and depends on a number of axes.  So what I like to do is give people tools for thinking, and that will help them apply those tools to their different situations.

The first thing I like to do is articulate the importance of understanding how to classify your situation.  I think one of the most important things is to think about the maturity of your situation.  Other axes to look at include the major goals that you're seeking: interoperability, higher speed of development, lower risk, the ability to create an overarching policy environment which is about control and there is a variety of values that factor into whether it is reuse or agility.  This is one thing that is an important variable in decision making.  I think the other realization that people come to as they mature is whatever they're seeking to get as a value is pretty intimately tied to the maturity, the governance capability and the constraint model, and all of these types of components.  One of the really important things to look at is the balance between the constraint model and the opportunity model or ROI.

This is a good perspective to take since the answer depends on where you are coming from.

Matsumura:  I think it is a little insufficient just to step all the way back and say that it depends, since this is a universal and completely unhelpful answer.  What I like to do instead is provide a set of metaphors which I think are applicable and I also can come up with a set of the dimensional axes.  One of my dimensional axis is there are really certain telling attributes that help you understand what to do.  One of them is clearly maturity.  Another dimensional axis that is really important is a use case of whether you’re planning to go external, whether you are talking about the scale of your deployment.  And the scale of your deployment is whether you are going to include external partners or multiple business divisions or are you constrained to a single division.  The skill and the concerns of doing a single division versus multiple organizational boundaries are dramatic and that’s a huge difference.  When you talk about multiple organizational boundaries whether they are within operating companies or divisions or whether they are across companies.  In either case, you’re talking about where governance skills sets and politics and things like chargeback, who’s going to pay, etc. all these become burning issues.  Sharing services all of a sudden becomes a political issue as opposed to a kind of like a default modus operandi.  Creating the culture and the structure for sharing is essential; creating the trust relationship and the incentive is also critical.  One of the key issues of what to do depend on the scale and this is one of the things I like to get people thinking about.  Is your SOA destined to cross organizational boundaries, because if it is you need to start thinking about those issues, but if it is not then you shouldn’t.  That is one of the reasons that I like to point this out.

What other factors should people look at?

Matsumura:  Another thing I like to help people with is the idea of granularity.  Granularity is really, really important because that governs very strongly the types of behaviors that make sense.  So the granularity issue is related to the level of application functionality you are worried about.  Some people are worried about integrating disparate ERP systems.  They’re worried about data integration of deep backend systems using web services.  Those things are a fairly fine grained and technical in nature but I think that carries a very dramatically different set of best practices, than if you are doing something at the business service level of granularity.  Which is extremely coarse grained and transactional and is very front end.  Skills that relate to doing hard-core data integration and Java programming and backend service ERP integration are different from the skills that have the do the front end things like Web 2.0, Ajax, mash up, and all those types of “front-end” types of things.  Even things like in a business process, things of that nature, and those types of SOA’s are pretty different.  The other thing I like to ask people to pay attention to and understand is the level of granularity they are seeking to optimize.  Some people are very low level and some people are very high level and I think that dimensional axis of granularity is important because it dramatically changes the way you think about it.

I like to look at SOA in three stages and in the second stage of SOA interoperability becomes important.  In your experience where are customers in the adoption curve and is interoperability important to them.  Was SOA-Link customer driven need for interoperability or was this more of a marketing initiative?

Matsumura:  It is very much customer driven.  The reason it is very customer driven is because what we found when Infravio launched this initiative was that we almost got overwhelmed by the response.  We did not expect 16 vendors to jump up and say that they wanted to be included.  We were very favorably impressed by the response.  What we realized was this was kind of a woodwork effect.  We have vendors that popped up and almost announced themselves.  For example, we had one vendor approach us and say “did you know that we are already integrating with your registry/repository in the context of text messaging and services, etc.”  Vendors said that “they were already integrated with us, and we want to go to market with you because we have done the engineering work”.  It is funny when you're at the level of registry/repository you are almost providing an operating system level functionality for distributed services.  What you have is vendors building on top of your infrastructure that you may not be aware of.  That's the irony of the repository, with standards-based interfaces you end up with, and you find that you have vendors already plugging into your system.  What we found was vendors that came out of the woodwork saying we already integrate with you with a customer x ie. Amberpoint, etc.  These vendors told us that that they are already in this account and integrated with your product.  In terms of whether its vendor driven or customer driven, we basically see it as very customer driven.  In a lot of these cases the solutions are just replications of what has already been successfully implemented in a number of customers’ environments.  So we were pleasantly surprised to hear from vendors that had integrated with the Infravio X-registry platform and some of these vendors who we had never heard of before.

What makes SOA Link different from the Governance Interoperability Framework (GIF)?

Matsumura:  There are two different types of approaches.  There is an orthodox standards based approach where the correct thing to do is to create novel API or protocol set that really locks down interaction and this creates kind of open standards-based process.  That is one approach.  I think there is room for that and that ought to be done.  The fact of the matter is that the customer requirements for interoperability transcends and exceeds what is available in standards today.  So that’s one kind of approach, the other approach is what we think is the “SOA Link approach”, it is kind of a social network or a peer-to-peer approach.  It is based on public assertions of interoperability, and is a kind of pragmatic ad hoc functionality delivery. 

SOA Link follows the second approach.  And in terms of how it differs from GIF, we feel GIF is the worst of both worlds.  The reason we feel this way is because it is not a standard and yet asserts a single kind of API.  It is not open nor is it a sort of pseudo standard.  That being said, in terms of its ability to provide interoperable capability for their customers, we feel that is good.  Delivering interoperability between vendors is good, but obviously the positioning of a single API as a pseudo standard doesn’t provide any additional value from our perspective.  The best solution might be for GIF to be submitted to SOA Link and become one mechanism, or style of integration between vendors, and in which case we would find that alright.

We really see this difference as one style of integration.  GIF is being positioned as a standard when in fact there has not been any kind formal public publication as to what it is, other than a press release.  There's no formal standards body connection and I want to be perfectly clear, SOA Link does not have any formal standards body connection either; but SOA Link itself is not mandating an API so there is no API to hide from view.  The goal of SOA Link is really almost like a good housekeeping seal.  In that sense what we are really articulating is the desire to be transparent about our intent to integrate and it’s really about delivering the functionality to the customer.  Either way, as a customer, if you buy products integrated using GIF you will get the same result.  From a customer perspective getting the integration, whether through GIF or SOA Link that shouldn’t matter to you at all. 

Some of the competitors in your space think SOA Link is a marketing play and not a real standard.  What is your view?

Matsumura:  Obviously those folks who want to have interoperability, in a similar vein are probably not all that happy that they didn’t do it first.  And the reality is that it depends on what you think SOA Link is.  If you think SOA Link may be submitted to a standards body, or it is going to be a standard, or it will evolve into this grand future vision of interoperability across all software products, I would say that you are missing the point since SOA Link is not that type of thing.  It is possible that some of the best standards could be submitted as technical notes, and they could have the potential to impact the development of standards.  This could happen based on the extent that our end-user customers are willing to step up and submit use cases and to help the relationship with standards organizations.  However, we see that as an orthogonal issue and we also see that as an emergent property rather than fundamental goal.

Who have you partnered with for SOA Appliances?

Matsumura: We partnered with Layer 7 Technologies, Reactivity, with DataPower (although they aren’t part of the SOA Link program), Forum Systems and others.  We have a number of partners that supply that style of functionality.  We find that different customers have preferences when it comes to that area, and we certainly want to accommodate them all.

You work with a variety of different products and your product is not tightly coupled to any one vendor.

Matsumura:  That is the nature of the SOA Link project - interoperability across products within a stack environment.  When you look at some of the bigger vendors, their solution is pretty simple from their perspective and that is to buy everything from them.  And frankly, there are several pluses and minuses.  On the plus side the customer gets what they bought from one vendor, and with a single source you probably get what you want in interoperability.  On the minus side it provides a lot of account control for a single company and that may not be desirable and there may be a need to counter balance that and so that is the way we look at things.

The other thing I think is a little bit unseen at this point is interoperability even within single source and vendor platforms that are stacked that isn’t a fait accompli yet.  In the sense that we know it's coming, but presently that stack level interoperability within a single source is still FUD in the sense if you look at someone BEA and AguaLogic they just acquired Fuego, and if you look at the history of SOA and within that framework IBM essentially just acquired Datapower, it hasn’t been that long.  And so the level of integration, even within the unified stack strategy isn't really complete either.

Yes, but these Stack Vendors are working to provide end to end solutions.

Matsumura:  Despite the fact that the stack vendors are going through that process, we have accounts for example, like British Telecom where we are embedded with IBM and we are doing integration with IBM products.  We don’t provide the box functionality and we are in a completely different category.  What I am suggesting is that customers’ demands are driving interoperability across stacks and across disparate product functionality.  The jist of it is that customers really have achieved a level of sophistication today with their SOA requirements.  What I am seeing in terms of RFP’s is that these RFP’s are pretty robust because of that vendor selectivity and the amount of leverage that the customers have.  They are really doing a good job of playing vendors against each other.  They are keeping people honest and they’re mixing it up and they are no longer looking to sole source these solutions because they are paranoid and want safety to keep everyone honest.  Rather, we are seeing customers who are strong enough and feel that they can control and manage their own accounts.  It is a healthy environment when customers are smart and sophisticated and we are increasingly surprised to see how much knowledge transfer there is.  We are not exactly sure how this is happening, but customers seem to be congealing on some functional specs and we are seeing RFP’s converging.  [Maybe customers are sharing these RFP’s?]

Do you want to talk about what differentiates Infravio Registry/Repository from everyone else in the SOA Governance space?

Matsumura:  Absolutely, I think that we probably have the most sophisticated treatment of policy authoring and enforcement in the registry/repository space.  One of the things I really want to highlight is that we have a rules engine, basically JSR 94 compliance Java rules engine that is integrated into the product.  What this enables us to do is manage assertions in a way I think is very robust.  What tends to happen in mature policy environments is that you have multiple constituents.  It creates two different challenges for product companies.  One challenge is a policy authoring problem, and what I mean by the policy authoring problem is that a lot of vendors think of policy as being very monolithic and tend to view policy as being the domain of the developer and architect.  I understand and agree with the view of the architect as the prime mover on policy; but they should not be the only constituent involved.  One of the things we feel is critical to policy authoring within our environment is to have multiple policy authoring interfaces, all which back into the rules engine.  We therefore have declarative XML based authoring, and we have web-based user interface type authoring which appeals to the business user constituent.  We have built a variety of tools to ensure the authoring of policy is not restricted to a single user type nor is it restricted to a single lifecycle stage.  We don’t feel that any small subgroup should own SOA policies.  That is one major positive that we been able to succeed in with our products.

There seems to be a lot of confusion on who should manage and control policy?

Matsumura:  Here’s my view on who controls policy, which I think is essentially a maturity question.  The way I like to describe it is like the evolution of the rule of law.  There are like four maturity stages.  The first stage I call the Frontier.  If you look at the frontier, who controls the law?  The way I like to describe it is the saloonkeeper and the cowboy.  What it means is that it’s basically about the developers.  The service providers and service consumers are in collusion and they control all the policies, because it is the Wild West and that’s basically how things are.  And in that immature environment the policy framework is not being controlled and there is no oversight.  There is no overarching control of policy and it is just being done on an adhocracy basis.  That works for a while, and the fact of existence and the economic vitality of saloons in the Wild West prove this functionality in the early maturity stage.

The second stage when you get past the frontier stage is what I call the Wild West.  What happens in the Wild West stage is that the sheriff gains control.  What I mean by law enforcement in this stage is policy enforcement, and the sheriff becomes the policy controller.  In the IT world that becomes the responsibility the IT operations crew.  The IT operations crew use things like security gateways and policy enforcement boxes to control the policy environment.  You end up with people who are on the IT operations side dictating security and driving that into development.  So developers have to adjust

because they no longer have a monopoly on the firepower in their local domain.  Now they have law enforcement to contend with.

The third stage is basically what I look at as being the emergence of local government, and what I like to think of as a “Hanging Judge Bob”.  Hanging Judge Bob shows up and he becomes the law and the sheriff now becomes his right-hand man, and the sheriff becomes the one who strings them up.  Hanging Judge Bob becomes the guy that makes the law, and in this case is like a line of business person.  If the LOB person steps up they become the hanging judge.  They become the local policy authority and give the orders to string them up and run them out of town, whatever.  That is the third stage of authority.

And as you can see, you’re starting to see a lifecycle story.  And in the beginning of the lifecycle story the developer controls all policies because they’re the only ones in sight.  And the saloonkeeper has a shotgun on behind the bar and law and order is going to prevail but whether that is reflective of any grander design other than like stay the hell out of my bar or you are going shot that is the limited understanding.  What you see is maturity and the start of the IT shop getting involved in policy design which I think is an improvement.  In the third stage we basically see the line of business getting involved and I think this is a healthy sign.  What this starts to do is align the interest of the Business with IT Department and you start to see the policies coming from the business.  So what that means is the policy person steps in to give direction and asks for ease of use, makes sure that versioning is under control and makes sure we have control of access a certain types of policies, etc.  The fourth stage is the emergence of the federal government.  What that means is it is no longer the domain of LOB person, and but actually things like regulatory power come into play and organizational power and central IT start to emerge as the stakeholders in the enterprise SOA policy management.  We see this final stage being the most mature stage where multiple constituents author policies. 

So what I’m saying, because of a mature multiple constituency policy authoring environment you actually end up being potentially more efficient and optimizing the business environment.  But on the other hand there is no way you are going to reach a level of maturity if you don’t have the infrastructure in place such as a bunch of courthouses at things of that nature.  I guess that is what I mean by maturity.  The last point in terms of our product is that our rules engine it enables the system that automates policy reconciliation because the other issue that addresses is that you now have multiple policy authoring environments and stakeholders how do you deal with the situation where one set of policies and  another set policies comes into conflict.  What is interesting in a rules engine environment is it is entirely declarative framework that actually has the facility for managing these interactions in a consistent way.  That is a powerful advance from our perspective.

Do you get policies based on induction reasoning (based on probability) in addition to deductive reasoning?

Matsumura:  Absolutely.  Those are interesting use cases.  That is where we get into flexible change time governance and we get system generated policies and things of that nature where you actually have flexible dynamic filters.  There is a variety of ways to manage flexible and dynamic systems style policies.  And from that perspective I think that policy authoring becomes fairly dynamic and robust.  I think the good news is that within a system that has robust governance capabilities, alerting, and notification, things like a rules-based engine what you end up with is a system which is much more responsive to changes of that type.  What you end up with in those systems is cascading values and cascading values ultimately relate to the defense of divergent interests.  So one group say IT support may have an interest in deprecating as many services as possible to reduce overall support costs.  While on the other hand, there may be in the interest LOB to maintain as many running services as possible in order to maintain as much surface area for customer transactions.

In those types of situations in enterprise SOA it is really important to have dynamism and some automated policy management, but to have reconciliation, escalations, alerting, approval, and they have a really robust system that enables for federation and control of interest.  If you look at the metaphor of federation and federal government, what you’re really looking at is the blend or control and the defense of interest whether it is the interest of the state or interest central authority or the interests of individual citizens.  Taking that metaphor of government to that extent becomes multi-constituent really fast.  Any system that really focuses on the dominance of single consistence by right of obfuscation, or by right of interface, or any of the traditional mechanism of control, I think misses a lot of a paradigm shift.  If your policy system favors a constituency, whether it be technical or whether it be lifecycle driven or even if it favors a constituency based on the physical location of a registry; or any of these funny little tricks; I think you are not going to be able to maximize the benefit of the system.

Do you find that policies are bubbling up to the surface, issues people should be talking about that they were avoiding talking about before?

Matsumura:  This is a maturity question and these types of problems only emerge when you have divergent multiple organizational interests within your SOA.  When you start to do B2B stuff and multi-organizational stuff, these problems are instant and are full-blown.  Crossing of organizational boundaries is a major milestone for an SOA.  The whole question of maturity is one where you start to require robust infrastructure for managing desperate policy holders and constituencies.  That’s where the design center platform speaks to and that is why we have been excited about what we have been able to deliver with integration and with the rules engine.  We feel we’re able to bring a customer through stages of maturation over SOA to the point where they are able to be reached at a very robust level.  That is the kind related to the product we think represents a very high value for the most advanced customer.

Maybe what happened in the Enron ruling today will precipitate the business to get involved more in Governance?

Matsumura:  Enterprise wide policy management is a really big issue.  I think the repercussions of ignoring are a little too clear.

Are you finding that most organizations when you talk to them about SOA Governance did not have any type of Governance at all within their organizations?

Matsumura:  No that’s hardly the case.  We see that there are multiple layers of governance and there is typically a top-down level of governance mechanism that relates very strongly to things like portfolio management and to things like financial controls and things of that nature.  We are actually seeing a pretty robust practice forming around ITIL and around things that enable increased robust governance from the top down.  We’re really not seeing is much sophistication in things like lifecycle governance and things like metadata management and the fine art of really dealing with the multiplicity of perspectives that come into managing both services and metadata.  Far be it from us to say that we are the first of sign of the SOA governance in the account.  But in terms of the being able to extract whether we increase the re-use value for increasing trust, reliability and quality of service, or whether we enhance the agility value, which is a function of the ability to constrain all of the crazy use cases that people come up with, and we’ve feel like we’ve done a lot to add in those areas.

Sounds like you are in an interesting area?

Matsumura:  It is very exciting and kind of fun.

------

I had a good time talking to Miko and especially liked his colorful analogy of policy management to the four stages of the Wild West.  I think Infravio has put a lot of thought into how to manage Policy Authoring, and the management of Policies in multi-constituent environments.  Their product seems to be very mature in this aspect in comparison to many of the other vendors out there in the SOA Governance arena.

More information on Infravio’s products can be seen at www.infravio.com .

__________________________________________________

>>  Back to Main Page

Gary E. Smith
SOA Governance Architect