February 10, 2008   Sign In |  About ebizQ |  Contact Us |  Join ebizQ Gold Club
David Linthicum
Dave Linthicum's Podcast Channel
Industry expert Dave Linthicum's musings on the integration industry, delivered once a week.

« November 2005 | Main | January 2006 »

December 21, 2005
New Podcast Up There...Show 23 JP Morgenthal and I on SCA

New Podcast Up There...Show 23 JP Morgenthal and I on SCA

Interview with JP Morgenthal, including what's what on SCA. To SCA, or not to SCA.

www.soaexpertpodcast.com

Posted by davel in | Permalink | Comments (0)

December 14, 2005
Solving the “Last Mile” Issue with Service-Oriented Integration

According to Zapthink Communications the SOA market is expected to grow from $435 million in 2001 to about $6.2 billion in 2006, this from a Service-Oriented Integration Foundation Report Using Web Services and XML to Integrate Systems. Impressive numbers. Clearly we are at the inflection point as enterprises prepare their infrastructure to leverage services.

However, as with any new trend there are always those annoying problems that we must solve in order to offer a complete solution. In the case of SOA it’s the “last mile” issue, or bringing your SOA to your existing systems, be they built 20 years ago or 20 days ago. In other words, exposing all of your enterprise systems as services, as well as managing how those services work together.

So, how do you approach the last mile problem when building out your SOA? Simply put, it’s really a matter of understanding and applying the right technology. I recommend the following procedure:
First, create a catalog of your potential services, or existing application functions. New or old services, it does not matter.

Keep in mind that services should be limited in their scope. For instance a service that controls inventory is too broad, not granular enough. It would be much better to document all of the sub-functions and sub-sub-functions to identify 1000 potential services, not just a few out of a single enterprise application. This gives those that use the services the opportunity to mix and match services at a much lower level, and thus makes those services more useful.

Second, figure out a strategy for exposing those services. The fact of the matter each system is going to need a different technique (see above) and a different enabling technology to complete the last mile. In some instance it’s going to mean redevelopment, in other instances it’s going require software the mediates the difference between the native interfaces or standard interfaces and Web services. In some instance the Web services are already exposed, if you’re lucky.

Third, document the data and structures bound to those potential services. In other words, how does that service use data and what’s the schema employed.

Finally, you’ll need some type of strategy to test the exposed services, making sure the exposed services function and perform correctly. In some instance you need to do some tuning and tweaking, depending on what you find. Remember, these services are destined to become parts of other applications, so any quality problems will be replicated over and over again.

Clearly, integration can be complex and difficult, and the hardest part of integration is linking your existing systems to your SOA and seeing those systems as a true set of services. This is also where most IT shops fall down, not able to make the walk down that last mile. Unfortunately, it’s the last mile to your success with SOI and SOA. If you don’t complete your journey, the problem is not solved.

Posted by davel in | Permalink | Comments (1)

December 12, 2005
Okay, How Does One Measure Agility?

Okay, if agility is a strategic advantage of leveraging a SOA, it's clearly difficult to measure in hard dollars, but not impossible. We first need to determine a few things about the business, including:

• The degree of change over time.
• The ability to adapt to change.
• Relative value of change.

Am I missing something.


The degree of change over time is really the number of times over a particular period that the business reinvents itself to adapt to a market. Thus, why a paper production company may only have a degree of change of 5 percent over a 5 year period, a high technology company may have an 80 percent change over the same period.

The ability to adapt to change is a number that states the company’s ability to react to the need for change over time. The notion being that the use of an SOA provides a better ability to change IT to adjust to needed changes in the business.

Finally, the relative value of change is the amount of money made as a direct result of changing the business. For instance, a retail organization’s ability to establish a frequent buyer program to react to changing market expectations, and the resulting increases in revenue from making that change.

Posted by davel in | Permalink | Comments (0)

December 05, 2005
Is SOA more about Reuse, or Agility?

Lately, there has been a lot of talk about what’s working and what’s not when it comes to building the first instances of a SOA. Reuse seems to be a key component, with the most of those implementing a SOA pointing reuse out as a key driver. I think this trend will continue for the next few years, as those within enterprises stand up a SOA for the purpose of building a library of services they can abstract from system to system.


