Governance

How Enterprise Architects can cope with Opportunistic Failure

by

You may not think that Failure is a desired outcome, and on the surface, there are some negative connotations to failure.  It just sounds “bad” for a team to fail.  However, there are times when a manager will INTENTIONALLY fail in a goal.  Let’s look at the scenario where a manager may choose to fail, and see whether EA has a role in either preventing that failure, or facilitating it.

What is Opportunistic Failure?

Does your organization manage by objectives and scorecards?  Scorecards and metrics are frequently used management tools, especially in medium and large organizations.  In a Manage-By-Objective (MBO) organization, a senior leader is not told “how” to do something, but rather a negotiation takes places that results in the development of a measurable objective.  The term “measurable objective,” used here, is a well-defined idea.  It is specific, measurable, actionable, realistic, and time-bound (SMART).  A measurable objective is a description of the results that a senior manager is expected to achieve.  In BMM terms, the objective is the “ends” while the senior leader is expected to figure out the “means.”  In business architecture parlance, the objective describes the “what” while the senior leader is expected to figure out the “how.”

Now, in many situations, a senior leader has to rely on other groups to perform, in some way, in order for him to achieve his measurable objectives.  This is quite common.  In fact, I’d say that the vast majority of senior-level objectives require some kind of collaboration between his or her people, and the people who work in other parts of the organization (or other organizations). 

For a small percentage of those dependencies, there may be competition between the senior leader’s organization and some other group, and that is where opportunistic failure comes in.

The scenario works like this: 

Senior leader has an empowered team.  They can deliver on 30 capabilities.  Someone from outside his or her organization, perhaps an enterprise architect, points out that one of those capabilities is overlapping.  Let’s say it is the “Product Shipment Tracking” capability.  The EA instructs the senior leader to “take a dependency” on another department (logistics in this case) for that.  The senior leader disagrees in principle because he has people who do a good job of that capability, and he doesn’t want to take the dependency.  However, he cannot convince other leaders that he should continue to perform the “product shipment tracking” capability in his own team. 

So he contacts the other department (logistics) and sets up an intentionally dysfunctional relationship.  After some time, the relationship fails.  Senior leader goes to his manager and says “we tried that, and it didn’t work, so I’m going to do it my way.”  No one objects, and his team gets to keep the capability.

In effect, the senior leader felt it was in her own best interest to fight the rationale for “taking a dependency,” but instead of fighting head-on, s/he pretends to cooperate, sabotages the relationship, and then gets the desired result when the effort fails.  This is called “opportunistic failure.” 

Thoughts on Opportunistic Failure

Opportunistic failure may work in the favor of anyone, even an Enterprise Architect.  However, as an EA, I’ve most often seen it used by business leaders to insure that they are NOT going to be asked to comply with the advice of Enterprise Architecture, even when it makes sense from an organizational and/or financial standpoint. 

In addition, one of the basic assumptions of EA is that we can apply a small amount of pressure to key points of change to induce large impacts.  That assumption collapses in the face of opportunistic failure.  Organizations can be very resistant to change, and this is one of the ways in which that resistance manifests. 

Therefore, while EA could benefit from EA, I’ll primarily discuss ways to address the potential for a business leader to use operational failure to work against the best interests of the enterprise.

  1. Get senior visibility. – If a business leader is tempted to use opportunistic failure to resist good advice, get someone who is two or more levels higher than that leader to buy in to the recommended approach.  This radically reduces the possibility that the business leader will take the risk to his or her career that this kind of failure may pose.
  2. Get the underlying managers in that senior manager’s team on board, and even better, get them to agree to the specific measures of progress that demonstrate success.  This creates a kind of “organizational momentum” that even senior leaders have a difficult time resisting.
  3. Work to insure that EA maintains a good relationship with the business party that will come up short if the initiative does fail.  That way, they feel that you’ve remained on their side, and will call on you to escalate the issue if it arises.
  4. Play the game – look for things to trade off with.  If the senior manager is willing to risk opportunistic failure, you may be able to swing them over to supporting the initiative if you can trade off something else that they want… perhaps letting another, less important, concern slide for a year.  

 

Conclusion

For non-EAs reading this post: EA is not always political… but sometimes it is.  Failing to recognize the politics will make you into an ineffective EA.  On the other hand, being prepared for the politics will not make you effective either… it will just remove an obstacle to effectiveness. 

Pats SOA Governance Perscription

by

RX 

