[fusion_builder_container hundred_percent=”no” equal_height_columns=”no” menu_anchor=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”center center” background_repeat=”no-repeat” fade=”no” background_parallax=”none” parallax_speed=”0.3″ video_mp4=”” video_webm=”” video_ogv=”” video_url=”” video_aspect_ratio=”16:9″ video_loop=”yes” video_mute=”yes” overlay_color=”” video_preview_image=”” border_size=”” border_color=”” border_style=”solid” padding_top=”” padding_bottom=”” padding_left=”” padding_right=””][fusion_builder_row][fusion_builder_column type=”1_1″ layout=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” border_position=”all” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding_top=”” padding_right=”” padding_bottom=”” padding_left=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” center_content=”no” last=”no” min_height=”” hover_type=”none” link=””][fusion_text]Many years ago, fellow EA consultant and thought leader, Jeff Scott, published an interesting article in CIO magazine that outlined a useful method for applying Enterprise Architecture to an organization. The article was titled “Don’t Just Build Business IT Alignment, Map It!” (linked here).

Unfortunately, I believe, very few people understood it.

I’ll admit that, when he published his article, I was working in an EA team and I didn’t use his advice either.  You see, Jeff was speaking from the viewpoint of a company that wants to provide EA as a consulting service (he was at Forrester at the time).  The advice he gave was less useful for organizations that wanted to provide EA as an internal service.

With your permission, gentle reader, I’ll spend a few minutes describing the difference.

Most internal enterprise architecture programs struggle, often for a few years, with finding their place in the overall process of IT service delivery.  Many will start out by extending from the tried and true “Architecture Review Board” while others will build a mechanism for evaluating the ROI of proposed IT projects.  Both of these are fairly “bottom up” approaches to EA, in that EA is not creating ideas for simpler systems.  Instead, EA is reviewing other people’s ideas with an eye to compliance to an arbitrary and often changing set of standards.

As most teams discover, this is a fools errand.  Teams that do not discover this are ultimately disbanded.  It’s a terrible way to apply the key benefits of Enterprise Architecture to an organization.

Teams that want to be successful, but have started an EA review program of some kind, should probably stop reviewing projects until they establish other points of value.  That’s my first bit of advice today.

Teams that are successful find that there is a key point of value that actually rings true for an Enterprise Architect to perform – a combination of engineering and business savvy that is difficult for a consultant to deliver and is even more difficult for the organization to do on their own: crafting novel approaches to deliver on the requirements of business strategy that is in keeping with the architectural goals and direction of the company.

In other words, to use a tired fishing metaphor, the hook is business architecture, the line is information architecture, and the result is automation of digital capabilities across the organization.

Effectiveness comes in the form of saying “yes” as often as you say “no.”  Yes, we can deliver your needs, but no, not using the poorly constructed solution you are proposing.  Yes we can go quickly, but no, your approach to shadow IT is not going to meet the needs of the enterprise.  Yes, your business requirements matter but no, we won’t ignore security for the sake of delivery.

This is a difficult and important place for an EA team to be.  To do this well, EA has to be integrated into the process by which top level initiatives are chartered.  They have to literally create the top level initiatives as a result of discussions of strategy and tactics.

So how is this different from Jeff’s process as published in CIO magazine?

Jeff started with a basic assumption: you have to start somewhere… find out where to start.  Look for fertile soil and start there.

Unfortunately, that approach pretty much emasculates the business architecture side of EA since the efforts start with a list of existing alignment problems and opportunities.  There is no discussion of novel opportunities, and precious few cycles spent examining strategies and looking for gaps in the company’s list of capabilities.

Jeff’s approach is practical.  It speaks of “coming at the problem from the side.”  It is very well tailored to delivery by a consulting company and can be well leveraged by a completely new EA team that needs to get traction and provide initial value in order to justify its existence.   For many companies hiring a consulting company, this is a problem that they face.  To solve that specific problem (where do we start), Jeff’s process works wonders.

The danger of the process, and the reason that I don’t believe it is useful beyond that narrow starting place, is that any organization who allows their internal team to use Jeff’s process for more than six months will be quickly trying to justify their existence the next time the budget is being created.  That is because the EA team, in that process, will add very little NEW value.

Adding value after the fact is not the best way to use Enterprise Architecture. It’s a good place to start, but if you don’t grow from there, the program will sink fast.[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]