We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Transformation in Action

Joe McKendrick

SOA Governance Keynote Transcript: Larry Fulton, Forrester Research

Vote 0 Votes
The following is a full transcript from Larry Fulton's keynote presentation at ebizQ's SOA Governance conference earlier this fall. (Archived presentation available here.)

Beth Gold-Bernstein:  Hello and welcome to the ebizQ SOA Governance Virtual Conference.  I'm Beth Gold-Bernstein, Chair of the conference.  Before getting started, I'd like to review the features and functions of our interactive virtual conference environment.  We have a networking lounge where you can chat with other visitors and joined a forum discussion.  

This conference includes virtual booths or you can chat with company representatives and download information.  Visit all the booths for an opportunity to win a prize.  To submit a question, click on the "Ask a Question" button on the gray console.  To download a copy of today's presentation, click the "Files" button.  To enlarge any of the slides, click on the magnifying glass icon to the right of the slide.  

If you missed any of the sessions today, or would like to recommend them to a colleague, they will all be available for archive viewing.  Now, I'd like to introduce our keynote presentation by Larry Fulton, Senior Analyst for Forrester who's going to give us a glimpse into The Future of SOA Governance.  Welcome Larry and thanks for joining us.

Larry Fulton: Thank you Beth.  As Beth said, my name is Larry Fulton.  I'm a member of the Forrester team that serves enterprise architectural professionals.  I work on a regular basis with EA folks like yourselves on the general practice of enterprise architecture.  I'm responsible here for SOA governance coverage as well as our ESP coverage.  Today, we'll be talking about The Future SOA Governance.  

I certainly like to thank ebizQ and our sponsors as well as all of you for taking the time to join us today.  So the theme today is about obviously about The Future of SOA Governance.  But one of the key points that I want to make sure that I make for everyone is that there's a definite difference in the world between those programs with effective governance and those SOA efforts that are not using any real governance practice.  

We see a lot better correlation of effort to results, a lot better, obviously, measurement of results, and generally just a more control and understanding what's going on with their SOA programs among those clients of ours that are actually doing SOA governance.  The big question, of course, is what exactly is SOA governance?  Well, the first thing to understand is that SOA itself isn't really a technology.  

You cannot go buy it SOA in a box.  There was something of an amusing story a few months back when somebody put SOA in a box on eBay.  I think the bidding made it all away it up to $11 or something like that.  But anyway, its more about the way that you build systems, it's an approach that has to permeate your end-to-end development processes and so it's really not a technology.  

Now clearly, SOA is about services but it's not really just about services, it's about the right services.  So the goal is not really to just turn out services but to create things that want to add lasting business value.  Collecting what you have and labeling them business services, that doesn't really get it done.  Having every project build what they think is needed so that other people can take advantage of it, that doesn't really get it done either.  

That leads to a lot of unnecessary duplication and generally poor fit for a long-term use.  It's not just about software development either, you can build the right services but you really want to have a good consistent perspective in how they're identified, how they're designed, and how they are their used.  In other words, how they're going to actually serve your business.  What it really means is you want to be able to institutionalize new principles and approaches.  

So SOA governance is how you're going to make that happen.  So it's not just about building the right things but making sure you can build them consistently.  So let's talk about how you is to institutionalize new ways of thinking because that's really the challenge.  What you're trying to do is make hundreds of consistent small decisions across many projects.  You're going to use services, build new services.  

It's easy to you imagine any enterprise going down this path and find itself with hundreds of new services.  And how do you make all these decisions consistently?  That's really the challenge of how do you institutionalize new ways of thinking so that you can be successful with SOA.  Well, the answer to the question is that you've got start with a vision.  It has to be clear what you're trying to accomplish, you need to make sure that it's clear to everyone who's going to be a party to accomplishing that, and that's an important success factor.  

From a vision comes a policy or really a set of policies.  So what does this vision mean in specific situations?  What kind of decisions have to be made and who's going to make those decisions?  What things are fixed?  What sort of things are you going to say, look, this is just how we're going to do it; we're going to innovate in other areas.  So that's part of the policy picture either as well.

Finally then, the goal is to take these vision and policy and drive them that into processes.  You've got machinery in place within IT that lets you make these same decisions consistently across the board.  So process is really the answer but it needs to come from a consistent vision.  Now in the early days, you're not going to have a well-defined process where everyone knows what their job is and how it's impacted by this so you're going to end up with more daily experts involved.  

