Time may be up for design-time governance

September 15, 2008 —  (Page 1 of 2)

Most SOA technologies have some value within the SOA stack; but as we learn more about SOA implementations and what’s really needed for success, many of the technologies out there don’t seem to bring much to the table. This is a natural technology normalization process that occurs within any technology trend; SOA is no exception.

Governance is a clear requirement for SOA; you need someplace to track, secure, define and maintain services. Two very different SOA governance approaches have emerged: design time and runtime.

Runtime SOA governance, as the name implies, is more about operational requirements, including the ability to live up to service-level agreements (SLA); execute policies around services; and make sure the services live and work well together in support of the SOA, and thus in support of the business when executing. There is clear and well-defined value, and therefore most runtime SOA governance products sell well. I view this technology as critical to the success of the SOA.

Design-time SOA governance, as the name implies, typically provides an integrated registry/repository that attempts to manage a service from its design to its deployment, but typically not during runtime execution of the services (although some try). Key components of design-time SOA governance, generally speaking, include:

a registry and/or repository to track service design, management, policy and security, and to test artifacts;
design tools, including service modeling, dependency tracking, policy creation and management, and other tools that assist in the design of services;
deployment tools, including service deployment, typically through binding with external development environments;
links to testing tools and services, letting the developer or designer create a test plan and testing scenarios, and then leverage service-testing technology.

In essence, design-time SOA governance works up from the data to the services, gathering key information as it goes. Thus, you typically begin by defining the underlying data schema and turning that into metadata (and perhaps an abstraction of the data). Working up from there, you further define the services that interact with the data and data services, and then transactional services on top of that. You can continue to define that into processes or orchestration. All of this occurs with design-time information that is managed within the design-time SOA governance system. I get that.

Related Search Term(s): SOA & SaaS

Pages 1 2 

Share this link:

SOA Software releases project-planning suite for SOA transition
Portfolio Manager provides a framework for SOA planning, helping developers prioritize services, understand dependencies, and plan architecture and governance processes, the company says. The product is marketed as being essential for creating road maps for transitioning to SOA Read More...

News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>



Download Current Issue

Need Back Issues?

Want to subscribe?