EA Principles Have Little Value

Just recently I learned that a client’s CIO leadership team began a detailed and substantive discussion on EA principles, the implications they carry for their organization, and how they can use them to transform their journey into the future.   I don’t see this as often as I’d like.  While gaining that level of leadership engagement in the creation and use of EA principles has long been a desired outcome, it is still somewhat rare.  In this case, it was a combination of good luck, good timing, and a skilled Chief Architect who was able to keep principles visible and to broker the discussion with leadership.  There is a lesson to be learned here.

With common sense as a significant part of a good set of EA principles, it is easy for a leadership team to write them off as “a statement of the obvious” and not pay much attention.  As enterprise architects, our goal must be to make principles relevant.  The approach is for us to demonstrate how they are used in practice and to show that they are more than a collection of catchy phrases.

For each principle individually, and for the set as a whole, it is important to be able to explain them in real-world terms.  This means choosing principles that guide desired behaviors and explain their rationale and implications in a form that leaders can relate to, with an emphasis on how they affect decision-making at all levels.

Unfortunately, I see many examples of principles that don’t gain traction.   When that happens, EA principles have little value.   When I diagnose the situation I often see that a lot of energy was consumed in creating the perfect written words, with less energy committed to bringing the principles to life.

A few tips:  Always be sure to include rationale and implications, but don’t worry so much about making them perfect, just strive to make them good enough.  Invest the extra energy in bringing them to life in four ways:

1. Ensure that ALL members of the core and extended EA teams understand what the principles really mean and how they are used
2. Be sure to actively and visibly reference the principles in the process of creating future state EA content
3. Refer to the principles and use them as a test in ALL solution architecture and coaching work
4. Carry the principles with you in discussions with leadership at every opportunity

By using the principles every day, their value will eventually be self-evident and leadership teams will recognize them as a helpful tool in their management arsenal.

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.

Tim speaking on BA Language at The Open Group Seattle

I will be speaking at the The Open Group Architecture Practitioner’s Conference in Seattle, WA during Day 2 of the  event at the Grand Hyatt Seattle, February 1-5, 2010.  

My presentation during the plenary session on Tuesday morning is entitled “Architecting the Business is Different than Architecting IT” and the session description and the rest of the event agenda and information is available at the event website.

I am looking forward to continuing the conversations around the maturation of EA into the areas of business architecture and information architecture at the event.  Let me know if you will be attending.  And please find me in the lobby, at a reception or after my presentation if you are there.

Podcast available for “Architecture’s Scope Extends Beyond the Enterprise”

As I mentioned in my last post, I was part of a panel discussion at last month’s TOGAF event in Toronto. The podcast is now available at Interarbor Solutions, while the transcript can be found at BriefingsDirect. I would like to thank Dana Gardner of Interarbor Solutions for moderating and producing the discussion panel and podcast. And thanks as well to my fellow panel members, John Gotze and Sandy Kemsley.

My Takeaways from the 23rd TOGAF Practitioners Conference

I attended the 23rd TOGAF Practitioners Conference last week in Toronto, where I was invited to speak on a panel (podcast coming soon on ZDNET) entitled “Architecture’s Scope Extends Beyond the Enterprise.” I had never been to a TOGAF event, so I was looking forward to seeing what the event would be like. I am happy to say that I was not disappointed with my decision to attend. The Open Group were gracious hosts. The attendees more varied in levels of experience than I had anticipated. Many of the presentations and panels were not framework oriented or TOGAF oriented, making for a more well-rounded EA conference that would have benefitted organizations that use TOGAF very little or not at all. But my greatest takeaway from the event was the underlying theme that ran through the keynotes, breakouts, panels, Q&A sessions and hallway conversations – It is time for EA to become a more strategic BUSINESS discipline. For those of you familiar with EAdirections and our time with the META Group, this is not a new message. However, it is refreshing to see a group perceived as heavily IT-focused as The Open Group to promote this message through the non-member and member speakers alike, as well as some of the tracks in the program. Here are some examples:

• The panel I sat on, while entitled “Architecture’s Scope Extends Beyond the Enterprise,” was actually focused on how the role of EA might be evolving in the future. The moderator and audience questioned the ability of EA to reach its potential as an effort within the IT department. While most see that EA has expanded beyond technology architecture, the evolution of EA towards business architecture is just beginning, if at all, in most organizations.

• The afternoon of day 1 featured tracks on “Holistic EA and and the Role of Business” and “EA Implementation and Business Transformation.”

• One of the afternoon speakers, Bill Sheleg of Deloitte, spoke on the topic of “Extending EA to a Business Discipline.” His premise, as we have expressed for years, is that there is a disconnect in many organizations between the defined strategy and the activities that are going on in and organizations, and that EA is uniquely positioned to bridge that gap. One of the key points he made came from a Bain Consulting study, which said “Seven out of eight companies in a global sample of 1,854 large corporations failed to achieve profitable growth, though more than 90 percent had detailed strategic plans ….”

• The highlight of day 1 for me was the end of day roundtable discussion. All of the speakers from the morning panel and the afternoon speakers in the Holistic EA track joined with the audience to share ideas and thoughts on the question: “What’s next for EA?” The resounding consensus of the group discussion was that EA needs to become a tool that the business (not just IT) uses to improve the execution of strategy. How that will happen, however, brought up several different opinions from the group.

