| home / programming / soa / 1 |    [previous] [next] |
|
|
|
Whereas the use of XML is no longer an option for many organizations, a move to a service-oriented design paradigm or a full-scale SOA often needs a bit of justification. This is especially true when large investments have already been made in (non-service-oriented) EAI projects with which an organization is already quite content.
ROIs open eyes “ROIs for service-oriented architectures can provide valuable information, beyond that required to justify the project.”
Regardless of whether you are asked to justify the use of Web services or have already decided to implement them in your environment, putting together a realistic ROI can be an enlightening experience.
In addition to providing "evidence" that predicted cost savings resulting from the use of Web services will be realized, properly researched ROIs can give you a clear idea as to how long it will take for these benefits to be attained.
Iterating through ROI and migration strategy documents “Keep revising the ROI as new information becomes available.”
It is common for the results of an ROI to shape an enterprise migration strategy. Flip that thought around for a second, and consider using a migration strategy as input for the ROI.
The nature of the research that tends to be performed for migration strategies is more focused on technology and implementation, rather than high-level organizational benefits. An intelligent strategy for integrating a service-oriented architecture can lead to much greater cost benefits than an ROI originally predicted. So, even if you used an ROI to justify your migration project, you can typically refine that ROI (and often improve the justifications) using the contents of your migration strategy.
Confused yet? Have a look at the diagram in Figure 13.1.
Figure 13.1
An iterative cycle between a migration plan and an ROI.
The initial SOA migration may be the most expensive part of an enterprise-wide initiative however, the scope of your ROI will likely go beyond the migration phase. Further revisions to an ROI will improve the accuracy of its predictions as they relate to subsequent phases in a long-term program.
ROIs for Web services can also be easier to justify than for other XML-based technologies. The benefits tend to be more tangible, because the interoperability enabled by the service integration layer results in immediately recognizable savings.
“Design a service-oriented solution to accommodate its probable migration path."
The built-in features of a Web services framework are there, whether you choose to use them or not. The foremost benefit of any service-oriented environment is the intrinsic potential for immediate and future interoperability. You can take advantage of this potential by designing application architectures for integration, even when not immediately requiring integration.
Fostering integration requires a change in design standards, application architecture development, and the overall mindset of the project team. For example, you can facilitate local requestors as well as future remote requestors by providing both coarse-and fine-grained interfaces based on standard naming and service description conventions.
To an extent, you can consider this new approach as building integration architectures, regardless of whether they will be integrating anything immediately. Perhaps a better suited term would be “integrate-able architectures.”
Chapter 14 fully explains this design approach by providing future state environments for service-oriented integrated architectures and EAI solutions.
13.2 Best practices for standardizing Web services“Consider standards for Web services as standards for your infrastructure.”
In the corresponding section of the previous chapter,1 I used an analogy about obeying traffic laws in order to highlight the importance of standards when integrating XML within a development project. Let’s alter that analogy to define an approach for standardizing the integration of Web services.
A city’s commuting infrastructure is almost always standardized. A traffic sign on the East side generally communicates a message (stop, yield, merge) the same way on the West side. You, the driver, can go from any point A to any point B with the confidence of knowing that the rules of navigation are being expressed consistently. Take your car outside of the city boundary, though, and that might change.
As with any enterprise application development project where you have different units of developers building different parts of the system, standardizing how each part is designed is important for all the traditional reasons (robustness, maintenance, etc.). In the service-oriented world, though, the real benefit is in establishing a standardized application interface. In an enterprise, this can potentially translate into a standardized system for navigating:
1. The “Incorporate standards” best practice in Chapter 12.
Back to our analogy: A different city, let’s say in another country, will have a compatible driving platform (paved streets, intersections, traffic lights), but there will be new signs with new symbols, and often a different approach to driving altogether.
Navigating through non-standard environments will always slow your progress and introduce new risks. When developing services within your enterprise, you are establishing infrastructure through which developers, integrators, and perhaps even business partners may need to navigate in the years to come.
Simply adding a common platform for data exchange is not enough to ensure a quality service-oriented environment. You need more than streets and intersections to guarantee a safe and consistent driving experience.
| home / programming / soa / 1 | [previous] [next] |
Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers
Created: March 27, 2003
Revised: February 21, 2004
URL: http://webreference.com/programming/soa/1
