Enterprise Architecture is Misplaced and Other News from MIT Research

Friday, February 18, 2011 |

Several interesting points that deserve their own blog posts, so this is just a conversation starter:

- EA should not be inside of IT, and it's usual placement hampers both IT and its effectiveness.
- EA maturity is directly related to organizational performance, and can be built in discrete stages.
- Overall IT Budget increases by a factor of 50% in organizations that are in Stage 4 (Business Modularity) and business leaders love that because they get more per use and time to market increases that give them competitive advantage.
- One of the determining factors of EA-lead transformation success is stability in the executive ranks (yes, my presentation on this coming in a month, so stay tuned)
- Strategic Agility has a dependency on evidence-based management culture.  This culture cannot be built overnight, nor can it come from natural evolution.  It has to be enabled from both top and middle.
- There are three (3) key requirements to work smarter: Operational Intelligence Backbone (Competing on Analytics), Business Rules Management (BRM), and Organizational Development.
- Align business activities with IT - not IT with the business activities.  Otherwise you're trying to align the most static strategies with to the most dynamic.  Create a core - and then align things to that core.

Please discuss!

AAB

Business Capability Naming and Content

Tuesday, February 15, 2011 |

Bruce Silver, BPMN luminary, has recently posted a piece on BPMN and Business Architecture where, he says, “In the past year the ‘architects’ seem to have discovered BPMN.”  WIth his usual meticulous style he dissects the difference between a process and other notions such as capabilities and functions, terms that architects like to throw around in their paperwork.

He clearly distinguishes process as the “how,” which is what we, at SenseAgility, have been saying as well. Process diagrams, and BPMN diagrams in particular, are the proof behind a particular type of capability, namely the Business Capability. In our work we’ve found that there are specific types of acceptable proofs behind different types of capabilities.

Here’s a statement Bruce makes about typing or perhaps it is even about granularity by implication, “If you’re sorting things into boxes, it doesn’t matter so much if some boxes hold square pegs and others round holes. But when you want to assemble those boxes into a coherent unit, it would be easier if the pegs and holes all had the same shape.” To us this principle is exactly the same one we employ when naming capabilities. As mentioned above, capabilities are different types. You can tell they are different types by looking at the proof behind the capability. That is, what makes the capability a capability in the first place? Business Capabilities have processes behind them, maybe more than one, but at least one.

So what I’m saying here is that if you want to give a name to a capability you need to have something in mind besides appropriate wording. Just getting people to agree on words doesn’t cut it. Why? Because ultimately you need to be talking about something of value. If capabilities can’t be linked to something of value then you might be imagining capabilities in a vacuum.

Anyway, subscribe to Bruce’s excellent blog when you get a chance.

Operational Capability Risk: Executive Rotation

Thursday, February 3, 2011 |

As announced last year, I will  be presenting at the OMG Business Ecology Initiative's inaugural "Optimization for Innovation" Conference on 3/22/11 on how an executive can quickly and efficiently analyze operations of a business unit.  As our team started researching for this presentation, we came up with a few statistics (yes, it's a tease) that even we didn't expect.  Loss of executive sponsorship is almost always in the top 5 reasons for project failure.  What surprised our team was the number of large organizations that actually have organizational efforts in place to make sure that executive rotations happen.    While this makes sense from a leadership development point of view, it increases the Operational Capability Risk.

So the focus of the presentation shifted away from the executive point of view and toward that of an Operation or Change Programme leader.  The majority of large scale organizational transformation efforts take time.  Not just capital, resources, but time.  Behavior cannot change overnight - it has to evolve little by little over time.  It is just like the sport of curling, but without the stone thrower.  The stone glides over the ice, and the most effective change agents simply sweep the ice around the stone with rather crude implements to guide that stone to where they want it to go.  Forcing the stone any other way can be counterproductive, and just downright dangerous - it weighs a lot and there's very little friction to stop it from running over one's foot.

Sweeping takes time.  Planned volatility in leadership throws a wrench into that need for time.  If you are a change programme leader, planned leadership volatility means that you not only have to continuously communicate about your effort, you have to "sell" more than one executive to be that effort's sponsor.  And to nobody's surprise, it is my belief that Capability Driven Approach is the optimal way to develop and deliver that sales pitch.  Belief isn't enough in many books, though - so confirmation of many case studies and independent verification from Forrester Research helps as well.

AAB