SOA requires trust
James McGovern made the following comments regarding my Service Adverse Architecture post:
Todd Biske is right on the money by echoing the fact that companies who have mastery of SOA also have forward thinking management. I wonder if him and Joe McKendrick would define a litmus test so that others can characterize their own enterprise in terms of the management team?
While I’ll have to give some thought to the entire litmus test, the first thing that immediately came to mind was trust, and it’s not limited to management. If I’m a project manager, I want to have as much control over my own destiny as possible. When I now become dependent on other groups and other projects outside of my control and my management to be successful, that’s a big leap of faith. Unfortunately, it’s part of human nature to remember the one project where a team had problems rather than on the times the team was successful. As a result, parties may go into the relationship with the expectation that someone is going to screw up, spend all their time looking for it ready to point blame, and as a result, that’s exactly what happens. If the groups instead focused on what is necessary to be successful, they’d probably be successful.
We live in a culture where making a mistake is unacceptable. One only needs to look at the current political process to understand how much our culture is based on avoiding failure rather than achieving success. A legislator is not allowed to change a stance on any issue, even though we as individuals do it all the time because we learn more as we go along. Cultures that are based on avoiding failure are, in general, going to have a difficult time doing more than maintaining the status quo. Innovating and advancing means taking risks, and when you take risks, some of them don’t pan out. Teams should not be penalized when they don’t pan out, unless it’s clear that they made very bad decisions based upon the information available at that time. I can look back at many decisions I’ve made in the past and recognize that some of my assumptions didn’t come true. As long as I’ve learned from that and don’t repeat those same decisions, there should be no penalty associated with it.
I suspect that organizations that are more forward-thinking have a greater level of trust within the organization. There is more collaboration than competition, and people all understand that everyone in the organization has the best interests of the organization as a whole in mind, not the best interests of themselves, their team, or their manager. Furthermore, management works effectively with the individuals in the trenches to help them understand what levels of risk the organization will tolerate and what the boundaries for innovation are within each group in the organization (essentially around roles and responsibilities). I’d much rather have an application developer creating innovative applications rather than trying to leverage a new Java framework. At the same time, the team responsible for development frameworks needs to be open to receiving input from the application developer. If they have mutual trust, the development framework team will be open to hearing about new alternatives, and the application developer will not throw a fit if the development framework team decides that it’s not in the best interests of the company to leverage the new framework at this time.
SOA will create more moving parts associated with the delivery of IT solutions. More moving parts means more ownership and hence, more interaction among teams. If we don’t trust each other, the chances of success are greatly reduced. That being said, trust must be earned and maintained, it can not be established by edict. Service providers must do all they can to build trust. Management must ensure that the organization takes an “innocent until proven guilty” approach, rather than the opposite, with actions that back it up.
5 Responses to “SOA requires trust”
Leave a Reply
Great comments Todd. Trust is largely earned and maintained through relationships.
In “Five Dysfunctions, Patrick Lencioni makes a case that trust is foundational to the behavior of a team – trust sufficient to allow honesty and vulnerability. This forms the basis for performance in today’s complex corporate contexts and allows a team (or a company) to overcome:
Fear of Conflict
Lack of Commitment
Avoidance of Accountability
Inattention to Results
The good news is open communication, commitment, accountability, and results lead to greater levels of trust. At that point, a cycle of positive reinforcement has begun (the flywheel is beginning to spin), and we’re building a high-performance culture that is able to efficiently deliver value to the business.
Keep up the good work.
Brian
http://blog.softwarearchitecture.com/
Brian-
Thanks for your comments. I actually meant to include a reference to that book in my original post, so thank you for taking care of it for me!
-tb
Todd, great insight… I look at it from a little different perspective, as I see trust as only one aspect, and think its more releated to seasoned managment/technical teams that know how to manage risk, in many flavors, that makes the difference.
I agree most find mistakes and failure not very palatable…however my motto is “fail fast, fail often, it’s the only way to success.”
Seasoned successful teams embrace failure…not that they are reckless, but high risk areas (unknowns) are driven to a failed state as quickly as possible, so recovery can start as soon as possible. The metric is not how often, or how great the mistake/failure, its how quickly a team can recover(cost/time/etc). I find much more tolerance when there is a clear recovery plan, and the risk area was identified during early phases of a project.
Those teams that actively manage risk, as opposed to risk avoidance, have the greatest success. As you noted, there are many more external dependencies and moving parts with SOA, that means more risk and teams will just have to learn to manage it.
To your point about trust, to effectively reduce risk, there is a requirement of increased transparency among teams. That transparency translates into increased trust and effective communication over time.
I see successful companies understanding how to activly manage risk in all aspects of thier business including IT, as opposed to risk avoidance. Active risk management I think will ultimatly drive to more trust among teams.
Tom
[…] Some companies encourage individuals to think outside of the box and outside of their formally stated responsibilities, and it’s probably one that should be added to the litmus test for a company likely to be successful with innovation and strategic initiatives. After all, the degree to which a company does this is a matter of trust. Unfortunately, it’s far easier to break down that trust that it is to build it up. For those of you dealing with that, follow this link to another excellent book that I’ve read. […]
[…] The interviewer, Mike Gotta, made the comment that blogs within the enterprise need to be purposeful, and that there’s a fear that they will simply be a soap box or a place to rant. To any manager or executive that has a fear about them becoming a place for employees to rant, you’re looking at the wrong issue. If employees feel a need to rant, they’ll be doing it in the hallways, break rooms, and cafeteria. If anything, blogging could bring some of this out in the open and allow something to be done about it. This is where I think there is real value for blogging, wikis, etc. in the enterprise. I recently had a post titled Transparency in Architecture that talked about a need for projects to make their architectural decisions transparent throughout the process (and the same holds true for enterprise architects and their development of reference architectures and strategies). Blogs and wikis create an opportunity to increase the transparency in enterprise efforts. I’ve worked in environments that had a “need to know” policy for legitimate reasons, but for most enterprises, this shouldn’t be the case. When information isn’t shared, it may be a symptom of lack of trust in the enterprise, which can be disastrous for SOA or anything else IT does. […]