CIO’s and EA – Leadership Challenges in IT

We ask a lot of our CIOs.  Just follow the myriad magazine articles and research pieces targeting CIOs to read of the breadth and depth of expectations heaped upon a single role.   The industry experts who define what CIOs ”should be” suggest that they must be technology visionaries and innovators, business transformation change agents, vendor relationship negotiators, savvy business managers and human capital performance motivators, cost-cutters, quality experts, portfolio managers, talent scouts, have operations and service management knowledge, be technology, process and solutions aware, passionate leaders and experts on the company’s industry, etc.  The list goes on.  Actually, I agree with all of these traits and more – they are all required.   It’s a tough job and can’t easily be characterized into a simple role description.    

As a case in point, I have been following Bob Evans’ column in Information Week of late.  I enjoy his perspectives.  His most recent column, “Do CIOs Still Matter“ , struck a chord in me.  He listed ten ideas to get started redefining a CIOs roles and boundaries.  Many of his points spoke to things that we have been coaching our Enterprise Architecture clients on for years.  In particular, he commented that today’s CIOs “spend too much time on the tech side of IT and should instead be more involved in technology-enabled business growth and customer intimacy”.  Other points included “lead the charge in seeing the future”, “drive transformation” and my favorite, “be a business-model buster”.

So, what is the CIO to do?  How can a CIO be tactical and strategic, responsive yet not reactionary, thoughtful and systematic yet not slow and obstructionist, operational and also transformational, cost-sensitive while investment and growth oriented?  The simple answer is that in all but the most extraordinary individuals, it isn’t possible, or it is at least unlikely that all of the required personality traits and knowledge can co-exist.  The best approach to being broad and deep enough is to surround him/herself with a strong team, with each member focused on different aspects of the role.   The best CIOs are already doing this, realizing that the CIO role isn’t intended to be a single super-human (though many white papers seem to suggest that and some CIOs try to become one) but is instead an aggregation of the skills and talents of a group. Traditionally, that group is called the “Office of the CIO”.

Many CIO’s already recognize that they can’t personally be everything to everyone and that they must have a great staff.  Most CIOs put a director in charge of the data center with a focus on operational efficiency and meeting service levels.  One or more directors are usually focused on solutions development and delivery.  The better organizations have a PMO in place to shepherd the project portfolio, though most PMO’s are low maturity engaging in mainly project tracking and reporting.  More on that in a future article.  What is missing in most CIO Offices is a person responsible for the big picture future state business context, the holistic cross enterprise perspective, the long view of the health and utility of the asset portfolio, and to address larger concerns like complexity management, portfolio optimization, integration, and the integrity of the information, technology and business architecture assets.  These activities and perspectives are embodied in the role Tim and I have prescribed to the “enterprise” architect since we began in this discipline in the 1990′s.    

While empowering a diverse IT leadership team is necessary, successful CIOs also understand that the buck stops with them, so they need to be able to make sound decisions when the rest of their staff doesn’t.  One powerful way to be sure the staff can address all the perspectives above, including the longer term, holistic enterprise view, is to elevate the Chief Architect to be a full member of the Office of the CIO.  If you have an EA function, but it is doing only the subset of enterprise architecture that we describe as “IT” architecture ( which usually means they reside several levels down in your organization)  then augment their skills and personnel and have them engage in the strategic and business-oriented discussions described above.  You will find them to be a valuable addition to your core team.

Stay tuned, we will be writing a lot more on the placement of EA in the Office of the CIO, the complimentary roles that exist in the Office, the dynamics, politics and culture of the team at that level, and the processes, perspectives, and leadership skills required for that team to support the breadth and depth of activities expected of the modern CIO.

My Take on the Q&A from the The Open Group Seattle Event …

I recently attended The Open Group Architecture Practitioner’s conference in Seattle.  During the event, I was given the opportunity to present a Keynote on the Language of Business Architecture, which I thoroughly enjoyed.  A couple of my peers, Mike Rollings of Burton and Henry Peyret of Forrester, were present and gave interesting presentations, as well as participated in a panel discussion, with Business Architecture themes.  There were several questions posed during the panel and Q&A sessions following their presentations upon which, surprisingly, I also had an opinion.  With apologies to Mike and Henry, I thought I would share some of them with our readers.   And George has an opinion or two, as well.

Q1:  If Enterprise Architecture as practiced by most is really IT Architecture and Enterprise Architecture is not a term that will be embraced outside the IT organization, what should we call it?

Tim’s Answer:  Although it is not as catchy, my first thought was Enterprise Planning & Optimization.  Until something sexier or more appealing comes along, this is my suggestion. 

George’s Answer: I can live with that and have never found anything better.  Several years ago, at successive Enterprise Architectures Conferences (EACs) I ran working group sessions to “rename” EA.  Each time, the group concluded that ”even with all the undesirable connotations of the name ‘EA’, we can’t come up with a better name”. 

Q2:  Have you ever seen EA report outside of IT?

Tim’s Answer:  To this point, I have not worked with a company that has the EA function reporting outside of EA permanently; however, I have worked with companies where the head of EA has had occasional assignments working for a corporate executive (not line-of-business) on strategic initiatives. 

