I have been looking at a broad range of technologies and technology issues over the past several weeks. It is the beginning of that time of year when vendors want to convince industry watchers that they are the best and brightest in the world and that each of these providers is poised to soar into the stratosphere… (so to speak). So, it has definitely been an interesting time. But before I tell you a few of the things that I think are significant, I wanted to share an observation.

E-Commerce and SOA similarities? About 7-8 years ago the industry was abuzz about e-commerce and how companies would be connected across a real-time supply chain so that products and services would be bought and sold through an electronic network. At that time I remember talking about this phenomenon to customers and vendors. I found that there was a considerable skepticism. How would it be possible that this industry would have the technology infrastructure, knowledge, and will to make this happen? Was this not simply a pipe dream by deranged computer scientists? Move the clock forward to now and automated supply chains and just-in-time purchasing and manufacturing are the norm. In fact, the marketplace has become so automated that there is a danger of global disruption in the supply chain because there is so little reserve supply of parts or inventory.

Fast forward to 2005 and think about the movement towards a Services Oriented Architecture. I am hearing similar worries from the marketplace. Is this technology direction real? Will I put my company at risk if I invest in this movement? How do I know if a vendor that I am working with is really adopting a service oriented architectural framework? I am often asked for my opinion. So, to save time, I have put my ideas into my top ten…

Judith’s Top Ten SOA Principles

My top ten principles for evaluating SOA preparedness:

1. SOA is real. It is not a quick fix. It is a ten year journey that requires considerable planning, just like an e-commerce implementation.
2. SOA is built upon 15 years of experiments in creating highly distributed computing environments that take into account everything from load balancing, software distribution, security, and data management including meta data management and registry.
3. SOA will only work if organizations lead with manageability. SOA by its very nature demands the aggregation of IP from many different sources. Scalability within SOA will come from management – not development.
4. SOA will only work if it is implemented within the context of a business process orientation.
5. SOA is predicated on leveraging business services that represent the component parts of your business.
6. SOA requires a container that creates a composite application.
7. SOA requires standards across all vendors implementations of SOA.
8. SOA assumes that you will begin to write applications differently – as a series of tightly defined services intended to be loosely coupled.
9. SOA assumes that each component part is equipped with a clearly implemented web services interface based on standards.
10. SOA dictates that change is the norm since this approach mimics the way a business operates.

Why did I feel compelled to give you my principals for SOA? I am seeing too many vendors who put SOA on their slide decks without really understanding what SOA is and what their responsibility is to customers.

There are a lot of vendors I have been looking at lately that are, in fact, providing value to an SOA environment. I thought I would mention one company that I think offered some interesting value for SOA implementations.

Redwood Software

I met Redwood Software recently at SAP’s TechEd conference. The company has been around since 1993 and was focused on providing job scheduling. Over time the company, which now employees 185 people, has leveraged its technology to provide provisioning of resources in real-time. It has become an important partner with SAP which now OEMs its technology since SAP itself does not provide its own scheduling. What I found very interesting about Redwood is that the company has evolved to support a Service Oriented Architecture. The product is designed so that it can grab infrastructure information and business events and provide the instructions as to how these events should be executed at the hardware level. The architecture is designed to be independent of underlying middleware. Therefore it can work as easily with IBM WebSphere as it does with SAP’s Netweaver. From an SOA perspective, this environment hits a key pain point. If you are creating a composite application that needs to pass information across systems of record it is important to be able to schedule the sequence based on events such as policy, date, or even time of day. Redwood addresses this issue.

When systems don’t work: a lesson in just-in-time?

Yesterday I was traveling back from an industry event where I was speaking about the importance of manageability. Ironically, I got a lesson on what happens when systems are not managed well. My trip from Las Vegas to Boston should have taken me about six hours. Unfortunately, the trip took me close to ten hours. First, radar in Boston’s Logan airport wasn’t working quite right (not a comforting thought when one is above the clouds). After finally landing safely, there was no crew to unload baggage (since the plane was late – that process broke down). To add insult to injury, the line for cabs meant another half-hour delay (not many planes are supposed to land in Boston after mid-night); and finally, road work was in full swing (not many cars are supposed to be driving around at 2:00 in the morning) so that my cab was detoured across the whole city of Boston. What is my point (other than to complain)? Quite simply, business process was at the heart of my problem getting home – even though all the systems for a successful trip were in place. There was a business process for each component of the travel system. However, there was no acknowledgement that there are dependencies and context across components of systems. Maybe there is a lesson here for service oriented architectures and just-in-time systems that are often not on time.