Let's begin at the end. It's a few years down the road, and Web Services have succeeded beyond all but the wildest evangelist's dreams. Bandwidth is infinite, storage costs a penny per gigabyte, and Quake (with user-configurable music and avatars, of course) is a cell-phone app. AOL and Microsoft own the consumer Internet like Coke and Pepsi own cola.
In business, software is a mesh of self-describing services communicating via XML-based messages. Standard vocabularies exist for every common human endeavor, and most of the uncommon ones as well, with the implication that software development takes place on a very high baseline of assumptions and embedded functions. Establishing that baseline used to preoccupy teams of programmers for months. No longer.
To write an "application" -- though no one would use that quaint term in these modern times -- a business analyst drags lines between blocks that represent business functions, things like ebXML-based contract negotiation and supply chain disruption management. These blocks are themselves composed of finer-grained services, many written by high school kids and available for free. The analyst, who might as easily be working on a smart phone as a desktop, uses her business knowledge to set parameters that tailor the generic services to the problem at hand. Reuse is a reality; very little software is written at the code level.
Does this scenario depict a utopia or nightmare for today's IT professional? One doesn't have to give a definitive answer to realize that the success of today's major IT initiatives -- ubiquitious connection, near-limitless resources, tinker-toy software assembly -- are radically changing the profession.
Just as the invention of the automobile did for makers of horse-drawn carriages, the shift from traditional application development to software assembly is challenging assumptions about how people add value. Whether you suffer or prosper as a result will depend on how you adapt to the coming storm. Here are couple of broad trends you need to reckon with.
Current Career Models Gutted
There are many ways to earn a living in software today, most of which have to do with managing the inefficencies associated with code. A successful services architecture is all about handling these inefficiencies behind the scenes, and will therefore gut many career models. Basic programming and website design will dry up as meaningful skills, for instance.
Two high-value paths will remain, one deeply technical, the other broadly analytic. This isn't so much a far-fetched prediction as a stated agenda for Java and other distributed computing paradigms.
According to the book J2EE Technology in Practice, edited by Rick Catell and Jim Inscore of Sun Microsystems (Addison-Wesley, 2001), one of the fundamental design goals of Enterprise Java is to "commoditize expertise." In order to add value, technical experts will require an under-the-hood appreciation of software tools and systems in order to ensure the robustness and scalability of discrete Web Services.
That means experts in Web Services design will need to focus not only on qualities that make the application itself work, such as performance and transaction integrity, but also on design features like granularity and parameterization, to ensure that the services can be adapted by non-programmers to new environments.
Expertise of a different type will be required to assemble granular Web Services into powerful systems of business automation. Business architects will use technologies descended from today's Unified Modeling Language (UML) to model their organizations and knit together systems that expedite both internal and partner processes.
According to Sun's Catell and Inscore, companies will increasingly "focus on recruiting developers based on their understanding of the business needs of the orgnization, not just their ability to solve arcane technical problems." Indeed, an organization's ability to analyze its markets and execute in terms of reconfigurable software services will become one of its most agile and potent differentiators.
Technical or Analytic Track?
If the technical track appeals to you, it's time to get serious about software. Study the mechanics of garbage-collected, object-oriented programming languages such as Java and C#. Study design patterns. Learn about two-phase commit and transaction services in J2EE and .NET. Research CORBA to understand the conceptual foundation for platform-neutral system interoperability. Becoming conversant in these technologies will have much higher value in the long run than learning the latest programming language.
If the analytic track is your cup of tea, study modeling, specifically UML and XML Schemas. Design patterns are useful here as well, while the emerging field of analysis patterns holds promise. Investigate, and if possible participate, in your industry's XML standardization initiatives. Most importantly, begin to think about what it would mean to model your business' marketplace, stakeholders, and processes in terms of a software services architecture. Don't look for a shelf full of books on the topic -- they haven't been written yet.
If neither hard-core technology nor business architecture suits your profile, don't despair. There will be a growing demand for support specialists, especially in the areas of security, database administration, network management, and legacy integration. But commoditization of skills will be hard at work here, too, so delve deep and seek out challenging projects.
Gordon Benett is a technology strategist with over 16 years of experience with information systems. He is a senior research analyst with Aberdeen Group, where he follows the Enterprise Java and Middleware markets. In 1996 he founded Intranet Journal, an internet.com site, where this story first appeared.