LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
ASP.NET MVC 2 Ships
ASP.NET MVC 2 has shipped.
03/12/2010 10:26 AM EST

Microsoft plans 'open' Silverlight analytics framework
Microsoft is going to announce a multipurpose analytics framework for Silverlight at MIX.
03/11/2010 09:51 AM EST

About CSS processing
Two sites that lead to a startling CSS conclusion.
03/10/2010 02:29 AM EST

 

Events calendar tab
SHARE
3/14/2010 to 3/18/2010
Seattle, Wa.
SHARE

Cloud Connect
3/15/2010 to 3/18/2010
Santa Clara, Calif.
TechWeb

Microsoft MIX10
3/15/2010 to 3/17/2010
Las Vegas
Microsoft

SharePointPro Summit & Expo
3/16/2010 to 3/19/2010
Las Vegas
Penton Media

TheServerSide Java Symposium
3/17/2010 to 3/19/2010
Las Vegas
TechTarget


 
print Printable version 
Most Read Latest News Blog Resources
Even with its success, .NET causes some consternation
Despite its popularity, the developer community believes that .NET isn't being fully serve...

Appcelerator dev environment targets Android, iPhone
This unified development environment compiles JavaScript into Objective-C or Java, and wil...

Eclipse creates new sub-projects for Mylyn
The sub-projects are designed to help organizations adopt agile ALM, and they will also br...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Time may be up for design-time governance


By David S. Linthicum
September 15, 2008 — 

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.

The issue with design-time SOA governance technology is how far the technology goes toward serving the true notion of "design" as outlined above. Most don't go that far, and many SOA designers are left wanting more robust features and functions, including true modeling and simulation capabilities based on SOA design and development best practices. Thus, most bypass design-time governance and go directly to runtime, and for good reason.

As with most SOA technology, another issue is the lack of a standard approach to design-time SOA governance. While a few standards are emerging, most SOA governance technology providers have gone off in their own directions, using their own approaches, and no two are alike. Thus, not only are you picking a tool, but you're also picking a design approach, which may or may not be right for you or your architecture. Most SOA projects that I see are being designed as best they can be using traditional office automation tools, and those seem to be working just fine. Not that it would be a bad thing to leverage a good design environment—but they just don’t seem to exist within the design-time SOA governance tools available today.

Moreover, most of the design-time SOA governance tools I’ve seen seem to spend most of their time worrying about runtime issues such as SLAs, while offering little that address the key design-time issues. Most SOA architects have become frustrated with the design-time options out there and are resorting to spreadsheets as their design-time tools of choice. Clearly, this area is poorly understood and poorly represented by the design-time SOA governance vendors out there today.

So, how do you fix the issues with the existing design-time SOA governance tools?

First, you work on a high-level approach that makes sense and figure out how that approach binds into a larger SOA design and development methodology. There simply is no context—and thus no value—with the tools that exist today.

Second, you’re either a runtime tool or not, so figure out how deeply your tool needs to drive into that part of the architecture. My advice would be to do it well or don’t do it at all. There are many runtime SOA governance tools that are already doing it well these days.

Finally, get together and create standards, technology and approaches that are consistent from tool to tool. Right now they are all different and thus proprietary—and that’s a hard sell these days when people look for durable standard technology that will be strategic over a long period.

Reach analyst David S. Linthicum at david@linthicumgroup.com.


Related Search Term(s): SOA & SaaS


Share this link: http://www.sdtimes.com/link/32819
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading