Characteristics of Effective EA

February 9, 2011

There are a few characteristics of an effective Enterprise Architecture (as well as IT Architecture) practice and its artifacts that must be established and maintained throughout its existence.  In order to be effective, EA and ITA need to influence investment decision-making at the portfolio level.  This means being able to show the impact of investment alternatives across the enterprise, on other investment choices (including current investments) and over a longer period of time than just the current and next budget cycle.  Regardless of goals, objectives, industry, size, or stage of maturity, these 5 characteristics are necessary for effective EA and ITA to influence the investment portfolio:

  • Business Driven
  • Forward Looking
  • Enterprise Breadth
  • Maintains Linkages
  • Proactive

Business Driven:  In order to be business driven, the EA program needs to involve professionals with an understanding of the operations and the executive leadership of the organization.  If you are architecting an enterprise, then your primary audience is the group of individuals with overall responsibility for the enterprise as a whole.  Your artifacts need to be able to communicate at the executive level, as well as create a forum for collaboration on the impact of strategy on the operations of the organization.   HL context models, relationship maps  and strategic capability change analysis are the deliverables that represent this characteristic.

Forward Looking:  Too many EA programs attempt first to impact implementation level decisions and projects.  While this is not only futile (one an effort is at the implementation level, EA impact is minimal at best), but also potentially dangerous.  Without an idea of the long-term direction of the business processes, information assets, business systems and technology, what meaningful and systemic guidance can EA or ITA provide at the implementation level, or even at the design level.  The architecture as a whole must be based on a consistent and portfolio-oriented view of how the enterprise will evolve as a whole over time.  This only comes from looking 3-5 (or more in some instances) years ahead.  Roadmaps are the deliverables that represent this characteristic.

Enterprise Breadth:  Many organizations have a history, sometimes successful even, of silo-oriented decision-making.  However, as complexity has increased and rates of change have decreased, the impact of silo decisions is being felt by these organizations.  And it is usually not a good feeling.  To combat this, EA must have an enterprise-wide scope to help senior executives understand the impact of decisions in one silo on other parts of the organization, because within the silo, this is not easily recognized.  And for the most part, if this perspective is not maintained by the EA group, it may not be evident anywhere.  This characteristic should be represented in all types of EA deliverables, providing the context to link artifacts from other levels of architecture (domain, solution, etc.), as well as planning  and development activities.

Maintains Linkages:  To increase the impact that the previous characteristics can have on overall effectiveness, the EA must establish and maintain both vertical and horizontal linkages in the participation and deliverables of the program.  EA is not responsible for the creation of every planning, design and modeling artifact in the enterprise.  But to increase the value of the lower level artifacts, as well as enable the impact of business driven, forward-looking, enterprise wide activities and deliverables; linkages across silos and domains and between levels of architecture must be established and maintained.  These linkages are generally represented in the overall EA meta model.

Proactive:  As I mentioned earlier, many architecture activities are focused on implementation and project level details, which is too late in the life-cycle to have meaningful impact without the benefit of process and artifacts that reflect the above characteristics.  Please don’t misunderstand my message.  EA needs to be able to impact the implementation and project level decisions, but not in the reactive way we see it happening in many organizations.  By creating teams, process and artifacts that are business driven, forward-looking, enterprise wide and maintaining linkages; EA can proactively impact the mix of projects and the implementation level design, technology choices and integration BEFORE projects are even started or implementation decisions are made. 

The true test of EA effectiveness is the ability to change implementation level decisions based on a reflection of what is in the best interest of the whole enterprise.  Without these 5 characteristics present, an EA program will struggle with that test.


Updated Registration Info – EAdirections speaking at AOGEA Collaboration Event in Southfield, MI

September 1, 2010

UPDATE: It is still not too late to join us at this multidisciplinary event in Michigan.   A Registration Site is now available with full event details and information on how to register.  Allen Brown, CEO and President of The Open Group will be delivering the opening keynote presentation.  If you have any questions, or would just like to chat before the event or on-site, drop us a note via the attached form.

George Paras and Tim Westbrock are scheduled to speak at the upcoming Collaboration Event sponsored by the AOGEA Michigan Chapter (Association of Open Group Enterprise Architects) on September 16, 2010 from 2:00 PM to 7:00 PM at Lawrence Technological University in Southfield, MI.  The theme of the event is “Interoperability between various disciplines in an enterprise”.