George’s Answer: I have seen a few forward-looking organizations exhibit EA-like behaviors with notions like future state, enterprise principles, enterprise operating models (a la “EA as Strategy” – Ross, Weill, Robertson) as context, etc., usually within the enterprise strategic planning function.  They never call it EA, though.

Q3:  Do you see many EA groups with defined qualitative metrics?  What are they?

Tim’s Answer:  Most EA groups need to have some kind of metrics or KPIs in place, and as most of the benefits of EA are indirectly realized through the efforts of others (project teams, operations, procurement, etc.), they tend to be qualitative.  I have seen clients measure reductions in complexity and asset portfolio mix that have both qualitative and quantitative elements to them.  Perhaps the most common qualitative metric I see is a periodic assessment of EA maturity/effectiveness.  Organizations compare the ratings in different categories from one year to the next to see where they are improving and where they are lagging.

George’s Answer: I agree with Tim and would add that, occasionally, I see many organizations implement specific quantitative measurements because their HR systems require them to have something designed to evaluate individual and/or group performance.   These tend to be behavioral measures, not value measures.  Examples include completion of specific EA deliverables, or reducing the number of EA exceptions requested by projects.  The latter is achieved by creating appropriate reuseable patterns that have high utility across the enterprise, solving specific implementation scenarios in a repeatable way, through education and project coaching, etc.  The leadership team must believe that these behaviors will eventually drive desired outcomes in the company if the architect is to have any chance of representing these as legitimate metrics.  

Q4: In large organizations, line-of-business (LOB) architectures abound.  Is this an inhibitor or opportunity?

Tim’s Answer:  I think that it can be both.  If you do not create a unified, but federated, EA practice across the organization, then you run the risk that the LOB architectures are inconsistent, increasing cost and complexity overall.  Also, the LOB EA groups will tend to be more customer-focused, giving the LOB what they want, which makes it more difficult for Enterprise-level architecture decisions that are optimal company-wide, to be embraced at the LOB level.  This federated approach is what we see at most large complex organizations, so it must be turned into an opportunity to be successful.  Without leveraging the extended architecture community, the EA will probably be largely unsuccessful in large organizations.

George’s Answer: It could be both, but being a cup half-full person, I usually see it as an opportunity.  If even a small part of a large organization can do EA successfully, that’s good for them.  With luck, it will spread and grow to others.  If there are multiple LOB EA’ish functions, perhaps they will be able to identify opportunities for commonality and leverage, but only if that really makes sense for that particular company.  If critical mass or commonality never materializes at the big-”E” enterprise level then at least part of the company has embraced EA concepts.

Q5:  How do you define a business capability?

Tim’s Answer:  To me, business capabilities are the next layer of abstraction below business strategies and objectives,   defined as the capabilities that the business operations must deliver to achieve those strategies and objectives.  Since capabilities are usually defined at a higher level than requirements, there is more opportunity to find capabilities that cross organizational and functional boundaries.  This approach helps identify the areas to which we can architect, rather than getting right to the solution. 

George’s Answer: This is a tough one because everyone has their own interpretation.  The simplest one I have seen defines a capability as “the ability for an organization to perform a particular piece of work”.   I like it BECAUSE of its simplicity.  Of course, then one must be able to define “work”.   One example capability might be, in a product company, packaging and communicating product features to potential customers.  That capability manifests in the marketing function.

Q6:  Do you think the long-term future of EA is to merge or disappear?

Tim’s answer:  I think for the vast majority, the answer is neither.  Ultimately, EA is all about leadership – providing it and being recognized by it.  It seems to me that the leadership of most organizations is interested in surviving, keeping the status quo, and being tremendously risk averse.  In those kinds of circumstances, I see EA following the enterprise leadership and basically staying the same.  Those organizations that truly embrace EA’s transformational capabilities and allow it to reach its potential may end up creating a hybrid version of EA – one part that continues the traditional IT architecture leadership under the CIO called EA, and one part that merges into the executive offices to provide leadership in planning and strategy, called something other that EA, perhaps Business Architecture (but I kind of doubt it).  In these cases, there will be a strong relationship and integration between EA and BA. 

George’s answer: I have long maintained and continue to be of the opinion that a well-run EA program “melds into” and becomes part of the management and decision-making fabric of the enterprise.  It isn’t EA itself that we ultimately care about – it is just the name we are stuck with to represent a future-oriented, holistic, business driven, enterprise-wide context that informs decision-making.   What we really care about is the installation of those EA-like concepts, behaviors and an enterprise context into how the enterprise works – whether it is called EA or not.   By the way, I think we are a long way from this happening for anything more than a relatively small fraction of organizations.

Let us know what you think.

Business Architecture Discussions Continues with The Open Group Seattle Conference

