Does your SOA lack social skills?

That’s the question Hub Vandervoort, CTO of Progress Software, has been asking CIOs and EAs of late. Not to be confused with social computing, Hub is talking to organizations about their awareness and ability to form and retain relationships for the betterment of all parties. Why? Because at the core of SOA is federation. And federation requires cooperation.

Technology side federation is obvious. It is the assembly of disparate services, and underlying IT resources, into business solutions. Business side federation is less obvious, but enormously powerful. It is the cooperation of disparate business entities to generate value for all parties, including the end-consumer. In his eBook, Hub cites business federation examples from aerospace manufacturing, financial institutions and travel aggregators. In my own work, I often talk to this as business activity ecosystems.

This moment of federation-ecosystem convergence, diverted my short call with Hub on SOA and the Economy to become an extended conversation on the criticality of applying social as well as technical concepts for successful federations. Hub refers to this as “Socially Oriented Architecture” (eBook).

Although our conversation was far ranging, and occasionally tangential, I’m only going to focus on the core concepts here – contracts, governance, trust & commitment, and empowerment. To learn more about socially oriented architecture, check out the eBook and related webinar, and look for Hub on the conference circuit.

 

Contracts

As Hub was explaining socially oriented architecture, he spoke of some basic, but not simple, questions. The first:

“How do we organize ourselves as people so that we can in fact form cooperative arrangements?”

In a truly cooperative arrangement, no single party is in control. The parties establish a contract in which they specify responsibilities, timelines, communications, performance expectations, payments and penalties. That should sound familiar to practitioners of service-oriented architecture. This led to Hub’s second question:

“What’s the right sizing of the contract so it doesn’t encumber us with a bunch of decisions that really don’t matter, yet provides enough adequacy so that we can get an effective federation going?”

The answer to this question is all about service-orientation. A right-sized contract:

• focuses on “what” each party will do, rather than “how” they will do it
• includes performance expectations, payments and penalties
• specifies interaction style
• defines precise semantics

In respect to interaction style, Hub shared that the most equitable federations interact in an event-drivenmanner. Parties inform each other of progress and delays with the expectation the other party will respond appropriately. No single party controls the flow of work and information.

 

Governance

In a service-oriented architecture, governance mechanisms and organizations are put in place to monitor and enforce contracts. A governance approach works for single domain environments, but becomes problematic in a federation. This leads to another of Hub’s questions:

“What are the human dimensions to get people to interoperate together when there is no hierarchy stemming over those people?”

This question, first raised by Hub during a speaking engagement in Europe, led to collaboration with McKinsey during which the following “from-to” was developed:

“Moving from a world where the principle management tool has been hierarchy to a world where the principle management tool now has to become trust and commitment.”

 

Trust & Commitment

This brings us to the final question:

“How are trust and commitment established?”

Hub shared that you can only achieve a trusting relationship with good transparency. In a business context, this is the timely communication of relevant information. As an example, Hub cited a simple purchase order agreement with terms to send the buyer an advanced shipping notice (ASN) 14 days after the order is placed. If the seller wants to build trust, he should send the buyer notifications from each step of the order fulfillment process. Then, if an issue arises on the fifth day, both parties are equally aware and able to adjust.

Commitment requires agreement on a unit of value appreciated by both parties. In a business context, the most common units of value are time and dollars.

According to Hub, contracts need instrumentation in place to create a trusting transparent environment, as well as monetization to create a canonical unit of measure for commitment. Without these elements, a federation will not succeed.

 

Empowerment

Bringing the conversation back around to corporate IT, Hub described his vision for the future of IT organizations that embrace social constructs and shift to a trust and commitment management mindset.

“The real shift [for IT] is not to do what you’ve been doing in the past faster, but shift from being delivery mechanism to empowerment mechanism — truly democratized computing in a Web 2.0 sense. The end-user is always going to operate on the path of least resistance. Find tools that enable him to create his own solution… mashable desktops, data access through services…”

Another point that Hub and I converge on is the opportunity to learn about business optimization from how people “wire stuff together” and how they “react and respond to events”. To capture this information, the wired components and environment must include instrumentation and monitoring. Hub was quick to point out that IT needs to be careful not to institutionalize that learning in rigid, controlled applications.

Hub acknowledges that this is an “unsettling idea” and that perhaps the most unsettling part is ensuring compliance with regulations such as SOX, PCI, and HIPAA.

 

Wrap and Discussion

As our call ended, Hub spoke to the state of this work. Socially oriented architecture is in the idea, rather than implementation stage. The path to implementation would include education and practices on the case for federation, management change, contract structure and negotiation, organizational change, and technology implementation.

Hub mentioned some might consider socially oriented architecture “granola SOA for the casual pedestrian”, but he was quick to add that innovative times require new techniques.

I thoroughly enjoyed my conversation with Hub. As folks know, I’m most interested in exploring the connections between business, technology and people. As follow-on, I plan to take Hub up on his offer to learn more about the ‘case for federation’.

 

Discussion Questions – How Social is your SOA?

1. How federated is your SOA?

• Do business so
  lutions (applications, processes, widgets, mashups) consume services from more than one domain? Are those domains within the control of your enterprise/agency?
• Are the business capabilities your SOA provides part of a larger value chain? Is service-orientation or events used to interact with other value chain participants (partners, suppliers, regulatory agencies, customers)?

2. Does your basic service design include system and business instrumentation? How are those instrumentation events used?

3. Does your governance model rely on hierarchical relationships? Could it work in a federation with external parties?

4. Is your SOA designed with end-user empowerment in mind? Should it be?

 

[Disclosure: Progress Software is not a client of my company, Elemental Links]