Thanks again to OMG and Brenda Michelson and Karen Larkowski at SOA-Consortium and BPM-Consortium for putting me on the schedule for the special meeting last week in San Antonio.  When I was asked to participate, the guidance on topic selection could have been perceived as daunting - rather than look into internals of how to construct #SOA or #BPM, I was asked to broaden the horizon and consider opportunities opened by leveraging these approaches in the real world.   My initial response was - "so, you want me to go from "Whoa, #SOA!" to "What could I do with this given an opportunity?" posture?  No problem!"

I had a lot of interesting interviews and research in creating this presentation.  Most people only see the results of M&A gone wrong on the front pages of newspapers, news, or talking heads shows.  As I continued to dig into the space, I realized that one of my favorite soap boxes applied here just as well as it applies in Project Management world.  Success (or more likely) failure, depends far less on easily quantifiable benefits like cash on hand and real estate owned than is given attention to during most integration strategy and planning meetings.  It depends far more on intangible organizational assets - culture and people.  As the Hewitt and Associates study shows, 90% of integration planning is spent on accounting, financials, and operations.  Yet  80% of what goes wrong is attributed organizational culture and departure of key resources.  The easily quantifiable "stuff" has dependencies on these "squishy" topics, and it's clear that a lot of merging and acquiring organizations find the successful outcomes elusive because these dependencies are not properly documented and addressed.

As part of illustrating what could go wrong, I created this handy TSA-Style Threat Level Chart based on the "Enterprise Architecture as Strategy" book by Jeanne Ross et al from MIT Sloan School of Business.  The insight of "Know Thyself" applies doubly here - to both organizations.  And while the colors are only warnings and not deterministic indicators of outcome, the amount of attention given to non-easily quantifiable areas of integration planning should vary based on where your organizations fall on this chart.   Another insight is that Integration Capability Portfolio can be used for internal integrations.  As most large organizations are aggregates of smaller business units, optimizing positive outcomes of reorganization is an ongoing concern.  The Capability-Based Approach planning techniques described in the presentation can be easily applied to the reorganization or internal consolidation scenarios.  

Here is the link to download the full presentation.  SOA-Consortium recorded the session, and I will post the link to the podcast once it becomes available.

Chris Curran (@cbcurran) posted an interesting take on whether a CIO can be truly successful without IT domain experience.  One of the more enlightening parts of the post is the diagram that captures 5 "functions" from Business Experience Only and With IT Experience.  I can see a very natural transition of this table into our model with "functions" as "capabilities" and experience labels as two of our four minimum perspectives (Business and Technology).  In fact, that is how one might start building the Office of the CIO with a Capability-Based Approach.  

Back to my reply:  it's an interesting premise, and one that is repeated many times in most environments I see. Larger companies tend to move 'high-potential' executive candidates to a less technical and more management "science" tracks. While I agree with Chris's premise that the optimal CIO should have both IT and relevant business experience, I have seen CIOs without IT experience succeed as well. One of the best was a CISO I worked for who actually studied, took, and passed a CISSP exam along with her technical resources - after working her way up through the general management track.

I found the example of the recreationally whining CIO quite instructive. The underlying issue wasn't lack of IT expertise - it was lack of trust in her "new people". Effective leadership is not about leading - it's about getting others to follow you, and that generally involves bidirectional understanding, if not trust. There are plenty of successful leadership patterns documented - even going as far back as Sun Tsu's Art of War. I'm not aware of any successful leadership patterns that involve calling one's team "them". Did the CISO in my example need to take the CISSP exam? Of course not, but it did gain her credibility with her new department despite lack of any security-related work in her experience.

As IT becomes increasingly complex at all levels of infrastructure and application development, CIO's ability to be successful will probably become more dependent on whether they can rely on people they lead for decision-grade information. It doesn't have to be direct reports - but there better be trusted advisers they can rely on. Without that in place, any organization that appoints a non-technically savvy CIO is in severe danger of mismanaging their technology investments.

We've held back a few posts due to new blog layout debuting today. Expect a flurry of activity in the next couple of weeks!

- Integration Capability Portfolio reprise
- SOA/BPM reprise
- Thoughts on Talent Architecture
- Business Operating Models

There's been a lot of interesting banter - some expected, some not so much - around the Sample EA Capability Map that we posted last week. One of the more interesting insights centers around the appropriate use of Enterprise Architecture. Here's an interesting exchange between me and @JohnPolgreen on Twitter:

JohnPolgreen

RT @chrisdpotts Just reading phrase "business-driven EA" and its apparent tautology. Any "not-business-driven EA" (in a business) not EA.

JohnPolgreen

RT @RealLouwWe have to solve the problem of confusion Enterprise IT Architecture with EA bit.ly»

aleksb6

Re: @JohnPolgreen ... is that really a problem?

JohnPolgreen

Re: @aleksb6 There is a place for IT Arch, but, IMHO it must be predicated on knowledge of BA, and usually in direct response to bus imperative.

JohnPolgreen

Re: @aleksb6 ...example - large scale server consolidation - seems an IT arch exclusive problem. Needs at bare min anal of impact on bus

JohnPolgreen

