Architecture Strategies and Principles

Posted by Boris Lublinsky on Jul 07, 2010

Sections

Enterprise Architecture

Topics

Architecture ,

SOA ,

Enterprise Architecture

 

There have been quite a few publications recently on the role of the enterprise architecture and the importance of its alignment with business strategy. According to Chris Curran:

EA often fails to reach its potential because so much emphasis is put on "EA" itself and not on its outcomes. Focus more on solid, collaborative business planning and let EA fade into the background.

Discussing 16 Enterprise Architecture Strategies Learned the Hard Way, Curran notes that:

Strong credibility and trust amongst Business and IT partners is a predictor of EA success. Credibility has typically been gained via joint strategic planning efforts, one project at a time.

Curran goes on discussing 5 most common architectural myths:

• Enterprise Architecture is what IT Uses to Plan its Technology. According to Curran, technology is only one of the components of the enterprise architecture:

  ... a good EA program starts with a representation of what the business units and functions want to do (objectives, metrics, a strategy of some kind) and uses it as a basis to understand what business capabilities are needed and then build a business and technology blueprint and plan.

  On another hand, he cautions against trying to spend too much time building such a blueprint:

  An exhaustive enterprise level blueprint is virtually impossible to build - it’s too big and no one will buy-in... The best strategy blends a direction-setting enterprise blueprint and business unit and domain blueprints.

• One Can’t Measure Enterprise Architecture. In Curran’s opinion, the only enterprise architecture that can be measured correctly is a business driven one:

  What can and should be measured is progress in delivering the prioritized business capabilities developed during planning. Once the capabilities are delivered, the relevant business metrics are also measured.

  He then continues by saying that EA should be measured in 2 ways: business capabilities delivered and costs of core services:

  Measure EA as an asset - what does it cost to provide the service and what return does the business get from the business capabilities delivered?

• Architects Only Pontificate, They Don’t Work. One of the byproducts of the technology-driven approach, notes Curran, is an architecture group spending most of its time meeting with vendors, writing whitepapers and implementing technology prototypes that never see the light of day:

  The companies that do architecture best "staff" the majority of the architects to projects as core team members. This way, they are on the ground adding their expertise every day.

  He even goes as far as defining percentage time that an architect should spend (on average) doing project work:

  Architects must be assigned to projects as core team members (60%+ of total EA FTEs) rather than "advisors"

• Enterprise Architecture Doesn’t Work with an SDLC. According to Curran:

  Methods and governance must be integrated into existing work processes (eg, project approvals, SDLC) rather than a new overlay

  Otherwise architecture processes will live by themselves, rather than being integrated into day to day enterprise activities:

  EA processes should live in 2 places, right after the high-level business strategy directions and priorities and embedded in the program, project and SDLC management processes to ensure that the cross system blueprints are implemented in each initiative as envisioned. So, for EA to work, it MUST not only work with the SDLC, but all other program and project level processes and methods.

  In Curran’s experience:

  High performance groups maintain consistent, formalized EA involvement in the SDLC to translate blueprints into sufficiently detailed starting architectures for each project as well as accurate cost and resource estimates.

  He also notes that:

  Mature organizations target 40% EA resource time for strategic planning and 60% on SDLC tasks, and typically err on spending more time on SDLC tasks.

• If You Subscribe to SOA, You Don’t Need EA. Curran explains that some of the companies are trying to adopt a particular architectural style, for example SOA or cloud computing to jump start their enterprise architecture. As a result they often end up with "one size fits all" and have this style dictate every architectural decision.

  ... if business leads in EA, it will dictate the appropriate styles and models of computing. Choosing an SOA model will only address a small portion of the overall technical architecture and may not be needed or relevant for some business areas in the overall EA blueprint.

Curran’s observations go to the heart of many problems that enterprise architecture groups are experiencing in many companies. Following his advice can make life easier for both enterprise architects and management.

1. Back to top

   Is EA dying?

   by Udayan Banerjee

   There was a lively discussion on one of the LinkedIn group on this topic.
   
   Here is a summary of what was discussed - setandbma.wordpress.com/2010/05/05/is-enterpris...

   Reply

2. Back to top

   need more info

   by Sawan Ruparel

   Good One. Is there a way to simulate or model this, before implementation? Also need a kind of importance map. What is more important that something else? I know this might depend on business, but then there can be relational map.

   Reply

3. Back to top

   Re: need more info

   by Chris Curran

   Hi Sawan - I haven't done an importance map but will think about putting one together. MIT's Center for Information Systems Research (CISR) has some research that looks at the important EA capabilities by maturity level. They discuss much of the thinking in their book Enterprise Architecture as Strategy.
   
   -Chris
   CIO Dashboard Blog

   Reply

• Older >