SOA Anthropologist
My colleague Ed Vazquez (Ed you need to start blogging and I) came up with a new role associated with SOA Adoption. It’s the SOA anthropologist. There is no shorting of pundits out there that feel that the most difficult aspect of SOA is the cultural change. I tend to agree. If you look at the average enterprise, they probably have 20 or more years of history of building stovepipe applications of various sorts. This doesn’t bode well for SOA. From top to bottom, there is baggage that exists that must be changed, ranging from project definition and funding models, to the project manager who is dependent on services and teams outside of their area of control, to the analyst and developer that must define and produce solutions that have the potential to be combined in a flexible and efficient manner in the future. It’s like taking a rugby team, putting some helmets and shoulder pads on them and saying, “go play football!” Some things look vaguely familiar, but in reality, they’ve got their work cut out for them.
A field that is slowly gaining some prominence, at least in very large enterprises, is corporate anthropology. Corporate anthropology is about understanding behavior and seeing whether technology (or anything else) will be applicable. If ever there was a role that could be useful in SOA adoption, it’s this. Someone can come in, dig around the enterprise, and attempt to classify the culture of the organization. Once the culture is properly understood, now the SOA adoption effort can be properly targeted to manage the inevitable culture change that must occur. Unfortunately, I have no formal training whatsoever in anthropology, but in my role as a consultant, I absolutely understand the criticality of identifying the way an organization works in order to be successful in the engagement. Back in my college days, I took a number of psychology courses (it wasn’t my major), and I’m better off for it.
So, anyone out there actually utilizing anthropology in their SOA efforts? If so, I’d love to hear about it.
4 Responses to “SOA Anthropologist”
Leave a Reply
Stovepipes may or may not be bad to SOA as there could for example be duplication of services or they may be distinct which really depends more on the business models of each stovepipe than anything else.
Agreed. Most articles and blogs tend to speak in generalities (mine included), which means that people are making generalizations like stovepipes are bad. If the stovepipe meets the demands of the business, and the business isn’t changing in such a way that requires breaking the stovepipe apart, where’s the problem? As you suggest, there may be duplication of services, and eventually, a desire to be more cost-effective may call that out. I presently have both VoIP and a traditional land line into my house. It’s redundant. Is it doing what I need? Yes. Is it the most cost effective approach? Maybe not. Are there sound reasons why I have it this way? Absolutely.
In last 10-15 years in telecom industry, most of products are built with vertical stovepipes architecture. It was making sense at that time because it’s like creating a fort where no one can enter. But with lot more competition from small vendors, industry standard and open source, it has become absolutely necessary to upgrade these vertical stovepipes to layered architecture. Look at size of vertical stovepipes, it’s a mammoth and compulsory task. Every enterprise who wants to be in business in future is developing and taking small steps to achieve a enterprise which is more agile in nature.
Once again, I don’t think anyone can argue that stovepipes are generally bad when you start talking about agility. I think what James’ comment, and my own followup state, is that you have to be cautious when speaking in generalities. You suggested that stovepipes are like creating a fort, and sometimes, even today, forts are good. Forts create a domain of control, and well defined domains typically allow for more nimble activities. When costs need to be cut, however, forts can be an impediment.