In fact, in the early days of your SOA journey, you're going to have a relatively small number of people involved.  It'll probably be a pilot project or two then you'll broaden the scope a little bit and over time involve your whole development organization.  

At the same time, you're going to have a small pool of experts who are going to help you work all this out in the beginning and over time, you'll want to reduce your dependency on those experts.  And again, this is the same idea of you trying to put a process in place so that the decisions that used to be made by experts ultimately are institutionalized and are made by people following the defined process and best practices that you have.  

So since that's our objective here, let's talk about SOA governance.  Here's a couple of definitions.  SOA governance touches all aspects of SOA with the goal of making good decisions consistently as they are needed.  There's several ways to drive home the point that governance is an essential ingredient.  

One of the challenges as we always face here is that the term governance is used in many different contexts.  A real differentiator of SOA itself as compared to some earlier changes in the evolution of IT is the ongoing discussion of SOA governance.  If we think back to the days of client/server, or the introduction of object orientation, or CORBA, or web applications, or even Web 2.0 technologies, those never really generated fundamental changes or improvements in IT that they promised.

Sure, they all gave us new capabilities and they helped us deliver new functions to our users, but they didn't result in a fundamental change in the way IT does business.  Now, after promising that kind of change, but more important to us right now, in fact, that the broad industry interest in SOA is accompanied by plenty of discussion about SOA governance and the best practices needed to make it work.

So here, you see Forrester's formal list of the key areas of SOA governance.  The business strategy and objectives are always the lead dog here driving out the specifics in each area.  SOA governance fits within four area of IT governance or you could also say it covers those areas; it surrounds them in the SOA world.  Portfolio governance brings the business strategy to near term focus delivering project application business service objective for the next 6 to 24 months.

Technology governance supports evolving current technology portfolio where it needs to be to meet upcoming business needs.  Project governance is all about the decisions made on the critical path to delivering business solutions.  And finally, service-level governance, which is sometimes called runtime governance, is used to monitor, manage, and enforce runtime policies in service levels.

Here's a somewhat simpler picture that outlines the major SOA governance disciplines, and we're going to use this to talk about SOA governance and where it stands today and what's happening forward.  Design-time is those things obviously that happens prior to a service going live.  It includes everything from what kind of services do we need, what the interface look like, how are we going to validate that the service is doing what it's doing, or doing what it's supposed to be doing rather and all of that sort of thing.

Except for development-time, which is the actual software development, building the code, assembling the pieces that have happened.  We've also go run-time governance, which as I said refers to what happens out in the production environment.  And then a platform governance is a term that we use to talk about the processes that you use to plan and involve your fiscal platforms, which would include middleware like enterprise service buses, or service management software, as well as things that have been more traditional parts of your middleware platform like messaging systems, and possibly older components, like EAI tools, and things like that.  

One interesting addition to this list is what we call SOA policy governance.  it's an emerging area where we start to talk about policy in the broad scope where we're not just focused on lower-level policies like what security attribute should be assigned to individual services, or what individual people are supposed to be able to do, but mapping those all the way into what is the enterprise's policy for security and tying that together so that you can actually work with those things at a higher level and be having discussions about how they apply to individual services.  

Okay, this next slide highlights what I would call the most mature disciplines in SOA governance.  And by mature, I mean these are the ones that are best defined and are more broadly being used in the real world.  And you see here service lifecycle management and then the runtime governance disciplines of security and policy enforcement and of course service-level management.  I don't want to talk about service lifecycle because it's such a critical piece and because it is also one of the more mature disciplines.  

So here, we see the components of the service lifecycle.  And right now, there's two different components here.  There is service creation on the left and service consumption on the right.  The basic sequence of activities we'll talk about in just a second but the point here is that service creation and service consumption are two separate things because for typical services is supposed to be built once and it may be consumed over and over again in multiple business context so these two are really separate.  

Service creation includes the steps you see here.  The goal is to answer these questions but the first step is to say, well, what's the functional definition?  Why are we building the service?  What is it really doing for us?  Then once we have that worked out we're going to want to build an interface or design an interface for it that's consistent with the other way other interfaces work in our organization that meets the needs of the functional definition and that hopefully will be broadly applicable in multiple business context.  

