SOA Expert Podcast Show 27...First Carcast about Virtual Applications. You can find the podcast information here.

Posted by davel in | Permalink | Comments (0)

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)

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.

Posted by davel in | Permalink | Comments (0)

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.

Posted by davel in | Permalink | Comments (0)

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.

Posted by davel in | Permalink | Comments (0)

I recorded my SaaS presentation at Arizona State University on Saturday and now it’s a Podcast. I discuss the value of SaaS, and how it relates to SOA. You can find the feed here. Enjoy.

Dave

Posted by davel in | Permalink | Comments (0)

“Software AG, Inc. today announced the availability of a Service-Oriented Architecture (SOA) gateway as part of its new Adabas 2006 product line. Adabas SOA Gateway lets developers access Adabas 2006 data using their familiar environment – including Java/Eclipse, .NET and AJAX – without any previous knowledge of Adabas or the mainframe.”

Press releases like this on rarely get on people’s radar screens, and for good reasons. However, this is indeed a significant event as we move towards SOAs, the Web 2.0, and the Mashups of all of the above.

Why? It’s bridging the old with the new, something that has been occurring too slowly, if you ask me. The ability to make existing, but productive systems, work and play with the notion of a SOA. This means they can be dealt with as true services, and not some wiggy proprietary API that must be abstracted.

In this case, Adabas, a very popular mainframe database, largely due to its performance and unique database model, can now be exposed as a service, and thus deal with other services, either through composite application development, orchestration, or both. Pretty simple concept, but the big iron software guys are slow to take these older systems to the service model. Looks like Software AG is much more forward thinking.

Good news for those of you leveraging Adabas, your SOA journey just got a bit easier.

Posted by davel in | Permalink | Comments (2)

New Podcast Up There. . .Show 25: Bob Brauer CEO StrikeIron

Bob and I talk about the concept behind StrikeIron, Web 2.0, and the future of the Global SOA.

You can find the Podcast here.

Posted by davel in | Permalink | Comments (0)

A few patterns are beginning to emerge. We can categorize them into larger buckets, including: legacy abstraction, simple composites, complex composites, and new autonomous services.

Legacy abstraction services are services built on top of existing services, including elderly technology such as Cobol and CISC on the mainframes, or perhaps services liberated from mini computers, or even enterprise class Unix systems. You can toss ERP and CRM applications into this mix as well. The notion is that you somehow are able to externalize these internal processes as services and leverage them as modern Web services, no matter how ugly and arcane the interfaces are.

Simple composites are one or two services that are bound together in a new service. Complex composites are many layers of services that are bound together, perhaps a composite that’s made up of other composites. New autonomous services are services that are created for a single purpose such as a Web service, and are typically not based on other services (non-composite).

Transactional services can be a simple or complex composite, or even new autonomous, but they support transactional characteristics including ACID. For those of you who have not seen ACID as many times as me, Atomicity refers to the “all or nothing” quality of transactions. The transaction either completes, or it does not. Consistency refers to the fact that the system is always in a consistent state, regardless of whether or not it completes the transaction. Isolation refers to the transaction’s ability to work independently of other transactions that may be running in the same environment. Durability means that the transaction, once committed and complete, can survive system failures. With new standards such as WS Transaction, how you build a transactional service should be more consistent. For now, developers are taking their own unique approaches, typically leveraging TP monitors or application servers.

Data services, as you might expect, are services that are built to produce and consume data. These could be Web service abstractions on top of call level interfaces, or simple services exposed out of an ERP system that produces data. These are very simplistic services, with schemas, access controls, and the encapsulated data. Almost always these are services built on top of relational database, but other database types are leveraged as well. Moreover, through a data services abstraction layer, you can emulate database types to meet the needs of your SOA.

Light weight services, as the name implies, means that you’re doing things with a light volume (typically less than 10 invocations or messages-per-second), and the size of the message that the service is passing is small (typically less than 50 KB). Heavy weight services, in contrast, do heavy volumes (greater than 10 invocations or messages-per-second, but more typically 100-300 invocations and message-per-second), and can transmit and consume huge messages.

Posted by davel in | Permalink | Comments (0)

When building a SOA, most are leveraging loosely coupled type architecture. Why the benefits of building a loosely coupled SOA with many services are apparent, the operational characteristics could be a bit of a nightmare. However, with a bit of planning, and the use of some standards, your SOA will be as reliable as functional.

The key problem to solve is to make many services, some you own and some perhaps you don’t own, work and play well together. The objective here is to leverage many services, and do so in a manner that makes them appear like a single application. Albeit the services could be running anywhere, in and outside of your organization. In short, making many appear as one.

Okay, now that we know what the problem is, how do we solve it?

You need to remember that this is largely an architectural problem, and not something you can toss products and standards at. Indeed, you need to define the capabilities of your SOA based on the requirements of the domain, and back the appropriate solution set (standards, tools, technologies) into it. For instance, too many fine grained services and all of the technology and standards in the world won’t help you.

What’s key here, at least from an architectural perspective, is that you make the right calls in terms of what services are going to make up your SOA supporting critical business events. This is where most SOAs go off track, typically attempting to bind too many services, and at the wrong granularity. You can consider services that make up your SOA like links in a chain, each defining the reliability and performance.

Having stated that obvious problem, there are techniques, technologies, and standards that you can apply that provide your SOA with better capabilities to manage a loosely coupled and distributed SOA. Although they are just getting off the ground, I believe they are some of the most important emerging capabilities.

Posted by davel in | Permalink | Comments (0)

Hey. Those of you who have sent me notes upset that my Podcast server ran out of bandwidth, I have good news. I moved my cast over to another service that provides unlimited bandwidth, thus no more denial when you’re looking for that SOA news on the treadmill.

You can find the Podcast here on the ebizq.net site.

Posted by davel in | Permalink | Comments (1)