George Paras and Tim Westbrock featured guests on A&G Webinar Nov. 16

Join George and Tim for a webinar on November 16, hosted by A&G Magazine.  We’ll also be joined by special guest Dave Baker, a longtime friend and industry colleague from PwC.

We’ll review the findings from the A&G 2011 Year-End Survey, discuss trends we see shaping the role of enterprise architect going in to 2012, and answer listener questions.

Follow this link to the Architecture and Governance Website for more information and to register.

EA Tips – Style AND Substance

For an EA practice to be effective EA leaders must pay attention to both the “style” of how their team operates and the “substance” of the work they produce. While that guidance isn’t new, in practice I often find that many leaders don’t have the balance quite right. It is worth revisiting as a general EA Tip.

First, what do I mean by “style” and by ‘substance”? (note: I chose those words because it sounded like a catchy blog title) For the sake of this article, I define “substance” to be the “work product” of the team as viewed by EA consumers wanting hard deliverables like frameworks, models, standards, roadmaps, strategy papers, and other related content. “Style” refers to “how” the team works with the rest of the organization in creating and utilizing their content: engaging business and IT leadership, fostering a collaborative environment; choosing communications vehicles, the words they use, and the “posture” of how they present themselves to the rest of the organization.

Many EA teams disproportionately direct more effort to the substance of the work than to building a sense of ownership and socializing the desired changes. In essence, they under serve the “style” elements. Granted, substance is critical. No matter how good the soft skills are or how convincing the leaders are, if the content isn’t solid then nobody will follow. But what is more surprising to many teams is that even the most elegant and perfect deliverables often don’t have impact. Why? – Because the team hasn’t positioned the larger workforce to embrace enterprise architecture content and to use it in their day to day work.

Improving the EA team’s style is often where we spend time with clients, specifically working on the “art” of practicing EA. Though many EA’s wish there was a methodological approach to these softer elements, there really isn’t one that works in all cases. People, perspectives, culture, and individual skills vary widely from organization to organization. One approach is to look to lessons learned from the organizational change management discipline, particularly as they apply to driving change across and down into an organization. There are tried and true techniques for preparing organizations for change, conducting education and awareness campaigns, gaining support and participation, and communicating effectively through a variety of different channels. After all, one of the valuable outcomes from EA is helping an organization move from an emphasis on tactical execution and silo behaviors to one that includes a larger, enterprise-wide strategic element. Substance is great, but style really does matter.

EA Tips – Substance OVER Structure

If you read my post on “Style AND Substance” I stated that an EA team shouldn’t spend disproportionate energy on content creation without also paying attention to the many softer, stylistic elements associated with leadership and influence. One without the other and the team will fail. In this “EA Tips” post on “substance vs. structure” I offer that an EA leader should worry only slightly about organization and team structural issues and spend as many cycles as possible jump starting the EA team and getting them to work together to produce meaningful content (strategies, standards, roadmaps, etc.).

Every EA team I work with these days is overloaded. I believe that much of the time spent worrying about structure and organization is time better spent elsewhere. Yes, I know that there are just some HR issues that must be addressed, team members need job descriptions and performance plans, and frankly most people won’t even join a team unless they have a reasonable understanding of their responsibilities and how performance will be recognized.

Beyond that, though, I find that many leaders find themselves slicing and dicing roles too finely and creating a lot of unnecessary work for themselves. In fact, doing so often works against the team and inhibits their ability to be effective. The team becomes just a container for a collection of individual contributors, basically working alone and rarely interacting. The very essence of EA is that everything, in some way or another, depends on everything else. The more you separate coverage areas, the more difficult it is to stitch it all together.

Basically, I am saying to not sweat the organizational issues any more than you must to get a few strong players onto your core team. Don’t be too concerned about segmenting responsibilities discretely among domains. Let individual assignments adapt to the content needs of the enterprise and allow your core group to float among them, learning, growing, and sharing perspectives. Encourage everyone to work together as a team and dynamically rotate individual leadership and deliverable assignments. The team will be better off and the members will be as well, plus less time will be spent deciding who does (and doesn’t) do what and more time will be spent on results.

IASA Chicago Chapter Inaugural Event April 7- George Paras Featured Speaker

Thursday evening, April 7, marks the inaugural event for the new IASA Chicago Chapter.  The meeting will be from 6:00pm-7:30pm at Illinois Technology Association (ITA), 200 S. Wacker, 15th Floor, Chicago.  The new chapter provides a networking and educational forum for IT and Enterprise Architects from across the Chicago area.  I will be leading a session on “Changing Architects’ Conversations”, sharing tips and techniques on how architects can create and take advantage of opportunities to engage enterprise leadership in strategic conversations.

In addition to speaking at the event, I am honored to have been asked to serve on the Advisory Board for this new chapter.  Please invite your architecture colleagues to come and join us!