In our session titled, “Don’t Call It EA if It Isn’t EA!: Holistic EA for a Tightly Integrated Enterprise” we’ll be discussing the dynamics of Enterprise Architecture as it evolves from an IT-oriented discipline into a necessary part of a compelling and successful business transformation effort.

This event is a collaboration between the AOGEA Michigan Chapter and the ABPMP SE Michigan Chapter (The Association of Business Process Management), itSMF Great Lakes Chapter (Information Technology Service Management Forum), and the SE Michigan IIBA Chapter (International Institute of Business Analysis).


Let the Budgeting Process Begin – EA’s Role

August 4, 2010

As the annual corporate budgeting season begins, we find ourselves again fielding client inquiries about the role that EA should play in this annual rite.  Like many such EA best practice questions, there is the EA purist answer and then there are the many variations of more practical answers.   

In an ideal world, enterprise architecture should have little to do directly with the annual budgeting process, per se, but instead be feeding the portfolio planning process.  We “inform” that process, which should be complete before the budgeting process begins.  The analysis of strategy and business capabilities enables the creation of a holistic enterprise architecture future state, and the comparison to current state charts a forward-looking roadmap and transition strategies.  That work provides the list of potential major investments, supplementing the list of projects that is the typical starting point for the investment process.  The budgeting process systematically transforms that list of “potential” investments into those that can be achieved in the next planning cycle based on available funds, resources, risks and business priorities.   EA’s role is to impartially analyze the list of potential investments and guide the organization through the implications of various scenarios.

From a practical standpoint the reality is rarely that straightforward.  For example, there often isn’t a portfolio planning process distinct from the budgeting process.  What the organization can afford, therefore, is a dominant constraint before strategic or even tactical outcome can be thoroughly analyzed.  The EA team must never be arm’s-length if our mission is to impact the choice of projects and guide the evolution toward the desired future state.  

Another reality is that, in many organizations, the future state is rarely well-formed.  As such, most EA teams must leverage the opportunities provided by projects already on the list.    Being active in the budgeting process is a fail-safe to learn about business opportunities they might not have seen, to gain new insights into the priorities of the organization, and to discover paths that will help bring potential future states into focus.

There are other answers to the EA role in budgeting question as well, not the least of which is dealing with management expectations.  How far enterprise architects should engage, and at what level, is situational and we’d be happy to discuss offline with anyone that is interested. 

Remember, EA should not be constrained by the list of funded projects but should focus on reconciling long and short-term interests.  We should never confuse or stifle the “out of the box” thinking that EA should provide with the realities of short-term investment and implementation decisions.  EA involvement in the budgeting process is probably too late in the overall investment decision-making continuum, but it can be a good place for the EA team to ask the questions that would demonstrate the need for more proactive and broader planning in the future.


EAdirections speaking at AOGEA Collaboration Event in Southfield, MI

August 4, 2010

George Paras and Tim Westbrock are scheduled to speak at the upcoming Collaboration Event sponsored by the AOGEA Michigan Chapter (Association of Open Group Enterprise Architects) on September 16, 2010 from 2:00 PM to 7:00 PM at Lawrence Technological University in Southfield, MI.  The theme of the event is “Interoperability between various disciplines in an enterprise”.

In our session titled, “Don’t Call It EA if It Isn’t EA!: Holistic EA for a Tightly Integrated Enterprise” we’ll be discussing the dynamics of Enterprise Architecture as it evolves from an IT-oriented discipline into a necessary part of a compelling and successful business transformation effort.

This event is a collaboration between the AOGEA Michigan Chapter and the ABPMP SE Michigan Chapter (The Association of Business Process Management), itSMF Great Lakes Chapter (Information Technology Service Management Forum), SE Michigan IIBA Chapter (International Institute of Business Analysis) and the local PMI Chapter (Project Management Institute).

Further details will be posted shortly on the AOGEA Michigan Chapter site or use the attached form to contact us for more information.


CIO’s and EA – Leadership Challenges in IT

February 28, 2010

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.


EA Value Contribution

December 1, 2009

What value does the EA function provide to the enterprise?  That question consistently ranks in the top ten list of most frequently asked EA questions.  The question, unfortunately, doesn’t lend itself to a simple answer.  It is more often a matter of value being in “the eye of the beholder”.   In other words, the answer to the question depends on who is asking and what answer they expect to hear based on their personal and professional interpretation of the word “value”.

