Monthly Archives: May 2009

I saw an [url=http://soa.sys-con.com/node/980029 new=true]announcement[/url] this morning by WSO2 that they are offering free SOA Training this summer; this triggered my “uh-oh” senses. I'm sure that WSO2 means well, but I've noticed a trend in my conversations with individuals who have a predominantly been trained by “SOA Vendors” to focus too heavily on the implementation design factors and focus too little, or not at all, on a top-down approach. To me, this makes perfect sense, because, and I know this is a contentious statement, architecture cannot be taught to the masses.

The results of bottom-up engagements, which are labeled as SOA, are faster delivery, increased reuse and lower development costs—all good things. However, these solutions are constrained by their limited aperture, which results in too narrow of a focus and misses capturing the necessary domain knowledge in to the architectural model—the key promise of SOA—that will provide the aforementioned benefits horizontally, not just vertically in a single business domain.

Hence, the business leaders are disillusioned. It's not that they don't see the benefits to software development, but because they still don't have a solution that enables them to execute in “business time”. Without leading with a top-down design, the necessary subject matter expertise, and subsequent service model, to enable rapid delivery of a large, complex, enterprise-wide business processes is missing. The outcome of this latter point is that as the business tries to reposition with market changes, in the eyes of the business, IT still cannot keep up and all the talk of the benefits of SOA is diminished. Thus, SOA is yet another instance of “all talk, no action.”

But, let's not lay all the blame at the feet of vendors offering training on a skill that is not designed to be learned in a classroom over five days, but is a craft that needs to be honed over years working with talented craftsmen. Part of the blame need to be placed back on the business for believing they can get something for nothing. Much of the business community does not respect the value of architecture, is too focused on tactical wins and allows themselves to believe that they can create an army of low cost programmers, send them to a vendor-led SOA class and have them churn out projects that can meet anything more than a small community of interest's needs.

Of note, I lay a lot of this blame on middle management that has never learned to have critical conversations with their executives. I believe most senior executives are strategic thinkers, which is how they achieved their current position. However, middle managers are not trained to manage the expectations of their executives, and thus, believe if they don't show constant momentum, they will be deemed incapable of delivery and relieved of their duties.

Well, you cannot show current momentum if you've bought into the promise of enterprise and service oriented architectures—you've bought into the promise that strategic modeling of the organization will ensure that the real business needs are met in a way that drives agility and allows the business to keep up with market demands. Middle managers that learn how to manage the expectations of senior management through this process will win in a way that will surely position them for growth.

So, while its been a long and winding path to the answer—subsequently, a path that truly shows how everything is connected to everything—the answer is that vendor-led SOA training is not a good idea. Vendors have a mission, which is to sell software. To them SOA is something you build, not something you design. Hence, the focus from the gitgo is a failure and will lead to continuous disillusionment.

If the goal for the organization is to develop software faster, cheaper and with more quality using CMMI-like processes, then many of these vendors will help you achieve your mission and be successful. However, do not believe for a second that what your programmers and engineers learn in these classes will help at all achieve the mission of service oriented architecture, because, architecture cannot be learned in a classroom in five days; only architectural principles can, which are like sharp knives in the hands of babies if not properly directed.

I’m currently reading “ Influencers”, in which the authors make a great point that with innovation, the messenger is as important as the message. There’s a story of a researcher who attempts to get farmers to use a more disease resistant strain of corn, but the farmers don’t view this person as experienced and don’t want to risk their crop. So, the researcher sets out to find that one person who will try the new strain of corn, thereby, setting an example for all the other farmers. So, the researcher finds this farmer that dresses in Bermuda shorts and drives a Cadillac, who is open to innovative farming techniques and who successfully uses the new strain of corn to grow a bumper crop.

At this point, most of us “engineer” types are thinking, “great, now all the other farmers have an example of it working and will feel more comfortable using the new corn.” I know I will raise my hand with regard to being in this camp, but I got schooled in a big way. I know that when I was out there acting in a business development / sales role for software companies, this was a critical factor for success. Moreover, in certain industries, such as finance, this approach works great.

However, we in IT often focus so heavily on the successful early adopters, that we forget about the majority of middle-roaders and laggards. Why are they middle-roaders and laggards? Well, as it turns out, when it comes to innovation, adoption is sometimes more limited by who adopts first than the fact that it was adopted and worked successfully. Middle-roaders and laggards weigh certain, maybe less visionary and less well-advised, opinions more heavily than the data they can view with their own eyes.

I’ve noticed this phenomenon, but didn’t have a full understanding of the processes that were occurring. Especially with regard to SOA, I remember in the early days being concerned that ITs early adoption of the concept might chase away the business before they had an opportunity to digest the value to them. Sure enough, I believe this is exactly what has been occurring. A concept that was supposed to bring IT/Business together has once again ended up having too heavy focus on IT and the business is now rejecting.

This brings us back to our Bermuda-shorts-wearing-Cadillac-driving farmer. As it turns out the other farmers did not respect this farmer because he was different and because he didn’t think and do things the same way they would. Hence, they rejected the cold, hard data that his crop surpassed them and, as some might say, “bit their nose to spite their face.”

When it comes to SOA, isn’t the Business a bit like the other farmers? If IT wants to succeed at leveraging the power of innovation, whether its Cloud Computing, SOA, Enterprise Architecture, etc. they’re going to have to stop “geeking out” and taking dominance over these creations and allow the influencer groups that the Business listens to take the lead and promote the value of these new innovations.