Like every other analyst and blogger who was publishing last week, I thought my research report should reflect the year change. However, I’ve never been accused of being much like everyone else. So, instead of offering predictions, or a look back, I wrote on what I believe is a linchpin IT role for 2006 – the enterprise architect. But not your first generation, ivory tower, whiteboard bound enterprise architect. Rather, an enterprise architect that practices business-driven architecture – more on that in a minute.
What follows is the content from that report, slightly altered for the blog format. In future posts, I’ll offer some “architect brain food” suggestions (and share my own plans).
Introduction – IT Linchpin 2006: The (Business-Driven) Enterprise Architect
2006 is shaping up to be a big year for enterprise IT. After years of chasing cost containment and regulatory compliance, enterprises are funding initiatives to spur and sustain business growth. These initiatives take two forms. Some will drive innovation––in product and service offerings,channel and market strategies, and customer interaction. Others will strengthen critical business and information technology infrastructure. Nearly all of the initiatives will require enterprise IT participation and investment. As a result, CIOs at growth-oriented companies have increasing budgets and plans to hire.
While this infusion of investment is a welcome reprieve, CIOs are determined to invest wisely: in strategies, technology, and people that create an environment for business and IT agility, while keeping project expenditures and run rates in check. Some of the strategies include (but aren’t limited to) service-oriented architecture (SOA), event-driven architecture (EDA), process-based architecture, federated information, enterprise integration, and open source adoption.
At the start of 2006, as IT folks are formulating their hiring plans and professional development plans, I wanted to highlight a critical role for 2006: the enterprise architect. That is, the enterprise architect who practices Business-Driven Architecture.
Business-Driven Architecture is my view of architecture, developed on the premise that architecture is not an end, but a means, and the business must drive architecture composition. In Business-Driven Architecture, enterprise architects are not only responsible for articulating the architecture, but also for actualizing the architecture, and introducing the architecture into IT business projects. Business-Driven Architecture has a strong bias to action, business opportunity, and project and portfolio advancement.
For 2006, enterprise architects will be driving the foundational strategies (as mentioned above) that make sense for their businesses, while actively consulting with, and contributing to, the business growth initiatives. I believe a talented enterprise architect(s) is a linchpin to your 2006 success.
What does a great enterprise architect look like? How can you ensure his/her success? Read on.
The Business-Driven Enteprise Architect
The business-driven enterprise architect’s responsibilities go well beyond the whiteboard. They need to deliver the architecture (tools, practices, services, and infrastructure), and roll it out to project teams.
Over the lifecycle of an architecture initiative, an enterprise architect might play a variety of roles, including strategist, evangelist, architect, project leader, developer, mentor, and enforcer. Obviously, your enterprise architect needs to be versatile. However, they don’t have to be superheroes. Most organizations have multiple enterprise architects, who collectively and collaboratively provide coverage across the architectural domains––business, application, information, integration, platform, network, security, and systems management.
Enterprise Architect Attributes
I break the enterprise architect attributes out into four broad categories: domain expertise, industry awareness, architecture skills, and architect traits.
Domain Expertise. An enterprise architect should have expertise in at least two of the foundational architecture domains, and be conversant in all. The foundational architecture domains are:
•Business Architecture
•Application Architecture
•Information Architecture
•Platform Architecture
•Network Architecture
•Security Architecture
•Applications and Systems Management Architecture
Industry Awareness. An enterprise architect should be aware of, and able to form opinions on, emerging and prevailing trends in information technology and the enterprise’s industry. Examples of emerging information technology trends I would expect [1] an enterprise architect to be aware of are:
•The Role of Open Source in the Enterprise
•Web 2.0 and Software as a Service (Saas)
•Rich Interface Technologies (Ajax, Flex, Laszlo) and Usages
•Opportunities for Really Simple Syndication (RSS) in the Enterprise
•“Lesscode” Development Movements (REST, Spring, Ruby on Rails, PHP)
•Federated Identity Challenges, Standards, and Options
•“Triple Play” (Voice, Data, Video) and the Enterprise
•Google’s Strategies and Implications for Enterprise IT
Architecture Skills [2]. An enterprise architect’s skill set must include architecture practice expertise, great thinking capabilities, and strong people/professional skills. For an enterprise architect to be successful, he/she must be able to take a (valuable) idea from inception to implementation, gathering support along the way. Specific skills by category are:
Architecture Practices:
•Learn, Adopt, Tailor, and Teach Appropriate Architecture and Development Methodologies
•Set and Enforce Standards
•Identify and Apply Patterns at the Business, Architectural, Design, and Programming Levels
•Drive and/or Participate in Portfolio Planning of IT Assets (tools, infrastructure, applications, information stores)
Thinking:
•Visualize and Articulate the Big Picture
•Abstract Key Concepts from Detailed Problem Domains (Business, Architecture, Systems)
•Ability to Analyze, Synthesize, Question and Recommend
•Generate Creative Ideas and Solutions
•Possess Natural Curiosity
•Good Decision Making, Accounting for Fit, Risks, Rewards, Time, and Expense
People/Professionals Skills:
•Lead Formally and Informally
•Influence at all Organizational levels, Internally and Externally
•Facilitate Diverse Groups
•Mentor
•Collaborator
•Communicator (written and verbal)
•Self Motivated
Architecture Traits. Architecture traits can be described as either “Truths Great Enterprise Architects Work By,” or, “How to Spot One in the Wild.” If you find (know) an architect with these traits, find a way to work with him or her!
A Great Enterprise Architect…
1.Is not afraid to make mistakes, and always learns from them.
2.Knows one answer does not fit all problems. Understands any given problem may have many good answers.
3.Builds a community to create an environment of compliance, rather than one of enforcement.
4.Asks great questions that compel further discussion, research, collaboration and innovation.
5.Makes smart compromises, never boxing himself/herself in.
6.Doesn’t work on an island. Collaborates internally and externally. Researches opposite points of view.
7.Considers technology in terms of business benefits, rather than the technological cool factor.
8.Is equally effective in a leadership, collaborator, or follower role.
9.Thinks holistically, yet acts pragmatically.
10.Can innovate, simply.
Keys for Success
No doubt, individuals in enterprise architect positions are extremely self motivated, and in their minds, success is never in question. However, there are things CIOs can do to ensure their enterprise architect (and architecture) are successful. Here are seven actions you can take:
•Make Room at the Table for Architecture Leadership. The architecture leader must have a seat at the CIO’s table in IT leadership and business leadership settings. The architecture leader, particularly one with an architecture background, will listen and contribute to the discussions with an enterprise architecture perspective. Don’t filter his/her information through a leader with a non-architecture focus.
•Set Shared Goals for Your Architecture, Project and Portfolio Leaders. Reduce the natural tension between architecture, projects, and portfolios, by setting some shared goals related to initial productivity, asset utilization (re-use), and enhancement productivity.
•Fund and Resource the Architecture Team, Early. To realize the architecture, the architecture team must have development and engineering resources. Set this team in motion ahead of the dependent projects.
•Transition the Architecture Assets to Operations. As the architecture portfolio is built out and incorporated into projects, transition the day-to-day operations of the resulting tools and infrastructure to operations teams. Don’t lose your architecture team to operational tasks.
•Integrate Enterprise Architects and Project Teams. Reduce the natural tension between enterprise architects and project teams by having them collaborate on projects. Seed enterprise architects into your project teams, particularly in pilot situations. Loan talented developers and engineers to the architecture team, to build out the architecture.
•Sponsor an Architect’s Forum. Bring all of your IT architecture talent (enterprise, domain, technology) together periodically to exchange ideas, discuss challenges, and tackle your toughest problems. Leverage their collective brain
power. Create a community.
•Encourage Enterprise Architects to “Feed Their Brains.” For enterprise architects to stay on top of their game, they need to continuously explore, stretch their boundaries, and sometimes, just sit and think. Recognize this is part of the deal. Be patient when the areas they explore don’t have an obvious connection to your business or technology plans. Trust their instincts.
Conclusion
I believe the enterprise architect is a linchpin role for 2006, and beyond. If you have enterprise architects that match the attributes above, good for you. [same if you are one!] If you don’t, start looking. In your search, pay careful attention to the architecture skills and traits. Incorporate situational exercises in your interviews to assess the candidate’s thinking. Don’t hold out for the non-existent superhero, but don’t settle on a pure technology jock. Lastly, remember, you get what you pay for!
Notes:
[1] While some of these trends are universal, such as the Google Effect, others (“Triple Play” and “Lesscode”) are more relevant to particular domains.
[2] Please note I don’t include architecture certification or knowledge of any specific architecture frameworks. I don’t believe architecture certification can truly measure all of the dimensions of architecture talent, particularly the skills and traits. As well, many of the most talented (and successful) architects I know, do not have formal enterprise architecture training. Instinct, experience, and a good mentor are often the best training mechanisms.
James says
Glad to see someone representing the proper perspective of an enterprise architect. What you describe is what me and my peers practice 99% of the time (we are not perfect). As far as your forum idea, I had started to sketch out an idea in 2004 but simply ran out of bandwidth.
The idea was to establish a quarterly Enterprise Architect Summit where the registration fees would be zero dollars and zero cents. I figured that pretty much every large enterprise had an auditorium we could use for free and we could leverage the intern programs for other aspects. The URL was: http://www.eaforum.org
brenda michelson says
James – I’d be interested in discussing an EA Forum — for the role that I describe and you second. Not sure what it would take to pull it off, but maybe we could start with a New England focus? -brenda
Paul Kurchina says
Great article – I could not agree with you more in terms of your comments, back in 2004 we setup a Enterprise Architecture community for Enterprise Architect’s in “SAP Centric” organizations. Your comments are especially true with web services (ESA in SAP’s case) and the greater need for Enterprise Architect’s involvement.
Quote from one company:
“The role and importance of an Enterprise Architect within a company’s IT organization will become much more valuable and integral to the overall success of migrating towards Service Oriented Architecture. As company’s evolve from their current IT platforms such as SAP’s Enterprise Services Architecture, architects will take on a more critical and prominent role early in analysis and design phases, where before this was the territory of experienced business systems analysts, developers, and super users. Many white papers and books that have been written on SOA seem to miss this point, but at our company this is proving very true today as we start the migration and towards leveraging SAP’s Enterprise Services Architecture.”
Send me an email if you would like a copy of the article on this community that appeared in the April 2005 Edition of SAP Info Magazine Paul@Kurchina.com
ASUG Enterprise Architecture Community
The ASUG Enterprise Architect’s Community was created in 2004 to help Enterprise Architect’s: “to better leverage what is available today – plan our roadmaps for tomorrow and to influence future SAP directions and developments”.
Enterprise architecture has a unique, holistic view of applications – not focusing on any one SAP applications module or SAP technology but on the totality including non-SAP application and technologies. Enterprise architecture cuts across all ASUG business process and technology groups.
The Community is seen as a way to define the roles and responsibilities of enterprise architects and to collect from them a variety of information, ideas, and lessons-learned that can be rapidly disseminated through various communication channels. The Community will facilitate education, networking , conduct webinars, participate in events, host discussion forums and – especially important ¬– provide feedback to SAP Product Development.
http://www.asug.com/groups/ea
ASUG – Americas SAP User Group http://www.asug.com
Richard Akerman says
Great posting! Will be very useful for me in helping to communicate what I do as an Enterprise Architect.
Science Library Pad says
the role of the Enterprise Architect
I am an Enterprise Architect, which can be a bit of a problem when communicating with people, since very few people know what EA is or what we do. Fortunately Brenda Michelson comes through with a detailed posting on IT
nathanhollis.org says
Traits of an enterprise architect
The role of an enterprise architect generally varies by organisation – often dependent on what background the CIO has, and usually whether they value the importance of the role. The traits listed by this great post by Brenda Michelson in this article …
Antony Upward says
Hi,
I’ve been working in the role you describe for about 7 years now…although I call myself a business architect (to differentiate myself from the more technology oriented people in the architecture teams I work with).
I’m also in the SAP space…and I suspect that a lot of people doing true EA are from the ERP/CRM space…simply because the vendors do so much of the technology archiecture/application architcture work there is less of that to do for each individual customer/client … so the client architects can spend their time on value add architectural activities. Just a thought.
Great article…could agree more with you summary of the opportunity for IT to make a sustained difference.
Antony
David says
I put a link to this article in my Sun Microsystems
blog entry at:
http://blogs.sun.com/roller/page/developerzone
with the specific entry being:
http://blogs.sun.com/roller/page/developerzone#soa_innovation_simply_enterprise_architects
Excellent article on the Enterprise Architect.
brenda michelson says
David-thanks for the comment and the post. I’m pretty sure I wasn’t “inside your head” – although I bet I could learn more than a few things if I were. I’m really pleased with the response to this post – by real practitioners. Great to see enterprise architecture get off of the whiteboard and into the mix! – brenda
JT says
Great posting Brenda!
I am first reading this in March 2006 and it resonates very well. We spend so much time managing against new technology trends, challenges, and hype curves … its very refreshing to see commentary on the real reason we provide architecture…for business enablement.
I hope to see and discuss more on Business Driven Architecture in the future.
-JT
brenda michelson says
JT-Thanks for stopping by. You will see more on business-driven architecture in the (not so far) future (I hope!). I welcome the discussion. -brenda
CK says
Phew! What a great article. Your article truly takes out the mysticism of it all. It really is about the business after all, isn’t it. I’m more a business person in an Infrastructure Organization. A colleague of mine has been kind enough to spend time exposing me to this thing called Enterprise Architecture. I posess so many of the characteristics that you describe and believe there is a place for me in Enterprise Architecture. I lack deep technical expertise in the foundational domains that you mention, but broadly can speak to all of them. I’d like to dig deeper into this thing called business-driven architecture. Could you give me some pointers?? Will you be blogging more on this topic?
brenda michelson says
CK- Thanks for the kind words. Yes, I believe it is all about the business. Actually, your specific business 🙂
I will be posting (a lot) more on business-driven architecture. If there’s anything specific you’d like to see or talk about, let me know. Thru the comments here, or email: bda at elementallinks dot com.
-brenda
Business-Driven Architect says
Business-Driven Architect: Quick Introduction
Getting through the first post on a new blog can be a daunting task for both the author and reader. So, to save us all some pain, I’ve chosen a question-driven format, augmented by links to my previous writings. Here…
Brian Leapman says
Hi Brenda,
Great article, but you may have put you and your colleagues into too small a box. The big business problems for architecture are how do we create collaboration and interoperability not only within the enterprise but across all our relationships and supply chains. How do we arbitrate between the 80% commonality each new standard creates and the 20% idiosyncrasy of our organisation that as individuals we like to create, maintain our useful legacy but enable it within a global meta structure? How do we align not only data and message, but collaboration, state set, process, and role? Is semantic necessary or interoperability when each organisation has independence of purpose?
Brian Leapman
Global Business Process Architect
By the way we have solutions to all these problems and are looking for a few technical process architects to help articulate the solutions in a global IT utility company. Do you know of anyone who might be up to this challenge?
Ahmad Khalafallah says
Graet article. One year old and still shining. Thank you brenda
John Wu says
Great article. One thing I would like suggest on the skill of enterprise architect is the capability of learning experience by the others. You can find more information on my book proposal
http://e-cio.org/lea_book.htm
brenda michelson says
Ahmad and John, thanks for stopping by and your kind words. I think the (business-driven) enterprise architect remains a linchpin for 2007.
John – good luck with your book. I keep threatening to write one, but it hasn’t happened yet. I like the immediacy of blogs and papers…