SOA

According to a Software AG study, 83% of IT directors polled said they will use SOA to cut costs and 40% said they planned to implement SOA governance in the next year.

Innovative vendors offering ways to make the transition to a cloud-based world less daunting.

Broadening adoption of a service-oriented architecture requires more planning, better management tools and more effective measurement of what's working -- and not working.

Even though certain products have "policy management" in their names, getting your infrastructure set for SOA policy should start not by evaluating products, but rather by understanding the major functions required for effective policy management and how they work together.

One of the biggest decisions MuleSource CTO Ross Mason faced in 2008 was whether to include UDDI support in the initial releases of its Mule Galaxy SOA registry. Although Mason remained confident that the world was moving away from UDDI, it is often a "check box feature" in the RFPs of organizations looking to adopt an SOA governance tool. So he gambled and instead chose to make a stand that this software category required a new, simpler architecture (namely, REST)

A service inventory is a living body of services that individually will need the freedom to evolve independently over time. What we learned when documenting the SOA design pattern catalog is that there are patterns that emerged not only at design-time but also during this post-implementation evolutionary stage in a service's lifecycle.

Enterprise-wide harmonization is a desirable and ideal target state that fully supports pretty much everything SOA and service-orientation stand for. For those that have achieved such a state, bless your standardized hearts. You have accomplished something that has eluded many others. However, not attaining this state does not mean you cannot successfully adopt SOA.

The single reason that you use IT within your organization is for service enablement. IT has proven itself to be essential to provide the levels of service that customers demand.

SOA is touted for its efficiency and agility, and if at least some of the stuff is already in place, indeed in every place, why isn't anyone getting to clock out and go home early?

Service-oriented architecture (SOA) can demolish the status quo. Decades of siloed system design have left most government organizations with antique, rickety systems that don't play well with others. By putting new SOA wrappers on old proprietary applications, modular interfaces can be built, shared, linked, reused and recombined as needed. No need to rip and replace old systems; instead, they can be refurbished and extended internally and even externally via the Web. This is where SOA shows promise well beyond rejuvenating legacy enterprise systems, says Bill St. Arnaud, senior director of advanced networks at Ottawa-based CANARIE Inc.

Service-oriented architecture (SOA) is all the buzz these days, but those in the know say the concepts behind SOA have really been around for some time. Not a technology per se, SOA is rather a way of designing systems that communicate with each other in a self-contained way so they don't depend on the context or state of the other services.