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


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Syncfusion announces component suite for .NET 4
Essential Studio 2010 has business intelligence, reporting and UI controls, ready for .NET...

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

Guest View: SOAs Are Turning the Corner


By Brent Carlson
September 1, 2005 — 
In the past year, service-oriented architectures have become mainstream because of their promise to provide business agility and flexibility through integration, productivity and reuse. Organizations across many industries are now investing in SOA strategies in order to put their IT house in order. In fact, a recent Forrester report found that more than 70 percent of large enterprises, as well as many small and medium-sized businesses, are currently deploying SOAs.

The market has seen numerous vendors emerge with SOA offerings and services, and major analyst firms have pushed a positive outlook on the market. With the hype and promise of SOA continuing to build, and initial adopters of the various technologies supporting SOA beginning to realize ROI, it is important to keep in mind that there are a number of areas that need to be addressed for the full promise of SOA to be realized.

First, all the hype has led to a certain amount of confusion. SOA does not equal Web services—in other words, a Web service that exposes a particular business function may very well be too fine-grained or too narrowly defined (i.e., application-specific) to be considered a valid element of an SOA. SOA is an approach to enterprise architecture that abstracts IT functionality into business-oriented services. Getting an SOA right means spending some upfront time thinking about key business processes and how they can be supported by a set of common underlying services.

SOAs will deliver significant financial and efficiency benefits only to the extent that they enable disparate projects to reuse common services that support key business processes. The long-term ROI of SOA will best be measured by the ability to rapidly implement new applications and integrations based on existing services, enabling organizations to react quickly to changing market demands, while simultaneously reducing both development and operational costs by eliminating redundant code. This of course is easier said than done. Achieving this “SOA Nirvana” requires a governance process that supports, tracks and manages service production and consumption within an SOA.

Best PR for Governance
Establishing governance functions at the onset of an SOA project is important for a number of reasons. Countless vendors are providing solutions that facilitate the deployment of SOA, such as UDDI registries, Web services security tools and XML registries, and others have begun to sell products that can do things such as monitor Web services performance and operations.

All of these solutions are valuable in an SOA environment, but the full potential of SOA will not be achieved unless there is a structure in place that gives management (and their adjunct governance arm, the enterprise architecture team) the ability to view the various moving parts associated with service development and deployment and track them throughout the application development life cycle.

Giving management this insight, and being able to offer developers access to information on a service—be it the history of the service, details on its performance, configuration, compliance with licenses, security posture, etc.—brings the promise of SOA full circle.

A big part of the governance process, of course, will be managing the tension of near-term business priorities against broader SOA objectives. Companies must make sure to guide the business functionality of services and get enough real, live business requirements applied against the services that are being developed so that they have a chance to build general services instead of point-specific services that meet one specific business process need.

To accomplish this, a combination of “bottom-up” and

“top-down” approaches is best. Bottom-up refers to the development of services based solely on immediate project needs. If one takes just this approach, the service layer becomes what SOA is attempting to prevent—YALOT (Yet Another Layer Of Technology), or more spaghetti code that implements a monolithic application in a different technology instead of improving business process flexibility.

Similarly, services also should not be exclusively defined in a top-down manner. Top-down business process analysis often leads to one of two outcomes: “analysis paralysis,” continual refinement of a model hoping to reach perfection (which never comes), or “Big Bang” projects that try to “boil the ocean”—defining and implementing everything at once, usually with disastrous consequences.

By combining the two approaches, business services are developed that can support an immediate project’s requirements with enough flexibility to meet future business process needs, both projected and unknown. Selecting development projects whose business processes establish overlapping requirements on common services allows an IT organization to incrementally define those services while meeting near-term objectives.

Two or three points of view (as expressed by these varying business processes) are enough to begin the service normalization process, producing a “version 1” service that is both general enough to support the first wave of development projects and that provides a solid basis for iterative enhancement based on the next wave of project requirements.

Proper governance of SOAs also demands that technical aspects of service development be carefully addressed. For example, architectural, performance and security reviewers may be involved at various software development life-cycle (SDLC) checkpoints to ensure that the services being built are using designated technologies, will perform adequately, and will not introduce security holes into the IT infrastructure.

As important as the business and technical aspects of SOA governance are, governance over service consumability is just as necessary. Unless you are building trivial Web services (like the ever-popular stock-quote service used so often in demo scenarios), you will need to provide considerable documentation beyond WSDL.

Consider requiring user guides, sample client code and traceability in addition to the original business requirements as part of the consumability governance process. This information, along with other searchable metadata about the service that is ideally managed within a software development asset repository, will make it easy for application developers to find the right service and give them confidence that the service is of high quality and will meet their needs.

Ultimately, you may have built a good service that conforms to your technical architecture and meets your business function needs, but if no one can understand it and no one can find it, what good is it?

Governance Is Key
SOA has most definitely turned the corner. It has gone from an architecture that organizations “are considering” and “see the benefits of” to an architecture that is in actual deployment. Early adopters are experiencing encouraging initial returns, but the ROI is expected to spike as services are reused time and again in an enterprise.

With the emergence of SOAs, governance processes are a must-have and software development will evolve to stress the quality and iterative top-down/bottom-up approach to the development of services. Orchestration tooling being built on top of services will progress as SOA progresses. I should point out that there is some good initial work being done by Microsoft with BizTalk, IBM with WebSphere Business Integrator, and other tools that are on the market. As the SOA industry matures, these and other tools will continue to develop their capabilities.

In terms of standards (I know it’s on your mind), BPEL has emerged showing promise as a way to bind services together into applications. It gained a lot of ground in 2004 and so far in 2005, and I expect its momentum to continue as more companies begin incorporating SOA into their IT plans.

Will SOA finally be the answer to our interoperability woes? Only time will tell, but the early returns are promising. As we move forward, keep in mind that establishing a governance process at the start of your SOA initiative will enable you to maintain control of your assets and ensure that enterprise technology is properly aligned to support business goals.

Brent Carlson is co-founder and vice president of technology at LogicLibrary, which sells asset-management tools.


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading