1. Reuse of services/behaviors, or the ability to leverage application behavior from application to application without a significant amount of re-coding or integration. In other words, using the same application functionality (behavior) over and over again, without having to port the code…leveraging remote application behavior as if it existed locally.

2. Agility, or the ability to change business processes on top of existing services and information flows, quickly, and as needed to support a changing business.

3. Monitoring, or the ability monitor points of information and point of service, in real time, to determine the well being of an enterprise or trading community. Moreover, the ability to change processes to adjust processes for the benefit of the organization in real time.

4. Extend reach, or the ability to expose certain enterprises processes to other external entities for the purpose of inter-enterprise collaboration or shared processes. This is in essence the next generation supply chain integration.

That's my story as of now.

Posted by davel in | Permalink | Comments (0)

One of the interesting things about this is that enterprises allow their software vendors to determine major portions, or in some cases all of their SOA strategy. This is not the right way to go about building your SOA.

Instead, enterprises need to work from their requirements to their design and technology selection, and not the other way around. By allowing your software, database, and even your middleware layers to determine how you’ll approach SOA, you’re giving up control and increasing the risk that your SOA will fail.

So, what’s an ERP junkie to do? First, it’s a matter of placing all major enterprises systems in their own domain, in essence abstract yourself away from any odd strategic decisions they may make that don’t match up to your business objectives, albeit you can’t do this completely. This places the larger enterprise software providers as mere service points on your SOA, meaning that they simply become an intra-company service provider, and not the master of enterprise processes.

Posted by davel in | Permalink | Comments (0)

The notion of orchestration is really nothing new, however it’s value as an enterprise resource is, and it’s clearly the driving force behind the value of a SOA. Simply put orchestration is the ability to control how information flows and services (behaviors) interact to form solutions, processes really, existing between dozens sometimes hundreds of systems, within and between enterprises. In essence, a meta application layer over and above existing services and data that binds remote systems together, to meet the changing needs of a business.

The key word here is changing. The value of leveraging an orchestration layer is not that you can easily define processes that exists between information and services, but the fact that you can easily change those processes later to adapt to changing business needs. Indeed, if it was all about creating processes a single time, you would be better off with a compiler than an orchestration layer, but the ability to place volatility in a single domain, in this case a process/orchestration engine, will payback many times the original investment. That’s why, I believe orchestration defines your SOA, and you won’t have an effective SOA without orchestration.

Orchestration is a necessity of you’re building a SOA, intra- or inter-organization. It’s the layer that creates business solutions from the vast array of services and information flows found in new and existing systems. Orchestration is a godlike control mechanism that’s able to put our SOA to work, as well as provide a point of control. Orchestration layers allow you to change the way your business functions, as needed, to define or redefine any business process on-the-fly. This provides the business with the flexibility and agility needed to compete today.

You approach orchestration as you would approach any other new technology. First, define its value and purpose. Second, define your own problem domain including existing data and services. Third, prototype a small problem to obtain functional experience. Once that occurs, it’s time to create your strategy, select your technology, and roll out our solution. This is one of those technologies that makes a difference in the way the business runs. I

Posted by davel in | Permalink | Comments (1)

Dion and I discuss the notion of Web 2.0 as the Global SOA and its impact on current SOA thinking. Also, we comment on the Systinet acquisition.

You can get the Podcast here.

Posted by davel in | Permalink | Comments (0)

Embrace your legacy systems. In fact, they may be the majority of services that you leverage within your SOA. This means service-enablement of systems that you would consider old and outdated, but indeed serve a purpose within the business and thus serve a purpose within your SOA. Those who attempt to displace and replace existing systems, just to support new technology, are destined to make their work much more complex and far reaching than it need be.

Posted by davel in | Permalink | Comments (1)

At the end of the day, services are small, specific applications and need just as much attention paid to design. If SOA supports composite applications and composite processes made up of services, then the overall design of services will determine the overall success of things made out of those services…it’s just that simple. Tried and true design techniques are applicable for service design as well. Please use them.

A few service patterns are beginning to emerge. We can categorize them into larger buckets, including:

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 (Atomicity Consistency Isolation Durability). 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 databases, 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)

As technologists, we don’t always want to make business cases for the technology. Indeed, we have a tendency to leverage the most popular technology without regard for how its use will affect the bottom line. Not a good practice if you want IT to have a strategic position within an organization.

From my blog on Monday, we indeed build SOAs because they provide an infrastructure for agility, or the ability to change processes in support of a changing business. They also allow for reuse; the ability to reuse application behaviors from system to system without having to port and retest code.

In order to understand the ROI, you need to define a business case around the notions of reuse and agility before you begin your movement toward an SOA. The anticipated ROI will determine the proper investment, and thus insure that the implementation of a SOA strategy has value within the enterprise, and you’ll have business success along with technological success.

Posted by davel in | Permalink | Comments (0)

Let me make this clear in 2006, SOAs are all encompassing architectures, not mere projects, and those who consider them ‘projects’ are doomed to failure.

You’re in for a pound when implementing SOA due to the fact that, the more penetration the architecture gets, the more value it has within the enterprise. Thus, you need to understand from the starting line that SOA is a notion that we build to, not build.

There is no SOA project, but there is an SOA strategy within an enterprise. When we hear “Our SOA project failed,” that’s not the fault of the architecture; it’s how the architect defined the scope. You have to focus on the bigger picture or your SOA won’t have the required value.

However, since an SOA project is the sum of its parts, you must consider the component parts as well, including notions such as identity management, semantic management, orchestration, etc., and how each part makes up the larger solution. An SOA is only as good as the weakest component, and neglecting a component will kill an SOA before it gets off the ground.

Posted by davel in | Permalink | Comments (0)