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

---Transcript---

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.

Posted by ebizQ in | Permalink | Comments (0) | TrackBacks (0)

Editor's Note: Interested in how BPM was able to transform a staid industry like financial services, then make sure you check out the webinar, BPM for Financial Services.

What follows is my podcast with John Jarrett, Director of BPM for AGF Trust. John Jarrett has more than 20 years of experience in the financial services industry across retail banking and head office environments, and for the past 18 months, John has led AGF’s Trust project to launch BPM into the organization. In this podcast we discuss BPM in the financial services sector and also introduce Appian’s upcoming Webinar, BPM for Financial Services.

Listen to or download the 6:44 minute podcast below:

Download file

---Transcript---

So first of all, can you tell me why BPM is a good fit for financial services?

Well, financial services is a bit of staid old industry but at the same time is under a lot of pressure competitive wise and regulatory wise. BPM allows you to be able to deal with both simultaneously. You’re able through BPM to get a better level of documentation and control over your processes.

This allows you to be able to repeat your processes with some confidence and as well, you are able to show auditors what your processes are with a greater degree confidence. So these translate into being able to better show what your risks and issues are regarding things such as Sarbanes Oxley, etc. And as well, allows you to be able to more flexibly deal with training, documentation, procedures, and manuals.

So I hear you mention business processes. Now, what exactly made you change your approach to business processes?

Well, we did have a bit of a unique issue and opportunity in our case. There were two real drivers that were simultaneously driving us to this need. One, our parent company had divested their back office to an outsourced relationship and we were leveraging and imaging a workflow tool in that platform and as a result of the divestiture, we needed to revisit getting that tool replaced or updated.

That said, at the same time, we also found that our old system while it was beneficial to us when we started, we’d kind of outgrown it and the pains around having had it customized primarily for mutual fund processing were becoming quite apparent that that didn’t necessarily really work very well for loan processing. So those two items kind of came together to drive us to look for a BPM solution.

So in looking for your BPM solution, what were your key objectives in choosing one?

Well, the key objectives we had were flexibility. We’re in a fairly high growth mode and a fairly dynamic environment here and so we were looking for a system that would allow us to have some flexibility. That though had to come with a strong degree of business involvement.

We didn’t want to have to have a high degree of dependence on either the vendor for an ongoing professional services relationship nor on our on internal IT shop to constantly have to fight in the organization for that shared resource so we wanted something that would have a strong business involvement as well.

So what BPM initiatives have you then put in place?

What we were first looking to put in place was a 'like for like' as we refer to it transition from our old platform to our new. So the initial go around was to put on our loan processing business. We had a small home equity line of credit business that we were doing on the old system as well as a GIC booking process. So the initial translation from the old system to the new system were just those lines of businesses.

So what has your return on the investment been?

Oh, good question. However, I don’t have very good answers for you, unfortunately, that’s just a bit of a squishy area for us as it is. Partly, because we’ve started off as such a small trust company and have been in rapid growth mode. We don’t really have good foundation of data. Its shifting sands really type of thing and it’s difficult for us to measure or be able to speak to it in those sort of specific points of reference.

And also, it’s still quite early. We’ve just really gone live with the Appian System in April. So for those two reason, that’s a little bit difficult. But what I can tell you is that the user community have spoken back with high praise on how much easier it appears to be doing the same things that they were more or less doing before.

And although we did talk earlier about doing this on liked for liked basis, we did take the opportunity where there were some low hanging fruit to be able to make some minor process improvements. And the extend to which those have sped up some the cycle times, or reduced some of the touches, and some of the back and forth things that used to occur in our old system, we can already see that we’re going to be able to get some headcount relief and some throughput speed increases from the system.

That sounds great. Now, what are your future plans for BPM?

Well, we plan to bring our arrears management area onto the platform in the fall. We’re looking at also brining our mortgage area into the platform in ’09, and then throughout the coming months and next year, reengineering a lot of the processes in the loan and GIC business.

Again, sometimes the processes were what they were because they needed to be that way for the business. But in other cases, the processes were what they were because of issues or limitations within the system and what we want to try to do is adjust both how the business the works as well as get around what some of those old obstacles were in the past and do some re-engineering.

We also want to use it as a communication platform for the organization when we’re doing announcements, updates, staff homepage, that type of thing so essentially, an enterprise wide sort of an application.

That sounds great. Also, don't forget the upcoming Webinar from Appian, BPM for Financial Services, where John will be a speaker. And if you do have any questions, please send an email of your question to curriulum@ebizq.net and we'll make sure to address it during the webinar.

Posted by ebizQ in | Permalink | Comments (0) | TrackBacks (0)

For security purists, SOA is like inviting Little Yellow Jacket into a china shop (if you haven't figured, Little Yellow Jacket is that famous bucking bull that launched many a bull rider hat over spurs). I use that comparison because the IT profession and bull riding are such similar fields.

Now you probably think I wrote that in jest, but if you've talked to a security professional recently, you'd know that trying to secure the applications makes bull riding seem, well, OK, it still makes bull riding seem pretty nutso. But security pros crave stability and solidity, and often SOA is just about the opposite of that.

Which is all the reason to check out tomorrow's ebizQ online webinar, Evolving Security Architectures and SOA for Better Business Collaboration. I reckon it'll be a most interesting e-hootenany, and you can secure yourself a spot right here.

I also recently did a podcast on that very subject, which I reckon you might wanna give a listen to, called, Does Good SOA Have to Mean Bad Security?.

So I hope to see you all rustling around the webinar tomorrow, and if our online avatars happen upon each other, I'll make sure to give you a how-do-you-do.

Posted by ebizQ in | Permalink | Comments (0) | TrackBacks (0)