• The second day featured an entire track on the role and profession of business analysis and the parallels between business analysis and business architecture. This track was highlighted by a discussion from Kathleen Barrett, President of the International Institute of Business Analysts (IIBA). She spoke on the evolution of the profession of business analysts, going so far as to say that the set of skills and knowledge that business analysts possess are the same as business architects should possess. IIBA just published the Business Analyst Book of Knowledge (BABOK) 2.0, which is something that I would recommend aspiring BA’s (analyst or architect) make a part of their repertoire.

The next TOGAF conference in North America will be in early 2010 in Seattle, WA, where I hope to see that conversation has continued and evolved.

Another interesting speaker was David Foote, of Foote Partners (www.footepartners.com), a research company focused on IT workforce management and compensation practices, trends and issues. David provided quite a bit of interesting data and research conclusions regarding IT jobs, skills and certifications in the US and Canada. His latest press release is available at www.tinyurl.com/ltfpte, containing much of the information he shared with us, but there were three salient points that I want to share:

1 – Although the US unemployment rate is still growing, there are some segments of IT that are losing jobs at a slower rate than most other segments, and in some cases, even gaining jobs in some months. This counter trending is typical of the IT profession in a recession due to the increased dependency on IT.

2 – One of the areas in which David sees a difference in this recession, than in past recessions, is that companies are being very careful about where they cut jobs, so that when the economy begins to rebound, they will be ready with their best people. Specifically, IT professionals with architecture skills and certifications are being valued very highly.

3 – To further solidify the position of architects, including enterprise architects, David presented several data points that show that while many IT skills and certifications are losing value with employers, those of architects are generally trending upward. For instance, Architecture and Project Management certifications that are tracked by Foote Partners have actually increased in value by 4.3% during Q2 2009, one of only 3 areas with growth. Also, of the 19 architecture certifications that they track, none have lost value in the last quarter, with some even gaining value.

Taken altogether, David did a pretty good job of convincing the audience that while some analysts may have predicted a “Death Knell” for Enterprise Architecture in 2009, that does not appear to be the case. My colleague George Paras also disputed this notion in a recent blog entry, www.eadirections.wordpress.com/2009/03/17/will-ea-groups-disappear-in-2009/. Both the data and David’s conversations with executives support the notion that this recession is a great opportunity for IT professionals with architecture skills to thrive.

TOGAF 9.0 Released February 2, 2009

The Open Group announced the release of the latest version of The Open Group Architecture Framework (TOGAF), 9.0, during the 21st Enterprise Architecture Practitioners Conference in San Diego this week. It is available for download at http://www.opengroup.org/architecture/togaf/.

During a briefing with The Open Group representatives last month, EAdirections learned about the improvements and additional components of TOGAF 9.0:

o The Architecture Content Framework, contributed by Capgemini, is a structured metamodel for architectural artifacts, intended to help an organization organize and relate the artifacts that they create. This is different than the reference models, TRM and III-RM, as they are targeted at organizing and related topical areas.
o The Architecture Capability Framework is intended to provide better guidance in the area of skills, organization, roles and responsibilities of architects, and a process for defining an appropriate architecture capability for your organization.
o Enhanced guidance on the usage of the Architecture Development Method, including the use of iterations, partitioning, applying TOGAF to different levels of architecture, and dealing with the specifics of different architecture styles, specifically security architecture and SOA.
o More, both explicit and implicit, improvements in the positioning of TOGAF as a toolset for ENTEPRISE architecture …. which, of course, we will be very interested in.

TOGAF has fundamentally not changed. The views, definitions, and perspectives that have characterized TOGAF for many years are the same. We have spoken to our impressions of TOGAF in support of Enterprise Architecture efforts many times, most notably in a webinar and corresponding survey in September, 2008. Our initial impressions of TOGAF 9’s changes are that they are all steps in the right direction, without having looked at the details yet. We will be conducting a more detailed review and making our findings know in the second quarter of 2009. If you have questions between now and then, don’t hesitate to contact Tim Westbrock at twestbrock@EAdirections.com.

Directions: EA practitioners should be aware of and investigate the features of TOGAF 9, with an eye towards the continued evolution of TOGAF as an EA toolset.

Dangers of ‘EA Senility’

In the last couple of weeks, I have spoken to two clients who had common symptoms which I have termed ’EA Senility’.  Both are Chief Architects in large, global companies.  Their EA functions are mature by any measure.  Strong EA governance and communication.  Completed TOGAF-like frameworks that are comprehensive, fully populated, current and well crafted.  Artifacts are polished.  In short, they are models of EA excellence and could serve as case studies for newly minted EA teams.

There is only one problem. 

Both Chief Architects believe they are slowly losing the support of leadership – both within IT and the BUs.  By ‘loss of support’ I don’t mean ‘anti-EA’ sentiment but rather a loss of relevance and interest. Both wanted insight and advice on how they could return to their ‘glory days’.

One of the clients had just had a meeting with their new CIO ,who was hired from the outside after the long-serving CIO retired.  One of the first things the new CIO asked was “How is ‘open systems’ incorporated into the enterprise architecture?”. 

The fact is there isn’t any open systems ‘stuff’ in either client’s EA.  No Linux.  No MySQL.  No Apache.  ‘No nothin’. I found this hard to believe. 

In talking with them I found that projects had come forward with open systems proposals but, it became clear to me, that ‘governance’ and ‘process’ and ‘standards’ eventually ground out innovation.  The EA teams had effectively become inhibiters of business change.  In their old age they had gotten away from the raison d’etre – to enable the business.

When, as architects, we stop looking forward and we stop innovating then we should retire.  We have become ‘the man’.  We have become senile. 

‘Senility’ doesn’t happen to the young, it happens to the ‘mature’.