A systematic, multi-part approach to addressing the value question can lend clarity.  By classifying the various ways that EA groups contribute value, and identifying the stakeholder communities and how they align themselves with those classifications,  each organization can address the value question in terms that are meaningful to their particular stakeholder mix.  In our experience every organization always has multiple value expectations. 

The weighting among various value contributors differentiates one organization from the next.  The weightings will change as the EA function grows and evolves.  To begin to answer the value question, lets define three possible value contribution classes.  These are focused not on what an EA function is, but on what it does for the enterprise:

Project Support:  In some organizations, value is defined exclusively by an individual’s direct contribution to the completion of project-oriented tasks.  While one can argue as to what proportion of individual EA team member’s time is directly or indirectly linked to project tasks, and it will vary by role, skill set and EA maturity, in the aggregate every EA team interested in long-term survival must make their contribution to project completion visible.  After all, it is the rare organization that doesn’t perceive “getting things done” as the highest value component.  As EA teams evolve, contribution to project success will become less hands-on, design-oriented and become more “guidance” oriented as the EA team uses its collective insight into the future state and roadmaps to inform project activities.  In these cases, getting things done “right”, in consideration of both project and enterprise requirements, becomes the operative value contribution.

Strategic Direction: The “raison d’être” of an EA group is to understand the strategic direction of the organization and capture it into a future state representation that reflects the eventual achievement of that direction.  For leaders that believe in EA, their expectation is that the EA organization will invest resources in creation of go-forward standards, patterns, platforms, models and other representations.  After all, an EA team cannot effectively and efficiently perform their “support projects” value contribution if they don’t have a basis to use in providing guidance.  Therefore, creating useable and prescriptive future state guidance, and communicating those directions to the project and asset communities, is a key value contribution that must be included in the mix.

Portfolio Transformation:  It is a rare organization, indeed, that doesn’t suffer from the accumulation of past incremental additions to its asset portfolios (technology, solutions, information, etc.).  Each addition was, at the time, fully justified and sensible in the context of the problem they were trying to solve.  Only upon retrospective analysis does an organization discover the burden those portfolios place upon them in the form of cost, resources, or inflexibility.  Given the future state holistic perspective defined by an EA function, a significant value contribution of EA is to help guide portfolio transformations to shed excess or duplicate components and bring them into alignment with the go-forward wishes of the organization.

By analyzing how the EA function can contribute in each of these categories, and by thoroughly understanding the expectations of stakeholder communities in each, the EA team can strike a balance that will satisfy itself that it is doing the right things, and demonstrate it to leadership as well.


Portfolio Management Still a Key to Realizing EA & IT Benefits

October 31, 2009

Enterprise Architecture as long been considered a planning discipline.  Many times when asked about the value of EA, people will comment with the old axiom, “What is the value of a plan?”  While there is certainly some inherent value in the artifacts, processes, and relationships developed by EA in and of themselves, the real benefits are achieved through the implementation of EA plans.  However, a conflict has always existed between the EA representation of a long-term enterprise view and the near-term bounded perspective of implementation projects.

For many years, well over a decade, we have been helping organizations overcome this conflict by developing a portfolio perspective of the many (sometimes hundreds or thousands) of implementation projects underway, approved and being considered.  While more organizations are attempting to maintain a portfolio perspective, there is still a decidedly immature approach to making portfolio decisions (managing the portfolio) from an enterprise perspective.

There are a variety of reasons for this:

  • Complexity / Volume of the project portfolio
  • Lack of tools in use to help organize / analyze the project portfolio
  • Lack of business participation / Perception that the project portfolio is an IT organization/CIO’s responsibility

The good news is that these problems can be overcome.  For instance, not every single unit of work defined as a project has to be accounted for in the portfolio.  Most successful portfolio management efforts include the creation of criteria for inclusing into portfolio analysis.  These factors can range from duration, budgeted expense, capital expense, and resource allocation to strategic impact, level of risk, ROI, and number of depencies. 

As organizations continue to mature their approach to portfolio management, they quickly find out that it is not all about realizing benefits from EA.  It is about making vastly better investment decisions for the enterprise.  The EA deals with the future vision of the enterprise.  The project portfolio management process, if done well with the input of EA, will provide a balance to fulfilling the immediate needs of the enterprise while also advancing the strategic vision of the business.


Follow

Get every new post delivered to your Inbox.

Join 177 other followers