Once we have that design done which clearly defines the functionality, then from there the service itself has to be design built and of course we need to go through a validation process of testing and other activities to make sure that the service really does what it's supposed to do.  The other half of this equation is the consumption process.  

And here you see we start with the issue of service identification, which is really nothing more than identifying those services that may be appropriate for what we're trying to accomplish in this particular project.  Once we have an idea about that then we'll move into what's called contract negotiation where we're going to work between the service consumer and the group that's responsible for the service to identify if there is any new capacity needs, if it's in fact the right service to be used, make sure that we got planning in place to get it to development, and test environments to support the project that kind of thing.  

Once we've worked out those details, then we actually need to do physical service deployment if that's required and move it to a final operational mode where we're  obviously running the service but we're also make you sure that the service continues to meet its targets for service levels and other things.  I want to talk a bit more about service consumption because this is part of the service lifecycle that is often misunderstood.  

A lot of organizations have some kind of service catalog and they allow developers to really freely include services from the catalog in their work.  This can lead to a lot of problems not knowing who's actually consuming which services, unexpected capacity needs discovered in production, or even just using the wrong services.  

Consumption contracts provide the means to address all of these things upfront before any work has been done.  Essentially, the consuming party is really registering an interest saying, hey, we want to use your service.  This gives a service provider the opportunity to get involved and learn what is needed.  Maybe suggest an alternative service, plan ahead for any needed capacity increases, and also work collaboratively with the service consumer to establish appropriate service levels for the service use.  

The result of this exercise is a service consumption contract.  A service provider will have a contract for each service use meaning multiple contracts for each service.  Likewise, the service consumer will have a contract for each service they use, each one potentially tying them to a different service provider.  Even better, the service contract serve at the organization's record of the relationship so everything from deployment, to [INAUDIBLE] planning, to impact assessment can use this information to drive appropriate and proactive decision-making.  

The other thing about service contracts here is the effort to initiate one can serve as the trigger point to kick off activities like capacity planning, like making sure there's an environment ready for doing development work against the service.  Like discovering that the production environment doesn't meet the needs of the target used because is not available 24 x 7 and that sort of thing.  Another thing I want to touch on here is service portfolio planning.  

The process is shown here and consists of taking a look at the solution roadmaps or in other words the business solution delivery projects that are slated for a period of time.  Evaluating them against the services in your service portfolio and then providing an updated roadmap that tells what services need to be added or modified, possibly re-factored or combined, and maybe even retired over that same period of time.  

Typically, we recommend that companies do this in a cycle where they would provide an updated roadmap every 6 to 12 months and each roadmap would sort of envision the period maybe 12 to 24 months out effectively giving you a sliding window.  And the other key thing that's important here is that not just the process but what does it really mean to have that that service portfolio?  

It's really the collection of your digital business capabilities so it's an important business asset and it needs to be reviewed and updated so that you can maintain and increase its value.  One of the things that we tell clients is that if you look at most businesses today, they are large enough that they really can't do something new, they can't pursue a new business opportunity, or change the way that they're doing business.  We're not making a change in some business process.  

Very often you can't make a change in the business process without modifying one or more IT systems that support that.  so we talk about moving to a SOA world, and the various business capabilities being embodied in services this very much is this portfolio here is very much the embodiment of your digital capabilities, and in fact, your business provides so it is really a very important asset that needs to be treated that way.  So here again is the service lifecycle as well as the portfolio management component at the bottom.  And I want to illustrate here the difference between service lifecycle itself and service lifecycle management, which is really where governance comes in.  

So the service lifecycle identifies the steps that we go through or more to the point the steps that the service goes through throughout his life.  When we talk about really having a governance process, we're talking about putting some sort of checks and balances on top of this, which might look like this.  Here each step of our lifecycle has got a review and approval component.  To just use one example, consider the service interface design step at the top.  

There may be a set of standards and guidelines that are provided as part of the governance activities to developers and designers so that they know what's expected.  You may have specific deliverables that interface designers need to provide whether they be text descriptions how things work or what they're supposed to do.  They might be [INAUDIBLE] definitions in the case of Web services interfaces; they might be message definitions in the case of JMS message interfaces and things like that.  

