Todd Biske on SOA Governance - 'It's About People, Policies and Processes'

DZone had a chance to catch up with Todd Biske, author of the recently published SOA Governance Refcard . In this interview, Todd delves into what exactly comprises SOA Governance, the skillsets required to implement it, and some industry best practices for achieving it.  

DZone: Todd, could you tell us a little bit about yourself and what you're up to these days?

Todd: I am a Senior Enterprise Architect with Monsanto, headquartered in St. Louis, Missouri.  I've been a corporate practitioner most of my career, with a brief foray into consulting for about a year.  I've been involved with SOA efforts since 2002, and have been an active blogger and conference speaker since late 2005.  I had my first book, SOA Governance, published by Packt Publishing in 2008.  I have a Master's Degree in Computer Science from the University of Illinois at Urbana-Champaign, and have always been interested in the application of information technology for solving problems, starting with my undergrad years in college where I took courses in psychology and man-machine interaction.  Outside of work, my time is spent with my family and friends, coaching my kids baseball/softball teams, attending St. Louis Cardinals' games, and being active within my church.

DZone: What exactly is service governance and what are its benefits to the companies implementing it?

  Todd: As technologists, it's not surprising that we focus on the new technologies that are always emerging. The technology is normally not the hard part, however.  The hard part is the cultural changes that are required to leverage these new technologies to their fullest potential.  SOA governance is all about the people, policies, and processes that are necessary to fully leverage the potential that adopting SOA can bring to an organization.  Simply building the same old solutions we've always built where the only change is the use of XML and HTTP technologies is only going to offer incremental improvements, at best.  Establishing policies that change the way solutions are defined and delivered, has the potential to create substantial improvements.  That's what SOA governance is all about.  Companies that establish the right policies and processes can have substantial gains.  Companies that don't will at best have incremental gains, and at worst, make the situation even worse than it may be today. 

DZone: What degree of importance do you assign to service governance in companies that are in the process of transitioning from a legacy architecture to SOA?

Todd: I think it is absolutely the most important thing to get right in an SOA effort.  If you think about architecture today, most companies probably have application-oriented architecture.  This is where the monolithic application is the main unit used to describe the information technology solutions.  That's simply too big of a unit to be agile.  Moving to a service-oriented architecture represents a huge shift in the way the information technology solutions are perceived.  Without solid governance, the efforts to get there are ad hoc, and are unlikely to achieve systemic success in a timely manner.  The transition must be carefully planned and guided by policy.

DZone: Is there some type of software that can help companies with the overall service governance issue? If yes, how mature is it? 

Todd: First and foremost, governance is not something you can buy, period.  There are technologies that can make your governance processes more efficient, but that's it.  The most frequent technology associated with SOA governance is the registry/repository, mainly because companies have realized that a requirement for SOA success is making the services that exist in the organization known to all.  In order to do this, some form of repository is needed, whether it's a commercial product or a manually maintained web page on the intranet.  In addition to the registry/repository, policy enforcement is also a part of governance, and can be automated through tools like ESBs, XML appliances, Service Management Platforms, and SOA Testing Platforms.  In all of these spaces, there are solutions available that are at least 5 years old, so they are reasonably mature, however, there are still many niche players and integration across an entire platform of SOA tools that works within your processes can still be a lot of work.

DZone: What skill sets are required for different team members involved in SOA governance? How do you categorize different team members and their required skills? 

Todd: The SOA governance team can be thought of as the SOA government.  They must be the leaders of the effort.  Just as any government has experts in particular domains, the SOA governance effort must as well.  A strong technical lead may be able to define policy for service technologies, but may not be the right person to define policies for service ownership, while a senior manager may be.  The team must be able to paint a picture of what the organization will look like both from a technology perspective, an organizational perspective, and a process perspective (how the organization works together to deliver solutions) in order to be successful.  This will require collaboration from senior managers, analysts, and technical staff.  The biggest skill that I would want on my governance team is the ability to influence.  Governance is viewed negatively in many organizations, because people think of rigid processes with bottlenecks that slow down productivity.  It doesn't have to be that way.  People who can influence and guide the behavior of the organization in the right direction are extremely valuable.

DZone: What are some of the common pitfalls associated with implementing SOA governance?

Todd: The first pitfall, which I already mentioned, is thinking that you can buy governance.  Buying a registry/repository or any other tool and thinking that the behavior of the organization will change is a big mistake.  Instead, think of how you want the organization to behave first, and then how tools may make that easier to achieve.  Second, make the policies explicit.  Assigning people to be part of a review board is a reason why governance is such a negative term these days.  These people never make the policies known that they expect projects to adhere to, so when projects come to them, they're simply making a best guess, and are typically wrong.  What's worse is when each member of the review board has their own thoughts and opinions, leading to inconsistency in the governance itself.  By defining policies and making them explicit, teams now have clear expectations and can even self-police.  The last pitfall is forgetting to establish the SOA vision.  In general, people want to do the right thing, but they are also resistant to change.  If you don't establish the vision and help people to understand why they need to change, they won't get there.

DZone: What are some best practices which companies should try to follow and apply?

Todd: I'm a big fan of some form of cross-functional team that guides the SOA adoption effort, such as an SOA Competency Center.  The reason for this is that an SOA adoption effort is larger than any one project.  Unless there's someone accountable for the effort as it spans across projects, it's unlikely to happen.  The reason it needs to be a team is that SOA adoption is more than just technology.  It involves changes in the way projects are defined, implemented, and operated, and people with expertise in all of those domains are required for success.  A second best practice is to understand your existing application portfolio as best as possible.  This can be done through application rationalization efforts, business capability analysis, business process analysis, and other techniques.  This is the thing that will tell you where you can get the most benefit from services, rather than simply building arbitrary services and hoping the potential benefit is realized at some point in the future.  The final best practice is to focus strongly on communication.  Having a formal communication plan to get out the SOA message, and keep it in the forefront of people's minds is critical.  I've worked on efforts with some very smart technical people, only to see them struggle because the message didn't get out to the masses.  Having a person who specializes in communications and can help define a formal plan for communication and education can be a big difference maker.