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:
RT @chrisdpotts Just reading phrase "business-driven EA" and its apparent tautology. Any "not-business-driven EA" (in a business) not EA.
RT @RealLouwWe have to solve the problem of confusion Enterprise IT Architecture with EA bit.ly»
Re: @JohnPolgreen ... is that really a problem?
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.
Re: @aleksb6 ...example - large scale server consolidation - seems an IT arch exclusive problem. Needs at bare min anal of impact on bus
Re: @aleksb6 ...EA PROJECTS may often go light on BA, the EA PRACTICE must focus on business value.
Re: @JohnPolgreen ... there is such a thing as business of IT. If predicated=aligned, I agree w you. If predicated=dependent, not so much
Re: @JohnPolgreen re: business value - agreed... convincing #CIO #COO #CEO of this is quite difficult
Re: @JohnPolgreen ... however, #EA is constrained by Biz Operating and Tech Operating models; in some cases only ETA is most appropriate
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?
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
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
Re: @JohnPolgreen ... just as w other tools/investments, there is such a thing as appropriate use with #EA, whether #TOGAF gets that or not
Re: @JohnPolgreen re: #TOGAF recommendation: doesn't that approach further ossify #EA as #ETA in minds of biz stakeholders?
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
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.
- 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.
- 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.
About Capability Investment Management (CIM)
- ► 2010 (39)
- ▼ September (5)
Blogs We Follow
5 days ago
1 week ago
3 weeks ago
1 month ago
3 months ago
3 months ago
6 months ago
10 months ago
1 year ago
2 years ago