However, agility, or the ability to create an agile IT architecture that’s able to change as the needs of the business changes, is also a major benefit, perhaps more valuable then reuse in the long run. The issue is that in the short term is there is really no good way to measure the value of agility…it’s more of a long term notion.

Thus, why many are seeing the benefits of a SOA through reuse of services, longer term it’s agility that will pay the rent for most SOA implementations, and is really what makes the approach strategic to modern businesses. My point: Agility should always be in the back of your mind when building out to a SOA, more so than reuse.

Posted by davel in | Permalink | Comments (2)

December 01, 2005
7 things to look for in SaaS

Business is getting faster, and is demanding that technology keep up. The days of long planning cycles for implementing technology is over, indeed business is demanding that the technology be there as needed. Enter the notion of SaaS, a concept that brings real power to business, allowing technology to better respond to today’s rapidly changing business environment. In essence the right technology at the right time.

So, if SaaS is something good, exactly what is it? Let’s take a look at the notion of SaaS, and what to looking for in an SaaS technology solution, including:

1. Ability to deploy rapidly
2. Ability scale
3. Ability to adjust cost with need
4. Ability change quickly
5. Ability propagate new features
6. Ability to drive real time
7. Ability to define the value within current business


Ability to Deploy Rapidly

While speed kills on the highway, it has the opposite effect on business. SaaS, means the ability to get your information technology as you need it and purposed properly. The time between need and deployment needs to be days and weeks, not months even year. We should consider technology like a water tap, when needed we turn it on getting just the amount we need.

For instance, say there is a critical business need to combine sales data with credit data, both in different system in different companies. Traditional forms of integration could take a year or more to design and deploy…too slow for modern business. However leveraging integration SaaS, you’re able to access the integration technology you need, typically without having to deploy software within your own infrastructure.

Ability Scale

SaaS won’t do you much good if the IT you’re demanding won’t support the capacity you need, thus any SaaS solution needs to scale to meet any requirement that a enterprise may have. Scalability is something not well understood. It’s not as much a matter of bandwidth and processing power but the ability to operate at a capacity that meets the business needs of the organization. There is a difference.

Ability to Adjust Cost with Need

The primary business driver of SaaS is the ability to pay for only the service you need and use, thus the economics are compelling. Many large organizations in the 90s spent millions of dollars on enterprise class software licenses which went largely unused. While the large enterprise software companies loved this model, many businesses did not realize the value for their IT dollar. SaaS is therefore more compelling.

Ability Change Quickly

Change is a fact of life in the business world, and an SaaS model provides the ability to adjust to rapid change, no matter if it’s an increase in need, or the ability to add and delete features. SaaS means that change can occur without time consuming renegotiations of software contracts, as well as installation and testing of new software.

Ability Propagate New Features

As new features are released, including bug fixes, the SaaS model provides for a mechanism that allows new features to reach all of those that need them, as they become available, without interrupting business nor creating additional cost issues. For instance, a new data format standard is released and that functionality will become available to those leveraging SaaS without having to stop production or upgrade software locally.

Ability to Drive Real Time

You won’t realize the true value of the SaaS model unless you it bring real time visibility of both business information and processes under your direct control. This means information is up-to-second current, and thus you have the ability to make decisions based on the most current data about your business. Moreover, you’ll have the ability to establish automatic mechanisms to carry out predetermined actions, such as automatically pulling a D&B on a sale greater than a million dollars.

Ability to Define the Value within Current Business

Finally, when leveraging the SaaS model you should have the ability to define the value of SaaS in context of your current business, not long term. While this sounds tactical to many, it’s really creating a strategy that creates a way of doing business that is much more cost effective and responsive than more traditional non SaaS type strategies. When using SaaS you should have the ability to scale your business, change when needed, and have full value of your information in real time without having your IT infrastructure lag behind, nor create a cost problem.

SaaS is really a new way of thinking about IT, making IT adjust for you business and not the other way around. As companies become more nimble and competition becomes more aggressive those that leverage the SaaS model will find that they have a key advantage.

Posted by davel in | Permalink | Comments (0)

Marketing Solutions | Feedback | About ebizQ | Unsubscribe | Privacy Policy | Site Map