Event and Registration Details

Improving EA Team Performance

With the arrival of the New Year, many EA teams are in the final stages of setting their annual objectives.  This year, we find that many are being asked to perform at a level significantly higher than last year.   They must do so in response to higher expectations placed on them by leaders who believe that EA plays a critical role in moving the enterprise into the future.  

Many annual objectives documents are primarly structured as lists of projects  and deliverables that the team must complete in the next planning period.   While hard deliverables are necessary and expected, every EA leader should also consider adding objectives designed to improve team performance and to address “how” the team is going to accomplish their assignments.   Why?  Because EA success requires predictable and consistent performance by the team as a whole and by its individual members.

One of the most interesting observations from studies of EA team performance is that the typical team profile of a collection of highly skilled and specialized individual contributors isn’t necessarily optimal.  To be successful, teams populated that way must learn to function as a team, supplementing the natural tendency for individuals to work alone.  Enterprise architecture is inherently cross-domain in scope.  Only by working in collaboration across domain specialites will the team be able to quickly address the many dependencies that are part of the modern enterprise.   

We recommend that EA leaders employ the following techniques when striving to improve their overall team performance:   

Develop a common language: Words and concepts are important.  Adopt/adapt a “language of EA” that makes sense for your organization.  A common grounding in EA core concepts can go a long way to unifying a team.  Look to the more widely used and common industry approaches to EA, take a class, or ask us.  We’re happy to make recommendations on practical approaches that will work, and show you how to adapt them to your needs.

Be a Team: Get together frequently, in person and/or virtually.  Eschew “project status reporting” meetings in favor of strategic discussions, cross-domain issues resolution, trend analysis and healthy debate.

Collaborate and Communicate: Actively recruit and engage external parties and bring them into the discussion.  Learn to exploit “social media” style connections to engage with these larger audiences. 

Learn to Lead: EA is a “lead through influence” discipline.  Take a leadership course, but be careful to select one focused on “soft” leadership styles.  It isn’t about traditional personnel management techniques.

With people as the critical element to EA success; it only makes sense to invest in team skills and performance.   Unfortunately, many teams put disproportionate emphasis on templates, frameworks and deliverables.  Make it a practice to visit/revisit the health and productivity of the team.  Don’t wait until next January to start.

Enterprise Architects as Change Agents

Last week I read a blog post by Rosabeth Moss Katner talking about Leadership and seven sayings that can guide and comfort those trying to drive change.  It was a good post and I tweeted it along with the comment “good advice for enterprise architects and other change agents”.   Since we began our interest in EA, Tim and I have embraced the slogan that “Enterprise Architects are Change Agents” and have used it as a theme when coaching and teaching. 

Lately, though, it seems that many EA practitioners don’t understand what the concept of “change agent” is all about and/or how to make it real, or are comfortable or constrained to only work on change at the micro (project, product, system, etc.) level vs. the enterprise level.  I wanted to take this opportunity to reinforce the concept that being an effective enterprise architect often means acting as an agent to drive large-scale change into your culture, influencing larger communities of people to engage, interact and make decisions in a non-local, non-micro “enterprise” way. 

The quotes Ms. Katner’s selected for her blog post are from herself and also from various literary and historical figures.  They are spot on and highly relevant to the EA community, specifically as applied to our role as leaders and change agents.  Some examples:

The quote from the Cheshire Cat in Alice in Wonderland that “If you don’t know where you are going, any road will take you there” speaks directly to the main focus of our work. Creating a coherent (and “business first” – see Tim’s accompanying post) future state enterprise architecture becomes the target that all paths must lead to.  Engaging leadership in discussions about the substance and form of that future state is the key to success here – finding the context and the opportunity is the tactic and there are many possible approaches.

The quote from Yogi Berra that “when you come to a fork in the road, take it” implies that we as enterprise architects sometimes must “stir the pot” and experiment, to not be afraid to float ideas before they are fully baked and see where they lead.  The fear of making mistakes is often so intrinsic that it paralyzes many of the EA teams that we have helped over the years.   Today, with internal social networking, many organizations now have vehicles where open, lower-risk exploration and trial-ballooning can occur.

Becoming an EA cultural change agent isn’t for everyone, but many reluctant practitioners have discovered that they are capable of doing it, once they embrace some of the concepts described here, practice them, and become confident in their abilities.

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

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).

Name(required)

Email(required)

Website

Message

EAdirections speaking at AOGEA Collaboration Event in Southfield, MI

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.

Name(required)

Email(required)

Website

Message

What Every EA Leader MUST DO – This Month!”

