Every eCommerce site requires two essentials: content and customers. In this post, the first in a two-part series, I will focus on the customer-half of the equation. Let’s face it: you can have all the content in the world but if nobody is buying, then half the equation is zero, and anything times zero equals—you guessed it—goose egg.
Continuing our discussion of Service Oriented Architecture, let’s look at some of the chief benefits.
SOA is designed to eliminate dependencies on a particular implementation technology. When services are accessed through a common interface, the underlying implementation can change without changing the systems that build upon them. The implementation of the service can change for many reasons, such as:
Replacement of aging hardware
Changes to operating systems or application servers driven by security policy or cost considerations
Selection of a more productive software development platform
One or more of these components can change without impacting any of the dependent processes if implemented within a proper architecture.
This is valuable when trying to leverage legacy systems for new applications. Perhaps there are many potential clients for the legacy system, but the respective clients might use different software development platforms. Hand-writing the software necessary to integrate with a system of moderate complexity can take several weeks.
Rather than asking each client to duplicate this effort, the legacy system can provide a web service adapter with a machine-readable description. Then, each client or business process can automatically integrate with the service—skipping the time-consuming, expensive, and error-prone process of manual integration.
Reliability is enhanced as well, since there is only one piece of software to be tested (the web service adaptation layer) rather than an integration layer within each client.
There are cases when an entirely new system is being designed, and an architect might have the power to mandate a particular implementation technology. Even then, accessing the constituent services through a standard interface is a wise choice for two reasons:
1) It provides a measure of “future-proofing” to the system. As new implementation technologies emerge, they can be adopted piece-meal by different services and their dependent processes.
Organizations have been using large enterprise systems for decades to improve business intelligence and processes. These systems—when correctly designed and implemented—provide organizations with important strategic advantages, including improved efficiency and reduced costs. However, implementing the wrong system or implementing it the wrong way can have the opposite effect—making an organization less efficient and ultimately more expensive to operate.
According to a recent report, 70 percent of large-scale government software projects fail to achieve their stated business objectives, are delivered late, or are substantially over budget. In August of this year, White House officials identified 26 high-risk programs within the federal government that are experiencing significant cost increases and schedule delays. These projects, which span 15 departments and would cost $30 billion for completion, are all mission-critical programs that are being put through a fast-paced reassessment process to move them forward, possibly in modified forms.
Below are three strategies organizations can take to avoid these pitfalls. These proposed strategies are based on nearly two decades of research, experience, and lessons learned by Partnet in developing and implementing large-scale Government web applications.
Strategy 1: Use Custom Code and Open Standard Technologies to Increase Interoperability of COTS Products
When introducing a new enterprise system, it is important to recognize COTS products can be difficult to integrate. While COTS products normally work fine independently, combining them together so that they function seamlessly is the real challenge.
One key to interoperability is understanding when to use custom code as a means to more tightly integrate COTS components. It is important to determine when custom code is called for, and when an existing tool will work best. Using open commercial standards like XML helps to balance the costs and risks associated […]