Good grief! Not another pesky TLA? Well, not really. SOC stands for service-oriented culture—an awkward term I use to describe a phenomenon that is an essential element of developing an SOA and sometimes conspicuously absent in the enterprise. Once I’d used this term a few times in my talks, my fellow evangelist and erstwhile cohort in crime, Allan  suggested I write a blog and take ownership of it.

A lot has been written to define what an SOA is, what its benefits are, and how to develop one. So much has been written in fact that the term ‘SOA’ may begin to suffer from what Jacques Derrida called effacement—the dissolution of meaning from overuse. Yet, as a wandering evangelist, I frequently find that SOA doesn’t have the momentum in the enterprise that one might expect given the honors that have been heaped upon it. I’ve started to think that the enterprise yearns for the virtues of SOA the way that Augustine of Hippo yearned for the virtue of chastity: “Grant me chastity and continence, only not yet.” I understand Augustine’s hesitation, but what about the enterprise? Why does the enterprise seem hesitant about the virtues of SOA?

Many organizations have overcome the inertia of the status quo and moved toward SOA with enthusiasm, of course—but many others are still moving forward at a snail’s pace—if at all. Even the enthusiasts won’t necessarily meet with immediate success on this front. And btw, having a bunch of services lying around your enterprise doesn’t constitute success with SOA, either. If you want to read a good article that keeps SOA in sharp focus, take a look at Control and Visibility in a Service-Oriented Architecture by my DPE colleague, Keith Pijanowski.

One factor that creates a drag on SOA adoption in the enterprise is a need for a well-organized and robust service-oriented infrastructure (SOI). Other factors at work hereare the trials and tribulations of attaining standardized, cross-platform service implementations. These can both be important obstacles to SOA adoption at times, but these factors have received a lot attention already; they’ll probably receive more in the future.  

One big reason for the sluggishness toward SOA that has been much neglected is the lack of service–oriented culture. SOA involves a true paradigm shift (Yes, I know this is a much hackneyed term—especially in information technology—but it’s very a propos here.) Part of every paradigm shift is a gradual process of cultural evolution. Paradigm shifts in computing are somewhat different from the scientific kind that Thomas Kuhn first described because they leave more room for doubt. When a new paradigm occurs in the scientific world, the shift has tremendous momentum because it provides superior explanatory and predictive power. Going from Newtonian to Einsteinian physics is a good example. Like a glacier, movement is slow but inevitable.

In the computing world, old paradigms often seem to have a strong inertia of their own, overlapping more broadly with the new paradigm. When N-tiered architecture appeared on the scene, for instance, client/server architecture and development continued largely undaunted for quite some time.  There are many reasons for this lagging effect, such as the lack of new tools, the need to fully leverage investment in the existing technology, the ramp-up time needed by developers to acquire new skills, and skepticism about the need for a new paradigm or its potential to fulfill its promise. But I think ‘cultural inertia’ is also fundamental to this phenomenon. Paradigm shifts push people and teams outside their psychological comfort zones—and this takes time.

Moreover, I think that this cultural inertia is greatly underestimated. The larger the community is, the greater the inertia can be—especially in risk averse organizations. Looked at from this perspective, the cultural factor helps demystify the sometimes torpid embrace of SOA in the enterprise.

In simplest terms, an SOC is the community mindset that has bought into the SOA paradigm. I’m not talking about the developer community alone. On the contrary, SOC must become pervasive in the IT community as well as business stakeholders in order to achieve the optimal benefits. Nor am I just talking about raising awareness about SOA, because success with this paradigm often requires far more. Ultimately, the development of an SOC may require an organization to transform itself in important ways. Architects and developers will need a new mindset and the skills to match it. The same is equally true for testing, deployment, infrastructure and operations. Each of these is a key facet of the community that must embrace service-orientated principles and fundamental change. Funding SOA can require fundamental changes to the budgetary process or new chargeback scheme’s to pay for services shared across multiple, semi-autonomous business units.

On the server side, an SOC may mean developing highly reusable services, but it also means designing facades that will position the business to take advantage of off-premise services as they become available. On the client side, an SOC can mean encouraging developers to fully leverage existing services in their designs and help drive new service requirements they are discovered. On the business side, SOC can mean coordinating joint development efforts between separate business units, being alert to opportunities to reduce cost or time-to-business value by consuming services in the cloud, or even providing services that can be securely accessed by partners or customers, improving business agility or opening new markets. In some cases, SOC will mean that parties from many different roles and areas of responsibility must work together to ensure that real interoperability across platforms is achieved with service and data contracts that actually model meaningful and useful business abstractions. Examples are abundant, but the point is that SOA must be ingrained in the culture throughout the enterprise.

Perhaps you will think I’ve gone too far by suggesting that business stakeholders are part of the SOC. Au contraire, mes amis!  Putting aside the obvious fact that transforming IT will require real business sponsorship and investment (i.e. money) to succeed, I think SOA is most powerful when it reflects service-orientation in the business architecture itself.  In fact, one could argue that many of the tenets of SOA were fundamental to business architecture long before they were introduced as the operative paradigm in IT. If you’re not convinced of this, I suggest you read Pat Helland’s superb article Metropolis –he’s not only more convincing, he’s more entertaining too. [Btw—it’s nice to see a card carrying member of the Barbarian Horde come back to Microsoft—for those who’ve been around long enough to get the reference.]

Surely, the tenets of contract- and policy-based design, service autonomy, and explicit boundaries are important fundamentals of business architecture as well as solution architecture. I would argue that SOA is most effective when business and IT are of like minds—that’s what an SOC is all about. It’s a shared commitment to a set of organizing principles. Business and IT can derive similar benefits from SOA—agility, standardization, adaptability to change, and quality of service, to name only a few. I really like Mohammad’s blog on this topic: Selling SOA to business stakeholders.

Want to accelerate the SOA paradigm shift in your enterprise? You may need to expend some energy nurturing the SOC as part of the process. I don’t think I can provide a simple recipe for this type of transformation, but to me, it’s less about ‘architectural governance’ and more about socializing the concepts, raising awareness, building consensus and encouraging buy-in about SOA. It’s cultivating the SOA mindset throughout the enterprise. Developing SOC is the indispensible human dimension of making the SOA paradigm shift. Without it, your success with SOA may be limited and slow in coming. Need a little help? Call your friendly neighborhood architect evangelist.