Now that everyone is back from the holidays, relaxed and enthusiastic, it is a good time to take a look forward and update your EA program’s objectives for the new year.  In our experience, most organizations have a very short window to accomplish this.  It doesn’t take long before the enthusiasm and vision for the future is replaced by the urgency and narrowness of the day.  Since creating a coherent future target-state view is the core idea that drives what the EA program does for the organization, it makes sense to use this moment of clarity to apply that same concept directly to the EA program itself.  Doing so should drive the evolution of your EA program throughout this year and into the next.

Begin by answering a few simple (OK, not so simple) questions: What would you like your EA program to look like a year from now?  Two or three years?  How would you like it to work?  Who needs to be engaged? How are we going to create value to our organizations?  Those are your goals, driven by your vision. These are just a few of the many questions to be answered before jumping in and creating detailed work plans.  It has to drive you to achieve your idea of what a smoothly running program should be and to the level of value delivery you want for your organization. 

Only then can you lay out the granular steps along the path to get there.  Those become the objectives.  This exercise doesn’t have to be hard.  It doesn’t have to be an exhaustive and thorough definition of tasks and highly detailed sub-tasks, with explicit milestones and work allocation down to the hour.   Watch out to not fall into that trap.  Many organizations expect it, but a project plan with that level of detail often becomes a burden that inhibits EA evolution instead of enabling it.  There are many reasons why EA isn’t well-suited to that level of detailed planning, many of which are unique to a particular organization.  Call us if you are interested in exploring those reasons and why they may apply to your organization.   In all cases, though, the continuous improvement of an EA program does require a thoughtful and meaningful planning activity.  What’s really important is to build a plan to a level of detail that supports your long term objectives balanced with more immediate value opportunities.

Here are a few examples of what our clients are planning for the year:

• Expand the reach of the EA program within the organization.  Using a variety of tactics that include active recruiting, more effective personal networking, public relations activities, etc. it is important that a larger community of individuals contribute content and ideas and then, indirectly, begin to see the value in the work that the EA group performs.  An important note – “teaching” people about EA is less important than involving them in EA activities.
• Enhance governance bodies and processes to include a higher-level, cross-organizational perspective.  Too often, EA is buried too deeply into narrow, infrastructure concerns within IT.  Will business people care about things like network/integration topography choices and standards taxonomies?  Probably not, so you have to work in areas that they really will care.
• Expand the scope of EA.  With some recent nudging, the best EA groups have pushed into the business domains, to take into account the full holistic breadth of enterprise concerns, particularly business, information architectures and application portfolios.
• Balance the workload between strategic, future state development and align with current state priorities.  Our clients are either facing major initiatives (ERP implementations, major business process transformation) or economic pressure causing significant budget and resource constraints or both.  They need to balance strategy work with contributions to efforts with immediate results.

Objective setting isn’t easy.  You have to pick the “right” objectives.  Then you have to determine the right order, and to what degree, to apply them.  An “EA Capabilities Assessment” is a helpful place to start.  Unlike an “EA Maturity Assessment”, if is actionable and can directly reveal your strengths and what weaknesses you must overcome.   Doing full-year objective setting well requires a combination of insight into organizational dynamics, understanding what your resources are capable of, and how much change your organization can tolerate.   This is one place where our experience can help.  As you think about the coming year, contact us.  We’ll be happy to discuss approaches that make sense for you and your organization and give you more insight into what is achievable.

Assessing EA Maturity isn’t all that helpful – Here’s a Better Approach

Most current discussions on EA Maturity focus on backward-looking metrics and score them based on levels that are similar to the Capability Maturity Model (CMM) process improvement system developed by the Systems Engineering Institute at Carnegie Mellon University.  Over the past several years we have started to develop a different opinion about using CMM-type assessments for enterprise architecture processes.  Here’s why:

1.       CMM was originally developed for project-level systems engineering capabilities. While some of the concepts are applicable to an enterprise-level planning process, the measures of success are not. Systems engineering is more tangible such that improved process maturity results in more successful outcomes. The same is generally not true of EA.

2.       After many years of experience conducting CMM-like assessments, it became clear that the exercise of collecting the responses to questionnaires aimed at rating EA capability maturity on a scale of 1 to 5 rarely resulted in any kind of consensus on levels of maturity.  That exercise usually led to some very valuable discussions, but the rating itself was far too subjective and inaccurate.

3.       The measure of maturity itself tends to rise with age; however, the outcomes may or may not be improving as maturity increases. 

For most organizations  it is better to accept the subjective nature of EA and assess the capabilities of an EA program, not its maturity.  The goal is to identify how effective the program is within the organization.  The categories are similar to the ones that are traditionally seen in EA maturity, but adjusted to measure against a scale ranging from “significantly inhibits effectiveness” to “significantly enables effectiveness”. 

This type of assessment is a step forward in helping an EA team to better understand its opportunities for improvement, the obstacles to overcome and its leverageable strengths.  The best measure of success is still going to be the impact on shareholder value.  Being effective is a surer path to increasing shareholder value than being mature.