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.
SDA: The Gartner Group estimates that a lack of working governance mechanisms in mid- to large-size SOA projects is the most common reason for project failure. Can you explain, in further detail, what the consequences of an ungoverned SOA are?
DT: It is the difference between doing SOA on a small scale—with a couple of developers for a small organisation where it is more easily managed because you sit next to each other and know what’s going on—as opposed to the large size organisations where there are large numbers of people in different parts of the globe with many more services being created for many more dependencies a interactions—that is where the failure really comes in. As the use of SOA goes up and there is adoption across the enterprise, governance becomes more critical, because you need transparency.
To talk about the consequences of ungoverned SOA, at the basic level, there will be questions about the quality of services written, and who is writing them. You will have to make sure what is being put into the registry, and is being made available to users—is quality software that conforms to the standards and requirements of the organisation. Building on that, without the governance there will be real questions about the quality, and questions like—does this work for my particular purpose? That lack of trust means services don’t get re-used, and that, in turn, means much of the value of SOA goes out of the window. Each developer will say that he will build the same thing himself—because he can’t trust people. So we are back to the traditional methods of IT architecture where everything gets built on demand rather than getting re-used. There will be questions about service levels. With SOA governance and being able to put service levels in front of services ensures monitoring and the management. The help desk also knows what is going on. Without the governance in place there will be questions about whether we are meeting service levels. Thus having that information is key. So without these answers we’ll just go back to the old thing of IT implementation, no reuse of services and tightly coupled architecture.
Thus without reuse there are no cost savings and no faster time to market. In fact, development is more costly because you’re spending the extra effort to turn code into services. That’s part of where the failure comes in.
SDA: What are the top three challenges in implementing SOA Governance?
DT: Firstly I would say you should have that organisational structure in place. That will create challenges for organisations because it won’t be the same as how they had thought of services in the past. Putting that in place is key. Second on the list, we need to be promoting re-use, without which, a lot of the value of SOA flies out the door. So making the information available, making it transparent, making it well understood—what the service is, what is the applicability, what are all the technical aspects of invoking that service—are all critical paths to SOA governance. You should also track your reuse to measure your progress. Another challenge is, in order to make services re-usable and to deliver this promise of SOA, you need to divorce the business logic aspect of the services from all the rest of it—the configuration of the services, information about how the service gets deployed, where it gets deployed, the security around the service, the policies that govern who can use the service and how it gets used and all of these things that don’t deliver the business logic of publishing the information on the web, but are critical to the use of the service. If you don’t divorce the two, the aspects stay tightly coupled, then the ability to re-use the service lessens By divorcing the two, two parties can have different policies to govern the use of the services, which will promote re-use. Getting the developers to be aware of that and obviously having the technologies in place to support that is critical, we call it Service Virtualisation, is also critical.
Daniel Ternes is TIBCO’s Chief Technology Officer in the Asia/Pacific region. He is responsible for helping customers shape and fulfill their enterprise SOA/BPM requirements as well as working to maintain TIBCO’s position as a thought leader for SOA/BPM. Prior to this current role, Daniel was based at TIBCO’s Silicon Valley head office as Director of Product Strategy. He was responsible for the product roadmaps and strategies of TIBCO’s Business Process Management (BPM) and Business Optimization product suites. Prior to TIBCO, Ternes was a Senior Vice President of Technology for Staffware where he was directly involved in product developments and innovations. Ternes is a graduate from Sydney University, Australia.
|