And they're provided into this review and approval activity.  and the red and green lights indicate that here's an approval checkpoint where if it passes muster and meets our usual set of guidelines and seems to be the right thing for the business then we'd  give it the green light to move into development.  But if not, it might be a decision to go back and rework something or change something.  And in fact, this is very important too when you think about working with outsourcers who may build services.  

You ultimately want a complete set of services that's more or less consistent in the way things are named, and the way things work, and the way various schemas are employed so that data is easy to work with.  And so you probably want to have all of the service interfaces whether they're built by outside people or built within your own four walls go through the same process so that ultimately you'll have a portfolio of consistent services.  And again, you can apply these same governance models to any of the other components of the lifecycle.  

So now let's take a look at some other things.  I've called these common ad hoc disciplines, which is not to say that they should be ad hoc but that in organizations that do this at all, it's kind of an ad hoc effort.  Service portfolio planning which I had just talked about before is something that we're starting to see people take more of an interest in.  

So you do have organizations taking a fairly formal approach but the majority of companies that are actually doing this are taking a look at individual requests for services and individual projects and saying, well, rather than just building according to those needs, let's have kind of a portfolio mindset, and think about all the other services we have, and the other projects that are in flight and kind of consider those things as we make our decisions so that kind of ad hoc approach is sort of where we stand today.  

Another ad hoc discipline is in the area platform governance.  One of the challenges there is that very early on in an SOA journey; people don't usually have the budget for big bang efforts.  People are not talking about, hey, let's replace enterprise infrastructure, not that we would ever recommend doing such a thing.  You've got the challenge of probably a lot of existing infrastructure.  

Ideally, you'd want to have  one has an idea good plan for migrating from where you are to a more cohesive SOA centric kind of model but that takes time and energy  so we see this happening kind of in an ad hoc way.  Likewise, with the implementation management, which is really nothing more than saying what pieces are we going to implement this year and can we do this in a way that minimizes impact.  One of the other things that's interesting about this is we do get questions from clients about how -- about these escalating support costs.  

And then if you ask them, it's like  well we got four EAI tools and we've got three different messaging systems and that includes multiple versions of JMS and all that and now they're adding an ESB, and maybe they're adding two AFBs for whatever reason and they're wondering why their support cost continued to increase.  Well, say, well look, if you had eight things and you add two more that's a 25% increase in complexity.  Why wouldn't you expect a 25% increase in cost?  

So the point that we'd try to make with people is at some point you need to decommission some things.  You can do that through attrition but that doesn't usually move as fast as you'd like so part of an overall IT platform plan usually needs to consider, hey, when is it appropriate to  invest in downsizing the infrastructure so that we're not just faced with escalating cost situation.  Okay, a couple of other disciplines I wanted to highlight that I would consider merging in future by which I mean there were people thinking about it.  

There are even some vendors thinking about it but any companies that are doing this are pretty much carving their own path and I wouldn't call it common at all.  On the policy governance front, what you're starting to see vendor tools that that work with policy beyond the, hey, let's attached security policies to a service.  That kind of policy is fairly common but dealing with this in an enterprise level and providing traceability from enterprise policies, like we protect our customer sensitive data from intrusion, or that kind of thing and really tracing that down to -- and that's why we do this to the code, or that's why we do this particular configuration in production, which you're starting to see vendors talk about products that can help do that kind of thing.  

On the development time side, you're building services, there's no reason you can't apply some of the best practices for development that we've seen in the past and say, hey, the internals of these services probably want to be built according to a limited set of patterns so that we have a limited number of things that we're working with and that there is some consistency.  

The other thing we see commonly is a lot of people are doing integration using things like ESB's, but that's done in a very ad hoc way.  We're starting to see people talk about, hey, let's try and do this integration in a way that gives us service oriented benefits down the road.  In other words, we define those integration points in a service oriented business friendly kind of way.  So we're just starting to see that happen but were not seeing a lot of product support in either of these two areas right now.  I want drill into the policy thing a little bit to sort of explain what some of the benefits are.  And this gets to what happens when you use policy at the actual implementation end of things.  

So here's a service that's built without policy.  So you've got some kind of service interface and here it's the get reservation interface.  And the implementation takes on certain responsibilities, which is to say, I need to make sure that I have access to this reservation.  I need to make sure that if that's not the case, or if there's some other problem, I can generate some kind of fault.  And if all these security things are okay, we're going to go ahead and proceed with the reservation.  When you employ policy, what you can do is take some of that out of the development cycle as shown here.  

