Service-Oriented Architecture

Web services were created around the notion that it's easier to discover and leverage somebody else's service rather than write your own from scratch. Also, it is much easier to create applications made up of many services, thereby allowing change to occur at a pace faster than anything we've seen in the industry thus far.

The idea of Web services was to create a standard interface, programming model, description language, and a directory that would allow this to happen in and among very different systems. Indeed, today you can leverage services across the Internet that are functionally equivalent to the services being hosted locally.

Taking this concept to the next level, we can build applications (composites) through the selection and use of these Web services. For instance, we have no need to write a logistics subsystem if one exists on a server someplace for you to leverage it. There is no need to write a risk analytics application; instead, leverage somebody else's work. You get the idea. This is clearly more a traditional computing concept than something new, thus saving a ton of time in the application development process and allowing businesses, large and small, to become more agile and have a much more cost effective IT. This is the promise of SOA.

Considering that we both understand the benefits of leveraging Web services and are willing to change our existing systems to support the exposure and leveraging of services, now what? The next step is brokering, or allowing consumers of services to find producers of services. There are a few instances of brokers today, including StrikeIron, Jamcracker, and SalCentral. Keep in mind that these brokers are also similar to directory and governance systems we are defining in SOAs today.

These brokers, as well as brokers yet to emerge, will provide a few key features to facilitate consumers finding producers, and the ability to monetize this interaction, such as:

• A directory service where the Web services can be found that contains a description of the service, owner, technology documentation, etc.
• An ability to charge for the service, either through a perpetual license, or a pay-per-drink kind of arrangement
• An ability to share reviews and other user information with other services users
• The ability to support a federated identity infrastructure

Thus, like monetized Web sites today, you're able to create a service, register it with a broker, and sit back and see the usage turn into fees for use. You can count on seeing many companies, such as the on-demand application service providers today, beginning to sell their Web services versus simple browser interfaces to applications. Clearly, Salesforce.com and Netsuite are moving in this direction. Moreover, we'll see smaller players, such as the "one guy and a dog" hit it big time as they create that killer service that everyone wants to leverage.

So, how do you prepare for this forthcoming market? Those who design and post services will have to understand a few basic principles:

1. Focus on granular services that are part of a holistic solution
2. Consider many service externalizations scenarios.
3. Track usage
4. Quality in the design

Focusing on granular services that are part of a holistic solution means that you consider the problem you're solving, as opposed to just the service you're implementing. Moreover, you're willing to provide many services that together will solve a business problem, but at that instance solve a tactical problem. For example, you're building a service to track overdue accounts, but you also need to consider how that works and plays with existing accounting applications, or other accounting services.

Considering many service externalizations scenarios means that you're building a service that may be externalized to humans or to other computer systems through a variety of interfaces. In essence you're interface-agnostic, understanding that the value of the service will need to be realized within a variety of systems, all having different looks and feels.

Track usage. Not to be too big brother, but it's nice to know who's using the service and where. This serves two purposes: first, it allows you to match up your income expectations with service usage. Second, it allows you to solve performance and availability issues before they become a larger problem. Remember, you're hosting this someplace, it's not delivered in a CD. You can build a tracking subsystem easily within services; make sure that those using the service understand that such tracking exists.

Quality in the design. If you're going to sell or rent service, you need to understand that the quality of that service needs to be impeccable. In essence you're becoming part of an application that's unknown to you, therefore you need to design that into the service as well as test the service, more so than any application. Not doing so means you'll be disruptive to those using your service, and your service won't add value; thus, it won't be used.

Go, make some money!

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...