by Mark C. Fralick

I have had two big revelations as of late.  The first is that there has to be a shelf-life for the term “The Thing of the Future”.  The second is that I am a software architecture bigot – but I may be recovering.  Read on…

How long does something get to be The Thing of the future before it must either give up the moniker or have it forcibly seized by the next great thing?  At a recent visit to a waterpark I noted that Dippin’ Dots™ is still the “Ice Cream of the Future”.   Seriously?  Dippin’ Dots™ has been around for over 15 years.  While they are wonderfully delicious - that is a long time to be the 'thing' of the future.   It got me thinking.  Is Services Oriented Architecture (SOA) is the Dippin Dots™ of the software world – perpetually the thing of the future.   Even today when I talk about software architecture  – I hear things like “Yes, we are looking into that”, or “we are looking doing something with SOA in the next project” (personally betting that statement has been uttered by that same person for years).   I am continually amazed at the slow pace of adoption by IT groups.  “A well designed SOA approach”, I preach, “breaks you from the boundaries of the application.  It creates unlimited potential for problem solving.”  All true, but here is the rub.  Who’s got the time? Who’ got the expertise?  IT staffs have about a million things to do; adopting a whole new philosophical approach does not often breach the conversation, let alone the priority list.

It seems to me that there are two real ways a philosophic turn like this happens: by edict or by evolution.  There is a set of CIO level execs out there that will look at all of the integration challenges ahead of them (for example) and not just see a ton of work, but also see an opportunity for something better; something that turns them into IT superheroes – with the ability to take on any comers.  These guys and gals will lay down an edict (or a challenge) that will potentially move an entire organization to SOA.  For these groups, the will need to look at every new problem in the context of an SOA solution.

All of that sounds exciting!  But in my estimation, there are many more IT groups gradually led toward SOA by newly acquired or upgraded software that, itself, is SOA based.   Or, they have made a more tactical integration choice, perhaps services-based, that leads them in this direction.  As a group, they attempt to evolve to this.  Not to say that there is a lack of vision or thought – more likely a total lack of time to address this.  In any case, what happens in this case is the development of pockets of SOA adoption in the organization and spotty expertise.   The movement, therefore, comes in fits and starts.   SOA is something ‘that’ group is doing that ‘we’ may do at some point. Movement to SOA in this fashion typically yields fragmented adoption and disparate implements.  This is one of the things that prompted me to give up my evangelistic notions when it comes to SOA. 

This leads me to the realization that, all these years, I’ve been a software bigot.  Look, the technology world is full of bigots; server bigots, platform bigots, mobile device bigots, development bigots, I’ve even known compiler bigots.  I had always thought of myself above the petty bigotry of implementation choices.  I would say “I don’t care how the service is implemented as long as it adheres to its interface and functional contracts.”  In my mind I was above the bigotry.  But I have realized that my bigotry comes from thinking that if you weren’t doing SOA, you were somehow following a shallow, inane path.  I’ve been critical, for example, of things like Ruby because of the two-tiered nature of most of the implementations I’ve seen.   I was wrong.  I fully admit it! Why am I repenting?   Sometimes, arguably many times, as software architects we get preoccupied with what is best for the developer or best for the system, and lose sight of what is best for the organization.

In this era of hyper-competitive markets the winning organizations will be the ones most nimble.  Therefore, the best system approach for an organization needs to be the one that creates the most nimble systems.  This sort of need for nimble shouldn’t be confused with so-called Agile Development.  Agile Development is a process – Nimble is an outcome.   Agile Development speaks to solving the developer’s problem, it is an improvement in the process, but it is not necessarily an outcome.   It is entirely possible, for example, that someone creating a system with an agile process creates a system not very agile (nimble) at all.

While I believe SOA can be the cornerstone for the development of nimble systems, I will be the first to admit that it is entirely possible to develop large, monolithic, and immutable systems with SOA.  If Nimble is the goal - then the discussion has to change.  It becomes more than a tools, processes, frameworks, and technologies.  I becomes about the coordination and integration of the resulting system.  But, how do we get there?  How do we even set it as a goal we can effectively communicate to others?

Here are some first steps toward nimble:

1. Enterprise Architects need a new goal.  Like my revelation about SOA not really being the goal, we need to think about Nimble as the goal.  We must have a Need for Nimble; and not for the developers, but for the organization.  Unfortunately, this is a difficult target and puts the architects in positions outside their comfort zones.  Going to the head of distribution, for example, and saying “What do you need to be where you want to be in a year, and let us do our part to help you get there,” is a difficult conversation to imagine for some enterprise architects.

2. Recognize that as you get closer to the moving parts of the organization, the more flexibility your systems require.   Execution systems on the floor of a warehouse, for example, often require a high degree of flexibility; certainly more than systems in the back office.  Likewise, those in the back office often require more flexibility than those in the corporate enterprise system offices.  What will this mean?  This will require you to allow, or even encourage, groups that are closer to the ‘street’ more flexibility regarding how they service their customers.   Supporting an effort, for example, one of your groups has undertaken to support its operational customers with some very easy to create and modify Ruby systems, would become fair game.

3. The Priority needs to shift to the development of an effective integration backbone across the organization.  Since nimble organizations may implement disparate systems to best solve problems, standardization moves away from choices of implementation and toward choices of integration.  One could very easily envisage an SOA/SOAP, for example, based backbone for doing this sort of thing and removing the historic requirements of detailed implementation knowledge from integration points.

My Favoite Nimble System

When you have one of these very nimble systems in your hands as an implementer, you can be a real superhero.  My Favorite Nimble System is the Dlx Warehouse and Distribution System from RedPrairie.  This system was constructed entirely from scratch to be nimble.   Beyond just being services based, it permits services to be scripted together to create a sort of Service Macro. I like to call their approach Services Oriented Scripting.  Someone with even meager technical abilities can create service scripts in minutes.   Not only do these new services handle morphing the transactional boundaries automatically, but they are accessed in exactly the same manner as off-the-shelf services – so may be used in the client work flows very easily.  Additionally, a namespace hierarchy permits these new services or service overrides to survived upgrades.   These sorts of execution systems are some of the closest to the street and often require the most flexibility in order to support operational requirements.  They, in fact, have the most need for nimble of just about any system in an organization.  We are excited when our customers choose a system like this.  As these systems are often the last step between an order and revenue, they have the double-whammy of being some of the most critical systems in the organization, and the ones requiring the most flexibility.  RedPrairie’s architecture goes a long way to allowing organizations using nimble as a weapon against their competitors.  In any match between to equally strong competitors, I’d always put my money on the one more nimble.  Wouldn’t you?

Dippin' Dots is a registered trademark of Dippin’ Dots, Inc. Dippin’ Dots is a wonderful frozen dairy treat and not related to this article
in any way other than a recent observation related to one of their slogans. I, personally, am quite partial to the Strawberry Cheesecake flavor.
If you have not tried Dippin' Dots – you should! If you, likewise, have not tried SOA - you should. You will find it cool and refreshing.