In this column, we look at a few of these innovations in technology, explore their value and benefit and then use them, as a way to understand the inherent obstacles to adoption.

Let’s start with SOA (Service Oriented Architecture). Here is a term we have all been batting about for a few years. This seems to hold promise for the universe of end-users and technologists, alike.  In this scenario, people can share their code modules, reducing the amount of  redundant code development, and subsequently freeing up the software community to move on to newer problems to solve, as well as significantly reducing development costs. In addition, its promise is also cross-platform access to these code libraries and data, making them available as a ‘service’ to all who can gain access. Sounds spectacular!

So, what is SOA?

Service? First, envision a house construction site. If you were the prime contractor, rather than owning all the tools, custom building materials or the parts, etc., you might hire a collection of subcontractors. Each subcontractor will have specific services and functions: plumbing, foundation, creation, framing, electrical, or finishing. Your master site plans would show the workflow, connect points and standards by which you were to build this house. The location municipality would provide a permit, as well as indicate what building codes (standards) you would have to follow, as well as to ensure that you met those local edicts. Then your neighbors would think of you as a welcome addition to their hamlet. (Master Data Management*)

The contactor for this federation of players has lots of advantages. As contractor, I don’t have to know how to do all these jobs or own all the tools etc. But I have to have a seamless way to get everyone working together. (Middleware)

If you were smart enough, you could build your entire house yourself, reducing all the coordination and communications it would take to do this.  That is the kind of trade-off that people could make, but not that much any more. In modern times, we neither have the time, nor the skills.

More handoffs—lots more handouts—but hopefully done in a very professional standard way. Once I learn the business of general contractor, I get pretty good at this and it opens the door to potentially getting lots more done.

I also need a good vendor list (like a card catalogue in the library) of what is out there: material, subcontractor directory, capital. Like SOA, there are many types of services I can access: data constructs, code, data, etc. and then I must put together a series of these to complete the process. 

Now the analogy leaves us, since with software, accessible by many people, the libraries are reusable. The digital world is not scalable. 

Our public library analogy works here since the card catalogue (Directory) has to have an adequate description of what is in that publication so that I can determine if I want to "take that out of the library.”  There are terms for my use, of course. Am I a member (certificates)? Do I have authority?

So, there are some pretty obvious benefits to all this:

• Long term cost reductions in development costs
• Cross platform integration
• Standards adherence (we are all using the same "rules” with some level of assurance, since the actual "code" is being used by everyone {concept in EPCIS, for example} ).

Given that the library was in place, your time to implement of, say, new business processes, would be extremely fast.  You call your service providers to hook up a few more connections and services and put it all together with the proper process and procedures (work flow or Business Process Management).

So, when we have this all in place, like moving into a new neighborhood and getting a phone service, or water hookup, it could be fairly straightforward.

BEA is a company that has put a lot of effort into creating the types of tools that would allow you to create these environments. You need tools for Master Data Management,* work flow (Business Process Management), Middleware and Security (see more on this in Inhibitors and Catalysts to Adoption ).

INFOR also has a big investment in all of this. They need to entice their customers in an attractive way into the new world.  Their commitment seems genuine.  

Other ERP vendors are also working on clever middleware, like NetWeaver and xApps. But there is one thing we must be clear about here. SOA is not a tool for putting a wrapper on your old code with nifty middleware.  That’s OK to reduce spaghetti code from one application to another, but it is not SOA.  In SOA the rules are no longer buried in the code, but externalized for many services to share.

But like all things we are to share, governance needs to apply here, too. Policy on approach and access needs to apply here, as well. Where do rules of the business reside in the future?  In the olden times (until today) it’s mostly in the complex code. SOA separates out flow from data, documents, and permissions.

Many firms that started out as e companies or cross-enterprise solutions have migrated to become platforms.  Salesforce.com is no longer for sales people, but has services in industry sectors like Financial Services.

For technology firms and end-users, the Journey will not be that fast. The commitment is not a trite phase, but a long-term strategy over many years to get to this newer place.

There is the need for a real education, as well as some changes in the work model of IT. How people share in the work environment sometimes is limited to the football pool. But one benefit that appears from SOA is that we don’t need to get into the mind of the code,  just what the service needs and what it will provide, like the drive-through teller. 

This all of course has been an evolution from the Data Management, Objective Oriented and web thought process. It won’t be the last word on technology approaches. But it is the smartest at this time.

Now on top of these libraries of data constructs, data and code, an end-user would want to interact directly, potentially creating their own queries as an access. This paradigm is also familiar to spreadsheet and report query users.

The Holy Grail, though, is having a coding language that is more like our spoken language. Our Natural Language.

What is Natural Language?

Natural Language is an approach to code that allows the end-user (or programmer) to create code using ordinary linguistics phrases, like "find all the people in Manchester who like Mick Jagger."  Natural language takes the language constructs and categories and then converts these through, say, XML code to construct a fairly standard program.

An interesting company we recently spoke to is Linguistics Agent, who has several patented and clever approaches.

Now, why all this matters.

If you were a huge software company with lots of customers over a thirty-year span, scattered across the world, those customers would be on a variety of platforms and languages (Fortran, Cobol, C, XML). Then you would have to deal with supporting all those customers, and tying in with every enticement you could to get them to move to the most up-to-date software. You want them (the customers) all on the same platforms because it is easier (i.e., cheaper) to support them.

But migration of software is a lot like transferring ships in mid ocean. You can see the other ship, but it’s a bit risky getting over there.

SOA provides an evolutionary path from one world to the other. For example, across the bridge you see some excellent new functionality, services, that you want. You can begin using these services to augment the current environments. If you actively continue to build and/or utilize more and more of these services, at some point you reach the tipping point, where it just makes sense to retire the old stuff.

If you are a firm with many mergers and also lots of legacy code, this path should also be appealing.

Today, the whole world is full of open libraries of code you might want to use. And as the world goes On Demand, you want to be able to bridge between the services you will find on the web and your local platforms.

If this is all so wonderful, why aren’t we already there?

I am not old enough to have lived through the establishment of the national telephone systems.  But as we all know, it took a really long time to roll out the infrastructure so that businesses and family could just plug into the shared system.

In the same way, the critical mass in the Service World is not there yet. Nor, state side, the ubiquitous high performance internet, so that we could truly rely on this clever mapping of services and workflow to create new automated processes On Demand.  Some countries are way ahead, like Japan, and some locales in Europa, so that they are able to rely on high performance with the feel of access right in our hamlet.

Tipping point analogs apply here.  Evolution, Not Revolution.

These issues apply to so many evolutions, on to new and better solutions:

• People: Understanding the real needs of Services so they can develop modules that are accessible and usable according to the ideal
• Polices and Standards of use
• Security: But in a way that does not impede performance
• Enablers of critical mass. And there are many available services and associations that both business and the global world of Free Agents can access and use. But most important, we need a web here in the States that performs!

These concepts can be implemented on or within your enterprise, but within your hamlet you might not see all the wonderful things that are available for you in the global village.