As we wrap up Thanksgiving Day (in the United States) and head into the greater part of the winter holiday season, our thoughts inevitably turn to an evaluation of the year gone by and goals for improvement in the year ahead. Some of us may even promise to exercise more, eat more healthfully, and take care of our personal lives better, and we may indeed keep those promises. But at ZapThink we would like you to commit to a New Year's resolution we know you can keep: improve your service-oriented architecture (SOA) skills by rethinking your SOA training strategy.
ZapThink is fond of saying that "SOA is something you do, not something you buy." Yet many so-called architects short-cut the step of actually doing architecture by hoping to buy their way to SOA. By now, we don't have to tell you that you won't get SOA by simply accumulating a set of SOA infrastructure products, development tools, or services from enterprise application products. You know that architecture is a discipline and set of activities that affect not just the technology, but also the organization, governance, and processes of the business. Yet, while you might know all that implicitly, your actions belie your beliefs. Even after buying those tools, many resort to learning SOA by simply learning how to use the tools they've purchased. This approach to learning how to do SOA simply won't work. Doing SOA right means learning how to do SOA – not just how to implement a vendor's SOA infrastructure products.
In order to make progress on SOA in 2009, you should look at how you're gaining SOA expertise. Have you thought about how you are learning to do SOA? And how to do it right? Have you thought about who you are getting that education from and what are their motivations? Is it possible you're paying for SOA training but just getting product-specific implementation and developer-level training? After all that training are you still scratching your head wondering how (or if) you've done it right? If so, you need to rethink how you acquire the critical skills necessary to make SOA a critical success.
The problem with vendor-specific architecture education
Architecture is not development. Assembling a bunch of services does not yield an SOA. Perhaps you already know that. But what about your training and skills development efforts reinforce those beliefs? In order to separate the activities of architecture from development, you need to learn the methods, practices, disciplines, and approaches of architecture. Architectural training focuses on acquiring expertise on how to actually do the various activities of architecture. This means that at the end of a given training activity, you should be able to use any tool or SOA infrastructure product to design a service, implement a service model, run effective governance, quality, and management (GQM), manage a service domain, implement a SOA test plan, among other activities. Yes, it is true that to actually build and run those services you will need more training to learn how those tools work, but if you don't have expertise in the abovementioned fundamentals, how do you ever stand a chance?
To further reinforce the "learn methods before learning tools" best practice, it should be said that learning SOA is not simply a matter of learning how to use tools. To use an analogy, don't confuse knowing how to use a cake mixer with knowing how to bake a cake. Anybody with a few minutes can learn how a cake mixer works and what its various settings are, but learning how to bake a cake takes time and experience to master.
So where does the "tools before methods" sub-optimal style of training come from? Many SOA infrastructure and development tool vendors offer SOA training as part of their offerings, and many end-users opt for the path of least resistance (or cost) and get their training from these vendors. While a handful of these vendors put some effort into incorporating vendor-neutral, industry-wide best practices and methodologies into their training curricula, most of these vendors simply see SOA training as a means to selfish ends. Some notable SOA vendors have admitted to us that they see SOA training as "loss leaders" to sell other things such as software or services. From this perspective, they offer training at greatly reduced prices or even free as a way of qualifying the customer to buy more stuff. It's sort of like those "exclusive passes" you get to distributor showrooms to demonstrate something when all you've done is volunteered yourself for a multi-day sales pitch on their offerings. Are you doing yourself any service by skim-coating your SOA activities with a smattering of SOA methodologies know-how while diving deep into implementation details of SOA Vendor Product version 3.2? We at ZapThink think not.
Other SOA vendors have admitted to us that they see training as part of their customer support efforts. These vendors see training as a way of helping customers use their products. In these cases, the training is not meant to actually enable organizations to fill in the missing gaps in their SOA skills, but rather to maximize customer satisfaction with products already purchased. End users that see training as an aspect of support should prepare themselves for the need to always play catch-up. No thought-leading organization would relegate training in such a manner.
Lest you think that software vendors are alone with such training practices, we can assure you that we've seen SOA consulting firms of all sizes likewise approach training as a pre-sales consulting add-on or as a checklist item in an RFP delivery. ZapThink recently provided training for an organization that had previously brought in a well-known SOA consultancy to provide SOA training. The customer's complaint was that the consultant knew the material in the course, but any time someone had a question that wasn't specifically about the material, the answer was "I'll have to get back to you on that." This is simply unacceptable. SOA trainers need to be architects and SOA experts. Any schmoe can read slides and fuddle their way through SOA exercises, but actually gaining expertise in how to do SOA right requires learning from someone who has both experience in the space as well as knowledge on SOA skills development. This requires a breadth of experience that goes beyond the material itself.
If the self-serving sales and support focus wasn't enough, what makes this consultant/vendor-driven SOA training particularly problematic is that many such training courses masquerade proprietary vendor or consultant methods as industry best practices. Vendors and consultants often develop courses around a methodology they developed for a customer. This content then makes its way into training curricula without any third-party vetting of those practices or even an understanding of other practices in the space with which to compare. Smart architects should press these trainers to explain how their approaches compare to others in the space and explain what about their practices are indeed "best". Furthermore, IT managers should demand that SOA training curriculum be vetted by credible third-parties to ensure that they are not simply getting indoctrinated into proprietary approaches that promote single-vendor or single-consultant lock-in. You deserve pragmatic SOA training, not dogmatic SOA training.
The ZapThink take
If you haven't already noticed, ZapThink has a bone to pick with much of the so-called SOA training currently offered in the market. Certainly there is a role for vendor-specific training, and the best source for such product-specific or consultant-proprietary offerings is the firms themselves that developed those tools and approaches. However, those that are serious about developing SOA skills need to beware the training version of Vendor-Driven Architecture (VDA). Just as you should only buy tools once you have determined your architecture and not vice-versa, you should buy vendor-specific training only once you have already mastered the fundamentals of architecture that are necessary to implement any vendor or consultant's offerings well.
Architects should also understand that the Return on Investment (ROI) for training and skills enhancement far outweighs that of tools purchases or consulting engagements. While a good SOA tool can return up to 200% of value over the investment, good training returns tens of thousands of percentage points of value. A single four-day course of the type we recommend above can cost as little as $2,000, but yield hundreds of thousands of dollars of returned value in accelerated SOA initiatives, higher overall project quality, reduced waste in development and tool purchasing, and better overall alignment of the SOA activities with business requirements. Investing in tools is a capital expense that is amortized across multiple SOA projects. Investing in skills development is an operational expense that yields persistent returns throughout the lifetime of the human resource. Furthermore, while the ROI of tools investments are perishable, the ROI of training and skills enhancements are permanent. Vendor training is highly perishable since as soon as the tools change, your product-specific training becomes obsolete. Whereas methodology training is highly durable – even as methodologies evolve, they simply improve on what's been done before or just add more capabilities.
At the end of the day, who is in charge of your architecture? You! You control the evolution of your architecture, so you should be in control of your education. ZapThink has a vested interested in the growth of SOA as a credible and valuable discipline. And this requires that we rethink our approach to training. Put this in your resolution list for 2009.