In this case with security policy, there's an intermediary component that works behind the interface but essentially doesn't invoke the implementation unless all the security issues are taken care of.  So where we're already seeing this happen both in some of the products that are out there and to some extent SOA management and ESB products can do this.  We're also seeing people use those products to build composite applications where they're separating these security concerns from the actual business implementation.  

And so then you can change the security rules without having to change all the business rules and you can also implement the business rules without having to get in the middle of security every time.  So this simplifies development quite a bit and gives you a lot more flexibility over time.  If you take this with logical conclusion, you can use a broader policy and say, look, we're not just interested in just security but were also interested in maybe there's a regulatory need for auditing that would cause us to alert something.  

Maybe we've got a performance policy that says we -- if the response is slow we want to kick something in.  It really could be any number of things.  So this again, says there's a lot of other things we may check for in business logic but we could take that out and make that part of policy.  So when you start to look at the advantages of thinking about policy, this is why we start to think about policy as a future just emerging governance area because it's such a powerful area and there really need to be some good processes to get the most benefit out of it.  

So I want to wrap up today by talking a little bit about each one of the SOA governance disciplines and giving you an idea as what we see that Forrester in terms of what people are doing today, what we see happening in the near future, and what we kind of expect will happen over the horizon.  so you think about the design-time picture, and again, this is where we decide what services we need, and how they're going to work, and make sure that they actually live up to those expectations.  Today, we see commercial lifecycle solutions.  

There's a number of vendors that have these so-called SOA repositories, we prefer calling them service lifecycle management solutions that put in the approval process and help you manage the Meta data for policies, and service definitions, and even help deploy those things.  And what we're seeing is that you're starting to see those products and other products in the EA modeling space start to have some support for portfolio management kind of  alongside customer interest that's growing in that space.  

What we expect to see in the next year or two is contract management features in those tools both expand in their capability and also expand in their use among clients.  I would say that a lot of clients have their own design patterns have a become a sort of a popular term in the industry.  We would expect to see more of that in terms of service design emerging over the next couple of years.  When we look at run-time, this is an area that's pretty mature today even in terms of the commercial service management and middleware solutions that are out there.  

The role of policy there is already significant; we would expect that to increase over the next year or two.  And then ultimately in the future, one of the big frontiers here is federation and how different pieces work together and provide a seamless experience.  So we would expect the run-time environments to provide better support for that kind of thing so that it would be possible for a service and one enterprise to invoke a service in another and make it easier to map all the security and policy requirements across that bridge.

On the platform side, we see that individual organizations are pretty much doing their own ad hoc planning.  We don't expect to see that change, they're really are not a lot of clearly defined industry best practices for how do we do migration planning.  And I think that that makes the future a bit unclear as well because every organization has its own unique set of legacy infrastructure doing its own unique set of things for the business.  And planning a migration path to a more unified service oriented kind of infrastructure really is pretty unique from [INAUDIBLE] organization.

And we've got case studies that show just a vast variation in what organizations are facing and how they chose to tackle it.  So that's an area that I think we're not really clear what we're going to see and we're probably not going to see a lot of really clear best practices emerge in the near term either.

And then finally, just touching on policy, the role of policy is growing.  We see this happen in infrastructure tools, in the middleware but it really isn't unified.  I mean they're standards like WS policy that let you move policy definitions around but it's not likely there's a standard way to define the policies themselves.  Pretty much the definitions are still tools specific.  We're starting to see that emerge as more of a discipline where people are saying, hey, we want to manage all these policies independently, maybe tie them together in some new ways.  

The future is really about, hey, we expect that we will see policies that are defined in a standard way so that you can use them across multiple product lines.  But really there's not a whole lot that's driving that today so the real question is when is that going to happen?  And it wouldn't surprise me if that's not two to five years out to be perfectly honest.  

So as far as recommendations, when thinking about the future of SOA, the real question is where is this going and what should you be doing?  How can you use this information to guide what you doing?  The first priority for SOA is always ensuring the quality of service interfaces.  So when you talk about governance in that context, some kind of lifecycle management process is really key especially for companies that are working with either large development organizations internally or working with one or more outsourcers.  

