Business Transformation in Action

Many companies have already started on their SOA deployments, and are doing the right things, deploying an SOA strategy in conjunction with their SOA architectures.

If you are moving towards an SOA initiative, if you are embarking on an SOA project, that project will fail without governance.

It’s not about how many services you have, how many processes you have, how many policies you have, it’s all about which ones matter Without SOA governance, you will fail to meet the expectations of your consumers. It’s all about which ones matter. Without SOA governance, that, at the end of the day will cost you business.

All the pieces that are necessary. The registry/repository… and there’s plenty of information. The maturity of SOA governance… SOA as were seeing it is evolving from a technical architecture to a governing framework. It is not so much about the applications that you build, or the services you compose, or the processes that you orchestrate and coordinate.

It’s really about understanding the lifecycle about the artifacts that make up your service oriented architecture.

Runtime and design time it doesn’t mean anything when it comes to SOA. its not runtime or design time, its all the time.

The lifecycles, creation cycles, usage cycles, deployment cycles, and there are governance cycles. I think that its important to makes sure that you know that all of these cycles overlap, and these cycles happen very very fast. In the past, the lifecycle of an application that you may have been using in your data center may span years in many cases the lifecycle of a service of a popular service, or a critical service, can span anywhere from days, not even days, maybe hours, even minutes, if the service is dynamically coordinated and composed.

When we look at the creation cycles, and we look at the usage cycle, it’s becomes more important for that developer, for that assembler, for that person orchestrating, to really have insight into how that artifact is being used.

In the past we’ve had developers develop applications, and then hand them over to operations and say, well you go run that, I’m not worried about the service levels. I’m not worried about who’s using it at all.

Now we enter the phase where the developer and the assembler, they have to be concerned with who’s using the service. Because the use of the service is ultimately going to start to talk to issues of satisfaction. The use of the service is really going call into end issues around service levels, and are you meeting the contract requirements, and what will eventually happen as the requirements start to flesh out of that service that’s currently being used, the person that owns the service will start to incorporate those requirements, and in many cases, it will happen in a very short amount of time.

At the same time that development is happening and usage is happening, you also have things around governance that are happening, and governance is happening both during this creation cycle. During this development cycle, and it’s also happening during this usage cycle, and governance is really bringing the world together.

So today developers can use technologies to help them get visibility into who’s using the service, how often the service is used, which methods in the service are being used. You can then make decisions around granularity, ownership, future support, version control, etc…

So its important to understand that when you continue to make the artificial distinction between design time and runtime. When we're talking about tremendous amount of overlapping lifecycles that are running in some kind of connected and coordinated way, you really want to be talking about all the time, and you want to be talking about the disciplines that happen and what the effect is on each other.

And by the way, when you buy technology, you really want to work with your vendors so that you understand if your vendor is selling you design time governance technologies, how does that technology work during runtime? And are they selling you runtime enforcement technology? Well, what about enforcement of a lifecycle during the development cycle? So You really want to make sure that you’re getting the right technology for the right job…

Before you go off and buy technology, understand that the best SOA governance strategies. Start with the organization. It is very much top down. It is IT governance, maybe its some type of architectural review board. And then filtering down into an SOA center of excellence. And then the governance policies and processes will start high up, and will be very focused on the business.

As they start to come down into the realm of service oriented architecture, your SOA competency center, .or your SOA center of excellence, it will be absolutely crucial to ensuring that the governance processes and policies are in place.

So making decisions like: what services do we start with? What services can we reuse? What services are candidates for shared services? Which ones should we work on first? You’re going to make decisions on which ones can give use the highest payback? In some cases, Which ones can give use the highest client satisfaction?

You always need to understand is this really a new or reusable service? Have I spent millions of dollars already developing this artifact in order to use it someplace else? Can I reuse tat artifact?

You’re going to want to know about, who’s going to pay for it? And after I build it, Who’s going to maintain it? Is it the developers? Is it the business unit? Is it the operations people? And finally, who’s going to own the service?

These are the decisions that the SOA center of excellence, or the competency center… or the steering committee, whatever you want to call them… These groups of individuals will be tasked with making these decisions.. and once these decisions are made, there are technologies that can enforce that.

How do you staff a center of excellence? How do you staff an integration competency or SOA competency center? Well, there are some folks who should belong on that team.

Understand that different companies, different organizations, have different titles. Look at the description of the person of the role, and fill in your own titles on the operations side, think about a systems administrator, a DBA… a technician that has expertise in the operation of integration tools.

From the administration side… you want to make sure that you have a manager, a project manager, someone that can read the initiative.…