Last year I mentioned that I attended The Open Group Architecture Practitioners Conference In Toronto and that I was very excited about the direction that the conversations went – namely the need for EA to become more of a strategic business discipline.  This month, I attended the version of this event in Seattle.  Again, I was encouraged.  This time by the theme moving past need and into practice.  The plenary sessions, which are the general sessions that are open to Open Group members and non-members alike, all focused on moving EA away from IT and towards the business.  With titles like “Changing the Conversation” and “The Language of Business Architecture” it is obvious that the conference tried to get people to think differently.  Some of the side tracks also promoted this concept, such as “Business Driven SOA,” “Translating Business Speak into IT Speak” and “Presenting EA to C-Level and The Board.”  Hopefully, they will continue and others will follow. 

My presentation was part of the “Language of Business Architecture” session, focusing on the dynamics and language of Business Architecture as it evolves from a commonly-accepted, but scarcely-executed domain of EA into a necessary part of a compelling and successful business transformation effort.  The presentation is available here. 

Also, following my presentation, Dana Gardner of Interarbor Solutions interviewed me for the BriefingsDirect series.  The topic of the conversation centered around the points that I made during my presentation on the language of business architecture, relaying the effectives ways that organizations can become successful in the development of transformational enterprise business architecture.

Click here to listen to the podcast.

Click here to read the transcript.

CIO Forum in Chicago: EA Benefits Session and Panel, April 6/7

George Paras has been invited to join Leon Kappelman, Editor of “The SIM Guide to Enterprise Architecture” (a project of the SIM Enterprise Architecture Working Group (SIMEAWG)), in a session on EA benefits at the upcoming Chicago CIO Forum & Executive IT Summit to be held at the Renaissance Schaumburg Hotel & Convention Center on April 6 and 7, 2010.  

The session will describe how using enterprise architecture (EA) concepts can yield specific benefits for organizations. We explore several real world examples where starting small, or with “slivers” of the overall architecture, can win over business executives by demonstrating real value. We also show how EA capabilities can be built upon the current skills of IT staff and how organizations can develop an EA capability that provides both short- and long-term value to the organization. Session concludes with an interactive panel discussion, question-and-answer session with attendees.

I look forward to seeing you there.  If you can’t make the event, please contact me via our website contact page to arrange a time to talk about how to apply these concepts to your own organization.

The SIM Guide to Enterprise Architecture  – Edited by: Leon A. Kappelman. This book is a project of the Society for Information Management’s Enterprise Architecture Working Group.  EAdirections has been a member of this important group since its inception.  The book reflects the research, analysis and thought leadership of a rich and diverse set of contributors.  

Look for the EAdirections chapter on A Pragmatic Approach to a Highly Effective Enterprise Architecture Program.

Architecture Readiness? What is that?

Recently I saw a question posted on a popular EA forum, asking about detecting the “architecture readiness” of the poster’s organization.   That got me to thinking about what we mean about “readiness” and is it that relevant anymore.  I admit that in the mid-90′s we would discuss the notion of an organizations readiness to embrace EA, but my perspective has changed drastically.  I think that the question is no longer “Is my organization ready to embrace and support EA?” but rather “How can I be effective in utilizing an EA approach in my organization?”  Clearly, the issues demanding EA support are still prevalent and the maturity of EA as a discipline has increased during the time since the mid-90′s. 

I do not believe that any EA function can be diagnosed quickly, as most of the issues regarding “readiness” are probably a unique combination within a company.  It starts with identifying the leverageable strengths, obstacles to overcome, and methods of mitigating those obstacles – including awareness at the executive level.  I don’t believe that any organization is completely “unready” for EA, but there are certain factors that are a quick read into how long it will take for EA to be a valuable, recognized formal method of helping the organization plan, rather than just a glorified design standards group.  Key among those factors is the understanding of and desire for EA as a strategic planning discipline by the CIO first, and the rest of EA management, second.  Many times, it helps to build some of the context level artifacts BEFORE you attempt to build executive awareness as those artifacts can be a very powerful part of the argument.  There are other activities (communication, collaboration, process integration, separating and defining roles and responsibilities among different architecture levels, and governance to name the most important) that all work together to establish a culture of EA – which is really what we are talking about here.

Hold the Date! – George Paras Keynote at Denver IASA ITARC on May 6, 2010

In a keynote presentation at the upcoming IASA ITARC Denver Event I will be discussing  the leadership challenges that many current and aspiring IT leaders face in their organizations, and how they can overcome those challenges by applying selected enterprise architecture concepts to their decision-making framework.  Not surprisingly, I advocate moving EA “upstream” within the management structure and expanding the context to make it more relevant to the business.   Doing so isn’t easy.  It requires a combination of skills in leadership, process integration within the Office of the CIO, and appropriate content in business and information architecture.   In this session attendees will learn how to get started on this journey.  

If you are in Denver and plan to attend, please let us know.  We’ll be available to discuss  ideas with any organization interested in expanding the scope and reach of their EA practice into business-oriented EA. 

The International Association of Software Architects (IASA) is the premier association focused on the architecture profession through the advancement of best practices and education while delivering programs and services to IT architects of all levels around the world.  The IT Architect Regional Conference is the first event in Minnesota to address the pressing needs of IT architects today. There are 12 seminars and two tracks separated by specialty: Enterprise and Fundamentals. Architects of all levels can take their skills to the next level.