I strongly recommend that you think seriously about having some kind of lifecycle management process that's consistent across all of those sources of services and hold all the parties to those.  The other thing is that while portfolio management, portfolio planning are still very difficult challenges, and things that are hard to get employees early on, you can certainly put portfolio thinking into your small plans as well as your longer-term plans so that you can also ultimately evolve towards a vision at each step.  

And the touch point I would make there is that each evolutionary path will be unique so your mileage may vary, of course, but you need to consider what the needs of your organization are.  So at this point, I'd like to turn it back to Beth.

Beth Gold-Bernstein:  Okay.  Thank you very much, Larry.  And now, it's time for your questions.  I'd like to remind you, you can submit your questions by pressing the "Ask a Question" button.  Before we go to your first question, please take a moment to answer this question.  What SOA governance disciplines does your company use today?  Please check all that apply and spend a moment and we will get back to you shortly.  

For our first question, Larry, what kinds of software out there does this separation of nonfunctional requirements like performance, security, service, policies versus the business function traditionally done by ESP's?  Are you referring to service appliances like data power?

Larry Fulton:  Actually, no, I'm not.  If you talk about the case of performance and security, those particular examples, those are built into things like ESBs or some of the SOA management tools.  but because the thing I'm talking about are certainly those things as well as things that may not be generic parts of the infrastructure but that may still be business specific.  For example, if you have specific auditing needs or other regulatory requirements that have to be met, you can treat them the same way by building your services in that way using something like an ESB.  

So for example, you might use composite service so that you would separate the policy in one set of services from the actual business logic and that lets you maintain independent control.  So really I'm talking a bit about a design perspective as well as in cases of certain things like security or performance things that you can have [INAUDIBLE] into the tools themselves.  So the idea here is to say you can go beyond just what the tools vendors are providing in a generic sense to get more of those benefits yourself by thinking about them as part of the way you design your service portfolio.

Beth Gold-Bernstein:  Okay.  Can you tell talk a bit about how or if ITEL processes can apply to SOA governance?

Larry Fulton:  I'll start by saying that I'm not exactly an expert in ITIL.  But in general, the ITIL policies focus a little bit more on the run-time side and the operations side of what's happening in IT and certainly there's SOA governance things that might happen that would be in the same realm.  For the most part, we see the design-time governance kinds of policies as not really being touched too heavily by ITIL.  

So the way that they can be applied is certainly the same discipline that ITIL brings to traditional run-time operations can be applied in much the same way, in fact, the same [INAUDIBLE] processes to what's happening in SOA operations.  But the design-time stuff, is stuff that you really haven't seen [INAUDIBLE] that have really taken a lot a hold in terms of the service software development lifecycle.  So again, on this sort of design build side of SOA, it's the same thing you're not seeing.  It'll be predominant there either.

Beth Gold-Bernstein:  Okay.  Can you give us an example or talk a bit about what are the governance absolutes that must be there to be successful for SOA.  Are there some?

Larry Fulton:  Yeah, we generally recommend in terms of what are the minimal sense of things that you need to doing.  Really is a question that we get a lot from people just starting out but I think that it applies across the board as well.  Certainly, you want to have some kind of a process in place that is allowing you to ensure some quality of services.  I mean the  biggest key to SOA is making sure that your services are the right services, that they're well defined, that they're fine in a way that's consistent and [INAUDIBLE] the business.  

As so an absolute minimum is some kind of review process that lets you ensure that those things are happening.  The other two areas that we tell people are important to get right are some kind of lifecycle process which would be the broader perspective on a review process for service design as well as some kind of a process that you're going to have to involve your SOA -- to define and evolve your SOA platform.  A lot of organizations have a whole series of pieces of infrastructure software there.  

The goal is to get to a point where you got sort of a cohesive platform that without some kind of process in place to do that you're going to be continuing the common practice of just adding more infrastructure components.  So those are the top three we would say.  Those top three areas and, of course, this top one of all is ensuring good interface design.

Beth Gold-Bernstein:  Okay.  Good.  Now, that was interesting.  Given the backgrounds of services going to the cloud, how do you see policies being applied in the context of enterprise SOA governance?

