This is a very meaningful year for me, because I turn 45 in June.  A long time ago, I decided if someone didn’t call me up to join their team by the time I was 45, I’d give up my expectation of being a Major League baseball player.  I figure if Nolan Ryan can’t make it past that age, neither can I.  So I no longer can afford to futz around in different “temp” jobs while I wait for the call to come.   It’s time for me to choose my career path.  I feel like my nephew who is a freshman at Notre Dame when he was asked to declare a major.  They wouldn’t take coeds and beer as an answer and neither will my wife.

So what do I want to do now that I have to put my dreams behind me and get serious?  I’ll put aside the obvious choices, like sitting around and waiting for someone to ask me to star in a major motion picture or to become the benevolent dictator of a small island nation.  Good choices, which were always my Plans B and C.  But now that Plan A hasn’t worked out, my confidence is slightly eroded that these back-up plans will come to fruition as well.  Regrettably, I now feel that pursuing my career might require a little more proactive effort on my part. 

What I’d like to do is participate in some meaningful way in the Next Big Thing (NBT).  So I’m searching for the NBT.  In the past, perhaps because I wasn’t actively looking for it, I’ve generally sensed the NBT at one level or another at least in the networking arena.  LANs and client/server software to enable shared printers and files always made a lot of sense to me.  Running LAN protocols over building wiring was technically challenging but the value was intuitively obvious.  Extending kicking and screaming LAN OS protocols to create global wide-area networks via multi-protocol routing and other trickery always seemed like a very important goal.  Creating unified WAN interface standards like Frame Relay to prevent every business from having to build their own private WAN was clearly useful even before the term Frame Relay was first coined.  Making LAN protocols faster and converting them from shared media implementations to switched ones was a no-brainer.  Creating portable software language standards so the applications could be developed on one environment and then easily ported to others was of huge importance.  I’m not saying I had the insight to conceptualize or invent any of these things – just that when I became aware of them my immediate reaction was “this is going to be big” and I found a way to get involved in all of these trends at one level or another.   

But now that I really need a NBT to fill in the gap of my aborted baseball career, where is it?  I don’t see anything right now in my comfort zone – networking – that evokes the reaction in me that past NBTs have.  There are a lot of useful things going on in the areas of security, wireless LANs, storage networking, web site architecture, and metro area networking, to name a few, but most of these things seem to me to be useful tuning – better performance, reliability, and manageability of things that have existed for years – than of fundamental or disruptive importance, which I think is a criteria for a NBT. 

It seems there has been so much innovation in networking over the past couple of decades that the world is taking a pause that refreshes to give ourselves time to catch up and fully digest what is already out there.  However, the relative stability in networking, which is a NBT suppressor in that space, may allow more innovation to occur at higher levels because such innovation can be rooted on a more stable foundation. 

This leads me to an area that may well be the NBT – Web Services. 

 I’ve been hearing the term Web Services for a couple of years now. I have to admit that until recently I didn’t pay it that much attention and therefore developed very inaccurate assumptions about what it meant.  At first I assumed Web Services represented an outsourcing option that lazy arachnids could leverage to have food-catching lattices built for them.  But then when I kept hearing the term more often in the context of IT discussions rather than on Crocodile Hunter, I figured I must be wrong.  So I then assumed Web Services was another terms for ASPs, providing the ability for enterprises to access applications in a time sharing manner over the Internet.  It turns out I was getting closer here, but I was still rather far off base. 

Rather than continuing to guess what Web Services meant, I decided to go to an expert – Barbara Angius Saxby of Acuitive.  Barbara has talked to a lot of people involved in and around the Web Services space and more importantly she has worked directly with several vendors to help them forge their roadmaps and positioning vis-à-vis Web Services.  She was able to explain to me in layman’s terms what Web Services are, or might become, and what they are not.  Her patient tutoring was so compelling; I asked her to capture the key points and publish a White Paper titled “Web Services:  A Floor Wax Or Dessert Topping?” which is now available on the Acuitive web site at http://www.acuitive.com/rr.html

The title of the White Paper gets at one of the biggest hurdles Web Services has – functional and definitional clarity.  Depending on what angle you look at it, and what your subconscious desires are, Web Services can be seen to be almost anything you want them be.  What I got out of the White Paper was not so much what Web Services are, but what they are not.   

Web Services are not a bright and shiny new thing.  Instead, Web Service is the term coined for the latest group of technology developments in a continuum of developments that have gone on for years and will continue to do so long after the term is out of vogue.  TCP begat HTTP which begat XML which begat SOAP/UDDI.  C begat C++ which begat Corba which begat Java.  All along, and in fact all the way back to when I learned to program in Fortran in college, software architects have promoted the use of “services” in the sense of one steaming pile of code providing useful functionality that can be called on by another steaming pile of software when needed, be it in the form of a subroutine (Hoover’s day) or a business logic applet (modern day).  This is the software developer’s view of the term ‘service.’  Because of this continual and gradual evolution of how software services are grouped, reused, and called into play, it’s kind of hard to figure out just when Web Services came into being.  They are built on a rich genealogy of previous generation’s hot concepts for software sharing and re-use. Other than web-ification to create greater connectivity, what is fundamentally new here compared to the function calls, libraries and object models of the recent past, including yesterday’s bright and shiny data structure model – XML?  Instead of peeling the onion we are adding layers.  Web Services are simply the latest set of interface and function definitions required to create the next level of portable, distributed, networked, and brokered application functionality – but over a unified network (the web) – which makes all the difference.   

By my working definition of the term “Market Segment” – a group of customers with common needs and similar views on how to address them – Web Services are also not a market segment.  Web Services technologies and standards, and applications enabled by them may become ubiquitous.  But ubiquitous technologies do not make for markets.  Other than some specific development, test, and infrastructure products, there is no TCP market or HTTP market or SSL market or Java market or C++ market or XML market per se.  These are generally either ‘under-the-hood’ or ‘table-stakes’ technologies.  The products that use or add value to these technologies can address widely varying market segments, depending on the value proposition and target customer set for each such product.  Web Services will be the same.  Don’t confuse the technology and all the related standards and pseudo-standards with the opportunities related to them.  I expect there will be very few successful companies who are known as ‘Web Services’ companies, and there will be very few product SKUs that are specifically Web Services widgets.  But there will be many successful products and companies generated by those who can envision how to leverage Web Services to improve how we do things today, or even better to enable us to do things we can’t do today, just as there were with C++ and Java. 

All in all, I don’t think Web Services will be the NBT that I latch onto.  While there will probably be lots of opportunities enabled by Web Services, like doing Enterprise Application Integration or Supply Chain Management or Customer Relationship Management better, the key here will be understanding the application user requirements and then leveraging Web Services and other methods to nail those requirements in a differentiated manner.  In other words, you need to be an expert in the application space first and the technology second.  And I am neither. 

But Barbara is and she will continue to expand Acuitive’s footprint in this space, continually asking the question “If you build it, will they come?”  In the meantime, I need to keep searching for my own personal NBT.