Re: @aleksb6 ...EA PROJECTS may often go light on BA, the EA PRACTICE must focus on business value.

aleksb6

Re: @JohnPolgreen ... there is such a thing as business of IT. If predicated=aligned, I agree w you. If predicated=dependent, not so much

aleksb6

Re: @JohnPolgreen re: business value - agreed... convincing #CIO #COO #CEO of this is quite difficult

aleksb6

Re: @JohnPolgreen ... however, #EA is constrained by Biz Operating and Tech Operating models; in some cases only ETA is most appropriate

JohnPolgreen

Re: @aleksb6 but you agree that the overall practice should be EA, therefore bus focused, even if an ETA approach is used for specific projects?

JohnPolgreen

Re: @aleksb6 difficulty convincing Cxx of value of #EA is one reason #TOGAF recs going after low hanging fruit to gain trust - use ETA for this

aleksb6

Re: @JohnPolgreen ... my point is that in some operating models, only ETA is appropriate, not full #EA - it must be a conscious decision by biz

aleksb6

Re: @JohnPolgreen ... just as w other tools/investments, there is such a thing as appropriate use with #EA, whether #TOGAF gets that or not

aleksb6

Re: @JohnPolgreen re: #TOGAF recommendation: doesn't that approach further ossify #EA as #ETA in minds of biz stakeholders?

JohnPolgreen

Re: @aleksb6 ...but build up your #BA knowledge as you do the #ETA projects - "#EA by stealth". In the lng run ul hv EA & show its value to Cxx

aleksb6

Re: @JohnPolgreen ... malheuresement, in that long of a horizon, #EA is usually susceptible to Shutdown/Restart #eapitfall

About half-way through the exchange, I realized that there is nothing in #TOGAF or #Zachman (or other frameworks) around the concept of appropriate use for EA itself. They throw the entire classification framework and in TOGAF's case ADM as the way to do Enterprise Architecture ("Framework is THE answer #eapitfall"). Hence, it becomes fodder for practitioners to argue about what "real" EA is, relegating perfectly legitimate subset approaches to pariah status.

In response, following our standard SenseAgility Bulls-Eye model, Enterprise Architecture as a function (or as Capability Portfolio in our view) is constrained by the Goals, and further b y Operating Models of each perspective. So if a subset of EA is appropriate for a particular Operating Model, then there is nothing wrong with only doing that part of EA! For instance, if an organization is based on Diversified Business Operating Model, the only impetus for EA to offer Business Architecture-based services as part of Business Reference Architecture Capability is if that organization wants to change it's Business Operating Model. If not, that information is not consummable by anyone outside of EA, so why would you invest into that capability?

In summary, EA is like quicksilver running where the lowest common denominator allows it to run. It will look different for every business and even within each business as it matures. This is where frameworks can lead practitioners astray. They have an end-state that is uncooperative with the demand.

In response to tremendous volume of requests from analysts big and small, we've spent a few days 'cleansing' a mature EA Capability Map and cross-referencing it with the EA Services posts that Todd Biske (@toddbiske) has been collecting on his blog (posts here, here, and here) from various thought leaders in this space.  We also considered Mike Kavis' (@madgreek65) thoughts on whether Enterprise Architecture is a good idea for smaller companies.

Before diving into insights learned (and shared with Forrester's Jeff Scott (@logicalleap)), a few notes about the diagram.

• We use the standard SenseAgility Bullseye that includes four perspectives:
• Business - defined as the business of the department in question, not the organization as a whole (upper left);
  
• Organization - who is required to operate all perspectives (upper right);
  
• Technology - what tools are used to operate all perspectives (lower left);
  
• Risk - what controls are in place to mitigate threats to all perspectives (lower right)

• The dependency lines are omitted on this Capability Map.  There are other, more appropriate diagrams that capture these relationships.
  
• For illustration purposes, we used one of the capabilities to show how services aggregate into capabilities.  EA Education Capability (Org Perspective) breaks down into 5 services, with further dependencies to EA Tools Capability (Tech Perspective) and its two services.

So a first batch of insights:

• As with any complex animal, it is the dependencies that drive the value of any EA organization.  Inter-dependencies between EA Capabilities, Services, Processes, and external dependencies based on stakeholder alignment are the key to capturing, monitoring, and reporting on the value of EA.
  
• Any Enterprise Architecture functions performs all of these capabilities - whether formally or informally.  And formality is not really determined by organization size.  The real dependency on organization size is the extent to which these capabilities are executed.  Formal education program and engagement management functions, for example, would not be necessary in a small company like Mike's.  They would be critical in a Fortune 50 company.
  
• The Capability Map is an operating model for EA.  It is not a roadmap on how to build or source capabilities.  Since each set of stakeholders is a set of unique individuals, each organization is unique.  Hence, healthy skepticism is warranted when someone presents a one size fits all EA roadmap.
  
• Enterprise Architecture has very little to do with Technology perspective.  Only 1/14 capabilities in our vanilla model deals with technology.  By contrast, fully half (7/14) are organizational capabilities.  This result should not be surprising - while a strong foundation in technology is a necessary skill set for any Enterprise Architect, business acumen, organizational awareness, and risk management are even more important.

More thoughts to come, especially with everyone's participation!