SDA India is an online resource for Software, Development,IT, Architecture, Open Source, Mobile, Security, Databases, Delphi, C, OS, Asp, .Net, Php, Xml, Java

Many organisations are jumping onto the SOA bandwagon, which allows them to extend and reuse existing IT systems and create new solutions and services based on SOA principles. The flipside is that the services can grow chaotically within a company— a development that SOA aims to prevent. This is where SOA governance comes into play. Governance means monitoring and managing the life cycle of services. SDA Asia spoke to Dan Ternes, TIBCO’s Chief Technology Officer in the Asia/Pacific region, to better understand the importance of SOA governance and the security issues involved. Ternes talked about TIBCO’s approach to SOA governance; how large enterprises are trying to deploy SOA in the real world, and more.

SDA: SOA governance is a hot topic today. But it is also a very vague territory. To begin with, can you explain what SOA governance actually entails?

Dan Ternes (DT): It is a very wide topic. When we look at services, about 60 to 80 per cent of the code is business logic, or business information. The rest, which constitutes 20 to 40 per cent, deals with things like security, policy management and so on. These are many of the topics that are covered under governance. In development, governance deals with the dependencies between the services published, the procedures to be put in place to govern the use and reuse of those services, the workforce required to approve the publishing, promotion and change of the services, so on and so forth. Governance in operations focuses on making services behave consistently regarding security, auditing or logging, even service levels.

SOA can be broken down into four components—creation of services, orchestration of services, deployment of services, and management of services. Governance has an organisational as well as a technological aspect across all these phases. From the perspective of technologies we have a set of three things. Firstly, a repository that allows you to publish, find and reuse services. Secondly, a registry that allows you to track services. The repository stores the actual services while the registry stores the whole series of meta data, particularly the dependencies between all services. This is helpful in measuring the impact of the changes that are made later on, as and when the case may be. Thirdly, governance has a policy management side, which addresses things like security, encryption, logging at service levels so on.

SDA: What are the main components of SOA governance? Can you explain a bit more about policy management and contract management, life cycle and metadata management?

DT: As I said earlier the registry, the repository and policy management are the main components—lifecycle management, metadata management do not really have a separate identity. Lifecycle management has to be part of the repository. It has to govern who can publish services and who can approve the services before they are published, what kind of versioning is being put in place with the services, do they get re-used, who re-uses them and so on. These are all things that I would see as part of lifecycle management. If you want a successful registry or a successful repository, then all those things need to be part and parcel of that capability.

SDA: What is the need for SOA Governance?

DT: At TIBCO, we’ve been working with SOA since its advent. But it has changed over the years and the industry has also learnt the right way and the wrong way to approach the whole concept of SOA. One of the things that the industry is starting to wake up to is that SOA governance is critical. For example, if there are just two developers in an IT shop, building an application, you don’t really have to be concerned about the outside world. Since you are building something that is self-contained, as long as you can make it work and put it to production nothing else matters. But once you open that up, and you are building services instead of applications, many issues surface. The problem that arises now is that you have around 2000 other developers who are building similar services, so there is going to be reuse. That opens up a can of worms because initially the services were built for internal applications, so you did not have to bother about encryption, but the person who wants to make use of those services now maybe putting this information out on the wire. So here encryption becomes key. There are security concerns— the business logic behind the service might be consistent, but how people make use of that is different, and the policies about security to govern these are different.

A whole promise and premise of SOA is to re-use services and these things become important. Without governance and aspects like policy management in place, there will be no trust. Governance is critical in order to ensure trust in the quality, applicability of the services. Without governance you have the ability to create all the services you like in the world but you lose the trust that is going to be necessary in order to encourage the re-use of services.

SDA: The main aim of SOA is to align IT and business together. How does SOA help achieve this objective?

DT: Well, in a couple of ways. One of the areas where IT and business need to be aligned is the area of business agility. That is really where the business side comes into play with SOA. A part of that agility is reuse. A critical argument to business agility is that the building blocks to many of the application have already being built, so you don’t have to reinvent the wheel, but just re-use what’s already there. But things like policy and security need change from instance to instance, so you need a way to make the same service behave in a slightly different way depending on the scenario—not the business logic, but the configuration around it and without governance that is not possible.

The other side is that there will be a general lack of trust regarding how things work. If people don’t know what is being built and more importantly how it is being built they cannot trust that. On the organisational side of governance, it is really about getting the buy-in from the people and selling them the concept saying this stuff works—this draws in their trust. That is the other area of governance—being able to talk to the business side and present these policies and procedures and organisational structure that gives them the confidence that making use of these services to build applications rather than the traditional IT approaches is workable and effective. Another way is by using business processes and technologies like BPM to help define the services you need. It naturally aligns the business processes and needs with SOA. Governance technologies like policy management also provide more flexibility and make it easier to do things like enforce compliance, or deliver service levels required by the business.

SDA: How does SOA governance also help check security breaches and aid compliance?

DT: That is actually policy management; there are again two sides to it. The development side—who is developing the service and how to take those services and put them into production and ensure that someone is not putting in rogue service repositories that other people start to use. So the first side of security is the right life cycle management—to ensure only accredited people can publish services, they have to be approved, and they follow a certain guideline and structure before the services are published. . The other half of the problem is that the same service can provide the same information to different parts of the organisation or outside the organisation, but the way in which it provides that information has to be different. Perhaps one has to be encrypted and the other one doesn’t, one has to be locked and the other one doesn’t. Putting the governance and policy management in place, allows you to make changes to the behaviour of the service without changing the business logic behind the service. That also allows you to support security by ensuring the right security and compliance is applied to the right invocation of the service.

SDA: What is the role of trust in SOA governance? How can SOA governance prevent rogue services from springing up everywhere, passing themselves off as legitimate nodes and wreaking havoc on the delicate trust that underlies production SOA?

DT: Two ways, one is the organisation has to put the policies in place—like procedures and the whole organisational structure around the SOA. We need to think about the vision, strategy and the priorities behind SOA development. We need to look at the portfolio of business services; we have to think about the funding, the scheduling of staff, the actual projects themselves, the infrastructure and who’s going to be the librarian of the services. There are a lot of these aspects to SOA governance, and different parts of the organisation will deal with different aspects So this is the organisational side of SOA—the policies that determine who can and can’t create services, and promote them and so on need to be in place first.

The second step is to have the technology components in place. This is part of the registry, part of the repository and the policy management. These technical pieces enforce those policies—the right workflow process, that governs the approval and promotion of a service. Both these sides combined will provide a preventive measure for rogue services popping up all over the place.