Just recently, I was asked to provide some advice to a customer on how to adopt SOA Governance, specifically the Oracle Enterprise Repository (OER), in a step-wise and rational way.  It seemed like sage enough advice to publish here

Here is what they were trying to do which is similar to what other customers are doing:

  • Establish a single source of truth in a SOA Repository
  • Single repository supporting on-shore / off-shore distributed teams
  • Manage service artifacts (i.e. projects, service design documents, policy definition…)
  • Enables SOA program managers manage service portfolio and service demands
  • Enables SOA program managers with related reports (i.e. demand, reuse, compliance & exceptions, dependency/impact analysis, …)

So it can be successful – but you don’t want to boil the Governance Ocean – at least not all at once.  In a word, I’d advise getting a firm understanding on which services you want to govern (probably not all of them) and the types of things you want Governance to do for you. Once you have that, you can move forwards in a stepwise approach that reduces the effort AND complication.  Realize that installing OER is only a small part of the puzzle.  You need to have the right Org structure (official or unofficial) in place and the right incentives and rewards to help motivate people to “do the right thing” such as to reuse services instead of writing their own.  Then you need the right processes to for people to follow.  It’s the notion that:  

 Governance = PEOPLE + TECHNOLOGY + PROCESSES


Let’s say there are 50 key services to manage –  for discussion purposes.  Here is what I’d do at a super high level:

  • Add Projects, Policies, Classifications Asset Types as needed (JUDISIOUSLY – keep it simple at first)
  • Add users in different roles
  • Get your top 50 key existing web services in OER using the Harvester if possible.  Otherwise just take some time to add them manually.  Make sure these are the relatively static PROXY services from OSB.
    • Be sure to assign one or more people to OSR as administrators/architects to help keep things in order
  • Add the correct lifecycle stage to them
  • Add the right classifications/taxonomy to them
  • Add documentation such that developers know how to use the service (i.e. can download a doc or visio or whatever that explains it)
  • Add any and all XSD, WSDL and other files that people would need to download to actually use service
  • Add a section to the OER home page that explains to users about the WL Gore SOA program, schedules and contacts – make it a place people go for some critical PROGRAM-level information – SELL what you are doing here…
  • Get developers used to using the tool through an in-house training
  • Use the reports to get a management view into the SOA program and help fund/support what you are doing
  • Then – start entering future state services to track as they go from inception to deployment in the life-cycle

 

Things that add complexity that you can add later IF they add value to what you are trying to do:

  • Install OSR / set up
  • Enable publishing to OSR
  • Set up harvesting of SOA/BPEL projects
  • Set up/enable automated approval workflows
  • Synch up performance metrics from OSB or OEM back into OER
  • Assign CAS (custom access settings) settings to individual assets

And so on.  But add these later after the basics are down.

So – I hope this helps anyone else who wants to begin a SOA Governance effort using OER (with OSR, OSB and OEM as secondary stages after initial success).

New Compilation Book and Possible EA Book

by

While I have not yet embarked on writing another book, I have been published in a second book. The publisher of my book on SOA Governance, Packt Publishing, has released their first compendium title called, “Do more with SOA Integration: Best of Packt.” It features content from several of their SOA books and authors, including […]

Decision-making – linking intent and action [4]

by

How is it that what we do doesn’t necessarily match up with what we plan to do? How can we best ‘keep to the plan’? Or, alternatively, how do we know how to adapt ‘the plan’ to a changing context? What governance do we need for this? How do we keep everything on-track to intent […]

You already use Stage Gates

by

Here’s some delightful industry news, the 2009 version of the Standish Chaos report indicates that only 32% of I.T. projects are delivered on time, on budget, with required features and functions. 24% of all I.T. projects fail, i.e. are cancelled pri…

You already use Stage Gates

by

Here’s some delightful industry news, the 2009 version of the Standish Chaos report indicates that only 32% of I.T. projects are delivered on time, on budget, with required features and functions. 24% of all I.T. projects fail, i.e. are cancelled pri…

Unruly Google and VPEC-T

by

Google has been hoist by its own petard: it seems obliged to ban its own browser from its own search engine for infringing its strict rules. Apparently the infringement resulted from some misbehaviour somewhere down the subcontract chain, unknown to Go…

Unruly Google and VPEC-T

by

Google has been hoist by its own petard: it seems obliged to ban its own browser from its own search engine for infringing its strict rules. Apparently the infringement resulted from some misbehaviour somewhere down the subcontract chain, unknown to Go…