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!
I had the opportunity last week to moderate two panels at the Troux Worldwide Conference. The first panel included EAdirections’ Tim Westbrock along with Mike Walker from Microsoft, Aleks Buterman from SenseAgility and Paul Preiss from IASA. The theme of the panel was a general discussion on characteristics of top-performing EA Teams. To begin the conversation, I asked each panelist to describe what a top-performing EA team meant to them. What I had originally believed to be a softball question that would show the breadth of issues and perspectives on EA turned out to be more controversial than I had expected.
The panel became caught up in the role of EA and the role of IT architects. Unfortunately, the conversations became focused on the differences in the roles instead of how they work together, diving too far into a differentiation of the “primary” roles and skills of each. It revealed some of the confusion around EA and shone a light on many of the issues that practicing enterprise architects must deal with on a daily basis. What I had hoped would be a conversation addressing how the EA function must be multi-purposed, strategic and tactical, business and IT-oriented, and with an eye to both short and long-term value delivery became overly focused on narrower perspectives. We had a few rough spots as we worked our way through the session, but luckily we ended well. We landed at the recognition that while the roles are different they share some common skills and, after all, they should be collectively working to achieve positive results for their organizations. Individuals in both of these roles will inevitably be working closely with each other.
Personally, I believe that the biggest part of being a top-performing EA team is learning to strike the right balance across the perspectives listed above. It isn’t about doing just one thing or having a “primary” concern as much as it is about how well the EA leaders cover the bases, shifting emphasis from strategic, business-oriented concerns, to helping certain initiatives head down the right path, and then back again as dictated by the situation. It is about breadth, and reach, and longevity.
In future posts Tim or I will examine several of the questions asked by the audience, some answered by the panel and others that we didn’t have time to address.
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.
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.
Most organizations that claim to have an “enterprise” architecture practice are really only doing “IT” architecture (ITA). What leads us to say that? Our research shows that most organizations have limited their scope to include only IT elements like infrastructure, data and applications. That’s OK in and of itself and it is a step up for many organizations, but that’s not EA. Most definitions of EA define it as creating a business strategy driven future state for the enterprise. To achieve that goal, EA must include Business Architecture.
In a keynote presentation at the upcoming IASA ITARC Atlanta Event titled “Don’t Call It EA if It Isn’t EA!: Moving from IT Architecture to Enterprise Architecture”, Tim and I will continue the discussion he began in his blog entry last year, one of our most read and most commented entries. We plan to explain the rationale behind this statement and share a few tips with attendees on steps they can take to move to a more fully realized EA practice.
If you are in Atlanta and plan to attend, please let us know. We’ll be available to discuss ideas with any organization interested in moving 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.
“Enterprise Architecture (EA) is an immature discipline and possibly getting even more immature. As the scope of EA extends beyond the areas that IT-centric efforts are prepared for (data, app, infrastructure), the competency, credibility and effectiveness of an EA team may decrease. However, there are a variety of ways to increase these characteristics for EA teams, regardless of the stage of maturity in which you may find yourself. “
That is the theme of a presentation, entitled “EA Profession: What’s Changing and What’s Not?”, I will deliver at the upcoming IASA ITARC event in Austin on Thursday, February 4. The discussion will feature a lively discussion about my assessment on the state of the EA profession, what I see going on in the industry that helps and hinders the evolution of the EA profession, and what else to expect in the future.
If you are in Austin and plan to attend, please let me know. I’m always interested in talking with other enterprise architects, those that aspire to the role, and IT Leaders interested in having an EA function in their organization. There will be plenty of opportunities for discussion and Q&A, including at an evening reception.
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.
“Enterprise Architecture (EA) is an immature discipline and possibly getting even more immature. As the scope of EA extends beyond the areas that IT-centric efforts are prepared for (data, app, infrastructure), the competency, credibility and effectiveness of an EA team may decrease. However, there are a variety of ways to increase these characteristics for EA teams, regardless of the stage of maturity in which you may find yourself. “
That is the theme of a keynote presentation, entitled “EA Profession: What’s Changing and What’s Not?”, to be delivered by George Paras at the upcoming IASA ITARC event in Minneapolis on Friday, November 13. The discussion will feature a lively discussion about his assessment on the state of the EA profession, what he sees going on in the industry that helps and hinders the evolution of the EA profession, and what else to expect in the future.
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.
Over the last several months we have seen a measurable increase in companies recruiting Enterprise Architects and Chief Enterprise Architects. While we are not in the recruiting business, nor do we track hiring the way an HR research company would, with EA as our specialty we do tend to get information first-hand. Our clients regularly tap into our expertise to help them justify the need for these positions, to define roles and responsibilities, to craft and review job postings for their HR organizations, and to provide general input to the hiring manager. We’ve even had occasion to speak directly to HR departments to help them better appreciate the EA role and help them be more effective in the recruiting process. Professional recruiters also tend to send requisitions our way as well, hoping we might know of potential candidates. Collectively, these discussions give us insight not only into currently available positions, but also those that will soon open. Furthermore, we have a unique perspective on the rationales behind the recruiting.
The increase we see is good news on several fronts. First, any hiring activity is positive. Our narrow, unscientific and anecdotal data hardly qualifies us as economic commentators, but we can say that it at least suggests that some degree of confidence is returning to the private sector. Second, the new positions we are seeing are for legitimate “enterprise” architect roles, specifically created to lead and coordinate a forward-looking, enterprise-wide, holistic pespective and to ensure that it is actionable and applied to today’s projects. This is distinctly different from the many specialty infrastructure, data, solutions, etc. “architect” roles which tend to be more subject-matter and delivery-specific. And the third piece of good news; it indicates that senior leadership understands and appreciates the distinction between enterprise architects and other architects, that they want what EA does, and that they can justify and attach expected value to having individuals in the EA role.
With every good piece of news, there is inevitably some bad. Yes, many so-called “EA” postings don’t read anything like what an enterprise architect role should be. Unfortunately, many companies recruit for enterprise architects to be chief technicians, and others believe that an enterprise architect is nothing more than an architect that works on “really big projects”. So, read between the lines if you are looking for an EA position. Also, while many companies will accept internal applicants for these roles, most are external postings. That reflects a general belief that the right skills and vision needed for EA are not available internally. The message for those interested in EA positions at your own company and currently in another role: even if there is not an internal “EA” position currently available, be sure to exhibit the skills necessary for that role. Now is the time to distinguish yourself, not after the job is posted.
We are interested in your thoughts and observations on EA hiring activity. What are you seeing out there? Comments are open below. We’ve also created a short, unscientific poll. I’ll let you know our findings in a future post.
George Paras will join the Winnipeg IT Architects Community’s October 8th meeting to share his experiences and perspectives while leading an interactive discussion on several topics requested by the Community. Topics will include establishing and maturing an EA practice, finding and growing enterprise architects, and key strategies to establishing and operating practical and appropriate governance mechanisms to link planning and the project portfolio with EA. He’ll also discuss his observations on the growing interest in EA by executive leadership and the higher expectations that they place upon their EA groups. As a result he has seen an uptick in new EA programs, the renewal/re-launch of past EA attempts, and increased hiring of enterprise architects.
Contact George Paras if you are interested in more information or in scheduling a similar session for your group.
We have a lot of work to do on our relationships! Fully 71% responded that the relationship doesn’t exist or that there is room for improvement. There is some good news though – 57% at least HAVE some sort of relationship that needs improving and 29% consider the state of their relationship to be “healthy”.
Here is an excerpt from an offline comment that I found particularly relevent and insightful:
“I’d say you are spot on with your observations and I think you need to let both groups know that an enterprise architect is fundamentally a differently-skilled person than a project manager. As you point out, an EA is concerned with the future, the long-term strategy and the big picture. A project manager is concerned with the here-and-now, budgets, resources, details and “the little picture”. An EA must be aware of all projects in the organization, and makes decisions regarding how one project can easily affect another – and maybe not in a good way. Project managers are under huge pressure to manage the scope to the budget and the timelines, while EAs are not.
My point is that an EA thinks dramatically different than a PM. Both the EA and the PM need to understand and recognize this and build on the differences and not let those differences destroy the relationship, and certainly to not jeopardize either a project’s goals nor the enterprise IT strategy.”
Well said. The writer asked to let both groups know; consider it done!
Thanks to all again that had interest in this topic. Comments are open if you have any additional ideas.
Posted by George S. Paras 
Top-Performing EA Teams – A Panel Discussion
March 30, 2011I had the opportunity last week to moderate two panels at the Troux Worldwide Conference. The first panel included EAdirections’ Tim Westbrock along with Mike Walker from Microsoft, Aleks Buterman from SenseAgility and Paul Preiss from IASA. The theme of the panel was a general discussion on characteristics of top-performing EA Teams. To begin the conversation, I asked each panelist to describe what a top-performing EA team meant to them. What I had originally believed to be a softball question that would show the breadth of issues and perspectives on EA turned out to be more controversial than I had expected.
The panel became caught up in the role of EA and the role of IT architects. Unfortunately, the conversations became focused on the differences in the roles instead of how they work together, diving too far into a differentiation of the “primary” roles and skills of each. It revealed some of the confusion around EA and shone a light on many of the issues that practicing enterprise architects must deal with on a daily basis. What I had hoped would be a conversation addressing how the EA function must be multi-purposed, strategic and tactical, business and IT-oriented, and with an eye to both short and long-term value delivery became overly focused on narrower perspectives. We had a few rough spots as we worked our way through the session, but luckily we ended well. We landed at the recognition that while the roles are different they share some common skills and, after all, they should be collectively working to achieve positive results for their organizations. Individuals in both of these roles will inevitably be working closely with each other.
Personally, I believe that the biggest part of being a top-performing EA team is learning to strike the right balance across the perspectives listed above. It isn’t about doing just one thing or having a “primary” concern as much as it is about how well the EA leaders cover the bases, shifting emphasis from strategic, business-oriented concerns, to helping certain initiatives head down the right path, and then back again as dictated by the situation. It is about breadth, and reach, and longevity.
In future posts Tim or I will examine several of the questions asked by the audience, some answered by the panel and others that we didn’t have time to address.