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.

ebizQ's Business Agility Watch


How Key is Governance to SOA? Larry Fulton Explains

Vote 0 Votes

Editor's Note: Interested in optimizing your SOA, then you cannot miss ebizQ's upcoming virtual conference on SOA Governance, which you can sign up for right here.

What follows is my podcast with Larry Fulton, senior analyst at Forrester Research and part of the group that supports enterprise architecture professionals. In this podcast we discuss all the buzz around SOA governance and offer a quick introduction to ebizQ's upcoming Virtual Webinar on SOA Governance, where Larry will be one of the keynotes.

Listen to or download the 8:14 minute podcast below:

Download file


Is governance an important consideration for a company implementing SOA?

Well, of course, it's very important. One of the things that's very interesting about SOA as distinct from some of the things that have happened in previous years in terms of trying to make improvements in the way we do IT, really is the governance discussion.

Back when people talked about distributed objects, and components and things, the one thing that was missing was a really well reasoned discussion across the industry of well, how do we manage these things? And how do we ensure that we're not just building bits and pieces but these pieces are doing what they need to do and that they are serving the business?

So the air play that SOA governance has been getting, I think, has been really a major facilitator in companies being successful with SOA because it isn't just about a technology, it isn't just about an architectural approach, its also about being able to put some processes in place so that people can get consistent results over time.

Now, I've heard a lot about run-time governance, design time governance and various other variations. What do these variations mean exactly?

Well, some of these have actually come from changes as the market has evolved. I think that the term "governance" as it applies here to SOA originally came from the fashionable use, if you will, of the term "IT governance" and really controlling the way that decisions are made in an organization in terms of what application projects are we going to invest in and those kinds of things.

And then, naturally, when SOA rose to some prominence then the same concept of lets apply those same governance principals became important. But it's also been taken to mean really any place that you're exerting control. So when you talk about runtime governance, that's really a very different use of that term, which really is to say, we're going to have runtime environment. Its going to have certain kinds of policies and other things that drive what it does to control the operating environment, and all of those come together and have been called the market largely, runtime governance.

So it's a little bit confusing but if you take the general model that says that governance is about applying the appropriate controls to get consistent results and you sort of bend that definition to include what would happen at runtime, then you cover the whole gamut.

Do companies pursuing SOA governance also need to implement a commercial service life cycle management product?

Well, that's an interesting question. I mean the short answer is no. But when we just sort of marry these two ideas, service life cycle management is the set of procedures and processes that you use to keep track of what services you're building, how they're working, are they designed in a consistent fashion, what are the dependencies, how do they relate to various business processes? All of those kinds of things.

And collectively, that is sometimes referred to as design time governance under the SOA governance umbrella. The fact is that those processes can be implemented without an automated solution but if you start to think about the scale of the number of services that you would have in any kind of reasonably sized enterprise over time, which could easily reach into the hundreds of services, and large number of dependences.

And naturally, you'll want your services to be able to be used in as many places as possible so that implies potentially a large number of dependency relationships that need to be tracked whenever you're going to make a change, to make sure that people are aware of what the change is, and that you can do good impact assessment.

To be perfectly honest, once you start looking at the scale of the number of services that have to be tracked and managed, it's hard to picture doing that effectively with an automated solution. So when I get that question from clients, I almost often say, what you really need to do is define the process well. And then at some point, whether you get to have too many services, or too many consumers of those services, or even just the number of changes to those services starts to get out of control, you may break a manual process and then you'll probably do want to take a look at some kind of automated product.

What are some of the pitfalls companies should avoid when going about SOA governance?

Well, there's a lot of places that you can look at this. I would say that relevant to the last question, you can end up getting a lot of products in and looking at SOA in general as a technology kind of a challenge, and then you find yourself maybe with governance based solutions you don't really understand, or that you're not really at the point in your organization of being ready to use them.

One of the things that we have found is that the majority of companies that have successfully done this SOA business have really started with an incremental process. And that's not to say that that's the only way people are successful, but by and large that seems to be what happens.

And one of the lesson learned when you talk to these companies is that they feel that incremental approach has been very valuable to them because its limited their risk exposure, its given them a chance to learn and maybe do some retooling as they get smarter about all of this. So they're taking small steps and growing as they go.

So when you look at SOA governance, I'd say that the same principle applies. You can really go too far too fast and end up with processes that are very overweight considering what you're really doing with them. So I would say that an incremental approach is probably a good way to go. So the big pitfall to avoid is building out a lot more governance than you need given where you are in your SOA journey.

Right. Then what are some of the best practices for SOA governance?

Well, I think that you can always look at that as the opposite of the pitfalls but I would say that the best practices have to do with starting in places that make a lot of sense. There's a lot of different disciplines in SOA governance that can go a long way into a lot of detail things, for example, lets make sure that we've got well defined processing models for how we're building individual services.

We can build templates and design patterns and things like that. But I would say that as a best practice, what you really want to do is focus on some of these life cycle management things and also figuring out where you're going with any of the core technologies that are going to be under your runtime platform.

So first best practice is to say focus on those things that are most relevant to a starting out position and then evolve your way into some of the other things. And then the second best practice that I think is very important is that you really do need when you put any kind of process together that's going to be business process within IT, you want to make sure that process is well understood.

You want to make sure that you got a lot of buy-in. You want to make sure that it's streamlined so that people don't work around that. And that probably means that you want to think about putting those processes in place manually and then evolving to other kinds of perhaps automated solutions or, in fact, even evolving processes to be more complexed.

We find a lot of more mature organizations will have different kinds of approval processes for different kinds of services, whether they're services that are divisional level, or an enterprise level, or things like that. And pretty uniformly, you find that all those variations have evolved in from the simpler beginnings.

So I think that the key point is too really to try and start simply, focus on getting things right the first time, and that would be our probably best advice on the best practices.

Thank you very much for joining me today, Larry. And if any of you listeners have any questions, make sure you log on to ebizQ and you can ask them so Larry can address them during the SOA Governance Virtual Conference.

ebizQ’s expert blog team covers a broad range of BPM, business integration, business analytics/monitoring, collaboration, content and related issues.

Peter Schooff

Peter Schooff is Contributing Editor at ebizQ, and manager of the ebizQ Forum. Contact him at pschooff@techtarget.com

Recently Commented On

Monthly Archives