What’s missing here is the role of evangelist. ….SOA is still something that is relatively new to IT. not new in concept to the science, but to IT departments, SOA is something that is reasonably… new, and it takes time for your entire IT department to really rally behind service centricity and service oriented architecture.

So having an evangelist that can stand up and represent the center of excellence to give it credibility is absolutely important… you need asset managers, librarians, for the services that own the catalog, these folks are incredibly important as well. from an engineering perspective. You need to have a business analyst, a data architect, a software engineer and a domain expert.

One of the most important thing that you musty have is …someone responsible with the testing…

The design cycles… and the run cycles and the governance cycles are all interlinked… well it’s the same thing with quality and testing as well. So its not just about testing during your development… its about testing during your runtime cycles… or your runtime environment. Its also about validation and those types of concepts.

So then with the people on the team… are the same people… ….you may have a developer that’s a great dba… or you may have a security expert…. That plays the role of system administrator as well. We recognize that. and we understand that you’re not going to go and hire roles… …you want to have the right people to make the right decisions…

These are the members of the team… that is going to guarantee that your SOA governance strategy is enacted all the way at the ..technical… level…

[Gartner framework] the technical level…. …we’ve introduced concept of integrated SOA governance technology set…. …it isn’t a suite of products.. …products work together… … you cant really buy governance… governance is gong to come from your organization…. But there is technology… so the set of integrated governance technology… vendors that offer them have a set of cloud based services…

At the center of any good SOA governance technology is going to be a registry repository… ..that registry repository is going to be responsible for… everything from catalog and how do I find my artifacts. To where are they stored? Where do they live? And how do I manage the lifecycles of those artifacts?

In one instance you need to have the capability of enforcing policy… I don’t just mean policy around security…. Who has access? How do you do authentication? I also mean policy around performance… around quality assurance… ..policies around sla compliance and contract management…

You want to have some tool for validation… …just because your artifacts …can be tested against a set of well-defined filters… because SOA is all about loose coupling… you never know who the consumers are going to be… so we need to have a way to validate that the consumers are giving the providers the information that the providers need to do the job.

So policy management, a registry repository, and validation are at the center of the best SOA governance technologies… around surrounding that… is the capability for provisioning new users and new services and new providers, and ..monitoring use…

Even though we are seeing… a fairly decent uptick of companies that are investing in governance technologies, and that have invested in governance strategies and governance… even though were seeing a lot of that, …many companies still don’t know who is using their services… and how often they’re testing them.

So having monitoring capabilities, which is sometimes included… in the SOA policy management capability, having the monitoring capability is a must.

Finally, being able to work with existing functionality is incredibly important. Why? Because … …like any other IT tool… none of these technologies live in a vacuum… they don’t stand alone. you will be using governance technologies in conjunction with an integration broker… or some piece of message-oriented middleware. Or an application server. Or a b to b gateway… or as many of you are doing, and enterprise service bus… so you need to be able to work in conjunction with the infrastructure.

So indeed looking at SOA governance technologies is not just about owning the functionality end to end, its about being able to work… with other parts of the infrastructure.

Its about being able to federate with directory services for role-based access control. Business process management suites, so you can get inside into process governance. A cmdb, an esb, an integrated development environment… an integrated development environment and service environment… for orchestration, assembly and development.

Its important to realize it’s a … two-way street. Many times I get asked, what should the registry/repository of record? Should it be this registry/repository for SOA? or should it be my cmdb? Depending upon the role you have in the organization, …. Governance is going to look different for you…. Looking form the perspective of a system administration, Looking at your cmdb… SOA governance and configurations and change management is going to look different… than if you look at it say from the perspective pf a developer, just looking for published.

So we need to have federation, but that federation needs to be contextual… that federation needs to be optimized…. For the viewer. It needs to have context.

Sadly, that’s one thing that seems to be missing from SOA governance today… we believe that within the next 24 months, you’re going to hear a lot about this issue of federation… a lot about the issues of governance interoperability so that things can be federated.

Today sadly, the most we can do, absent of standards, is a single replicate or synchronization… n some cases, that’s going to be good enough. Iin other cases, such as …in b to b instances, instances where I’m reaching outside my firewall… and I have to do business with a business partner, and I cant always, or I cant always sync, it will become hard.

We need to move towards a delegated system… where we can have one registry interacting with another registry on behalf of another and another and another…

This is where standards are going to get us… Sadly again, they don’t really exist today. But, there are some initiatives from vendors… around governance interoperability and federation, and we are hopeful that these will help you not only maintain… good governance… throughout your infrastructure, but support a federated system of registry/repositories, metadata repositories… CMDBs…and other pieces of infrastructure… to get the information to the right party in the right context.

For access to the archived audio presentation, click here.

_______________________________________________________________