SOA Visibility: Keeping the Wheels On

The first installment in the SOA Governance@Work series

SOA governance is a big deal, truly important stuff. It covers lots of territory and involves lots of people taking lots of aspirin. Get it right, and your SOA initiative has a far greater chance of success. Get it wrong, and it won't be very long before Moose and Knuckles from building security help you move your stuff to your new office on the sidewalk near the bus stop.

But SOA governance isn't a monolithic issue. Like SOA itself, SOA governance is all about the dynamic interaction of many interconnected pieces -- people, processes, technologies, and more. So rather than trying to digest SOA governance as a single ginormous  concept, it's a lot easier on the gray matter to break it down into easily digestible chunks. That's what the SOA Governance @ Work series is all about.

The first chunk on the menu is the visibility and traceability of SOA software assets.

Start Your Engines

SOA is to a service what a racetrack is to a sports car. On a race track, various policies, standards, and controls are put in place to insure, for instance, that you don't have farm tractors racing against Formula One cars, and that all the cars speeding around the track are moving in the same direction. SOA governance performs a similar function, ensuring that there are no collisions between services, and that the services don't do anything that might anger your customers, your boss, lawyers, or representatives of government agencies.

SOA governance, at its most basic, requires holistic awareness of contents of the SOA software asset portfolio  -- the catalog of parts from which the SOA will be built.  Those parts can be anything: business processes, components, frameworks, services -- literally anything relevant to the design, development, and use of services and the applications that will consume them.  Without that awareness, without visibility into and traceability of when where, how, and by whom those parts are created and used, there is no SOA governance, and your race track will inevitably become very messy and expensive a parking lot.

Why is this visibility important? Consider this short video...

It's anybody's guess as to how many parts there are in the little red RX-7 in the video -- thousands, maybe tens of thousands. In that video, nearly every one of those thousands of parts appears to have worked perfectly -- except for twenty lug nuts. Why did the wheels come off? It boils down to a lack of lack a of visibility and traceability into the use of a handful of simple, little parts. That's the automotive equivalent of ineffective SOA governance.

What You See...

The SOA lifecycle is a food chain in which small parts are consumed in the development of larger parts. Effective governance over that food chain begins with the ability to see and understand what parts are available, and how those parts relate to each other, to the projects that have produced or consumed them, to the projects that are in the process of producing/consuming them, and to the projects that plan to produce/consume them.

Without that critical visibility and traceability into the contents of the SOA asset portfolio, your SOA initiative will eventually meet the same fate as the red RX-7: Vroom! Screech! Crash! If you're lucky, no one will be around to immortalize your misfortune on YouTube.

But how do you gain the necessary visibility?  What does it look like? And what do you do with it once you have it?

The image below offers an example of a dynamic relationship map for a service,  as displayed in BEA AquaLogic Registry Repository Oracle Enterprise Repository.

View larger image

The center node in the image is a software asset named Inventory Availability Service. The lines projecting outward from the center node indicate the various relationships that connect that service to other entities. These include the project that produced it (MOM Inventory Consolidation), projects that have consumed it, policies that have been applied to it (Production SLA Policy Gold Beta and Corporate Quality Standards Policy), and a process that is implemented by the service (Order Verification Process).

Each node in the display represents an asset in the repository, each with its own metadata, including relationships, dependencies, usage history, and more.

This display of SOA asset relationships and dependencies is dynamic. Clicking on any node in the display shifts the focus to that node to illustrate its various relevant relationships and dependencies. BEA AquaLogic Registry Repository Oracle Enterprise Repository also provides other views of these relationships and dependencies, as well as information on who has used the assets, user comments and reviews on assets, and other important information.

...Is What You Get

Armed with all the information provided by this visibility and traceability, architects can make informed decisions about the SOA assets to be used in projects. They can make accurate impact analyses. They can effectively manage change. They can even prescribe assets for reuse in projects, optimizing reuse by relieving development teams of the burden of hunting for suitable assets. (We'll take a look at that prescription process as the SOA Governance @ Work series progresses.)

This visibility and traceability, while only one aspect of SOA life cycle governance, is the first line of defense against problems that can cause the wheels to come off when services are deployed onto your SOA racetrack.

In future posts we'll dig into other aspects of visibility across the SOA life cycle, including SOA management in the runtime environment.


Post a Comment:
  • HTML Syntax: NOT allowed



« July 2016