Larry Fulton:  That is an interesting question.  When you think about policy in the broad context, the individual policies that govern, for example, this service should be able to process 200 requests an hour or only people that have this security clearance or fit this profile should have access to those kinds of things.  They all trace back to something that's really more of a strategic policy of protecting corporate assets, or providing a general level of service to a certain class of customer and that kind of thing.  

so when we talk about policies in the context of the cloud, it's no different because when we talk about policies without a cloud, we're talking taking the derivative configurations, and policy settings, and rules that come from those corporate objectives and formulating them to where they make sense in the operational environment.  And so the same thing has to happen if the service is in the cloud.  

If I'm going to hand data from my organization to a service in the cloud to act on, I need to have the same level of assurance that that data is protected from a security standpoint that the right kinds of things that are going to happen, that I'm going to be able to meet same service levels that my customers expect.  So I think that the challenge, of course, is that we don't yet have a good way to sort of genericise those policies so that they can be taken along for the ride with the service request, or in advance of a service request, or anything like that, and interpreted and then applied at the lower level correctly.  

I think that that will probably come especially as we see more of this kind of services in the cloud thing.  That is one of the challenges there is that, it's easy when you talk about a simple example but when you talk about things that have all of the intellectual IP concerns, or other kinds of security-related, or performance level, or guarantee of service related challenges that there's going to need to be some work in that area.  Probably what's going to happen first is that organizations that are operating those clouds, if you will, will end up having to take some kind of leadership role to drive adoption up.

Beth Gold-Bernstein:  Okay.  That's an interesting one.  Now, how do you see the role of service consumption going back to service creation?  For example, someone finds a service in the registry, wants to use it but it only solves 90% of their functional needs.  How do you manage that version control and then there are problems between that and bridges; how do you see companies doing that?

Larry Fulton:  Well, I think that some level of that is inevitable, right.  I mean people need what they need and so they're going to be looking for services that fill those needs and naturally some kind of partial solution is going to be evident.  When we think about service portfolio management, we always -- we think about it in two ways and one is that there has got to be a routine process of taking a look at the services we have and making a determination as what needs to change.  

But also, the idea that these ad hoc situations whether they be this  example here where I have a service that almost meets my needs or I have a new business need that has completely unidentified and therefore there is no service that fulfills it.  The model that fits in with the process I described earlier is that part of the service consumption is to say, hey, I'm looking for a service that's almost defined here and then you need to engage some part of the organization to make a decision as how we're going to fulfill that need.  

Are we going to say, well, 90% is all you get and so you're going to have to find a way to work around that?  Do we look to say does the service need to be expended in some way and if so, if it does that brings in all of the things that the person here has asked about to say, well, what about versioning.  It's one thing to say we're going to just strictly add to the amount of data that comes back or add a method that doesn't impact anything else.  It's another to say that adding that 10% functionality in some way impacts what's really meant by the service or impacts people who are already using it.  

So you probably would have some kind of policy in place that would say we version things a certain way when changes are easily able to maintain some kind of reverse compatibility.  But when cases where's there's not reverse compatibility, you're going to have to turn around and do it another way.  So really what we'd say is the short answer is that, that request including the gaps has to engage the process whereby a broader decision is made as to how to handle it.

Beth Gold-Bernstein:  Okay.  I'm sorry but we are out of time for questions.  I wanted to share the results of our poll.  It looks like at least a good percentage of our audience are doing some governance and that's the good news.  I'd like to invite you all now to visit our exhibition hall.  Visit all the booths for an opportunity to win the book, Service Oriented or be Doomed by Ron Smelser.  

All of our sessions today, have been recorded so please refer them to colleagues if you found them helpful.  And those who listened to all three will be entered into a drawing to win a GPS from Magellan.  Hope you all enjoyed the day and visit us in the lounge for more discussions.

1 Comment

Dear Joe,

Thanks for posting the transcript. Could you please point me to a copy of the slides used in this presentation?


In this blog (formerly known as "SOA in Action"), Joe McKendrick examines how BPM and related business and IT approaches can promote business transformation.

Joe McKendrick

Joe McKendrick is an author and independent analyst who tracks the impact of information technology on management and markets. View more


Subscribe in Bloglines
Subscribe in NewsGator Online
Add ebizQ's SOA in Action Blog to Newsburst from CNET News.com
Add to Google

Recently Commented On

Monthly Archives