Pragmatic Enterprise Architecture

Wednesday, October 8, 2008

Counterintuitive Enterprise Architecture

If you have spoken to any Chief Architect or a student of Enterprise Architecture, most would advise you to begin your Enterprise Architecture program with the Business Architecture, which is sound advice. The business needs of the organization should drive technical solutions. How could you possibly know what your Technical Architecture should be if you don't know what Business functions it should support? In other words, your Business Architecture should drive your Technical Architecture.


Here's a taste of reality. Most Enterprise Architecture Programs organizationally reside in the IT department. Many IT executives don't understand Enterprise Architecture, or if they do consider it to be purely Technical Architecture.


So how do you create and an adaptive Enterprise Architecture program driven by the business with these constraints? Start with your Technical Architecture!


I know, I know, believe me it hurt me to say it. However, if you want your EA program to survive and eventually provide value to the organization, you need it to be around long enough to do so. I recommend building credibility by first dealing with your Technical Architecture governance, lifecycle, processes, artifacts, etc. By building credibility and documenting your wins with your Technical Architecture, you'll have the breathing room you need to tackle your Business Architecture.

Labels:

5 Comments:

  • Brad,

    In my view, any form of Architecture inititative must be guided by a clear rationale and purpose. So if The organization decided that for whatever reason it wanted to do Business Architecture (but without realizing that it lacked the organizational capability to do so) I guess recommending them to start with Technical Architecture is unlikely to win laurels. How about elevating the problem space one level up and asking the executives a clear reason as to why it wants to do any form of Enterprise Architecture. If it turns out that what they really need is BA then it might be worth explaining to them the organizational roadblocks rather then asking them to do TA?

    Thanks,
    Karan

    By Blogger Karan K, At October 13, 2008 10:32 AM  

  • I guess that you claim EA to be counter intuitive when it is inside the IT department. I recently attended a presentation on Enterprise Architecture where Gene Leganza of Forrester Research advised to hide your best EA people in other departments in order to regroup and reform your EA team after the recession has ended. I have blogged more about this presentation at http://ploneglenn.blogspot.com/2009/01/enterprise-architecture-talk-on-second.html

    By Blogger Plone Glenn, At January 16, 2009 12:24 PM  

  • I would posit that if your doing an Architecture initiative without a clear purpose or rational, than your not really doing an Architecture initiative. However there is no rule that your initial purpose can't be to build that momentum, or credibility, that will help provide examples to the business that a larger scale architecture initiative could provide benefit. The idea is to build towards the goal, at this stage the credibility and architecture of the technical systems, the next stage the architecture of the business. Even perfectly executed, Architectural goals are themselves only stepping stones in the greater evolution of the company. Even if the initial goal starts small, with a Technical Architecture, it will lay groundwork by providing benefits to use as examples, getting technical resources to start considering projects from Architectural point of view, and providing experience at multiple levels of the technical group.
    As a bonus, there will likely be friction at some point with business projects wanting to implement something against that would violate the Technical Architecture, which is a clear invitation to show the benefits, explain Architecture, etc. Even if you have to gut and rework half the Technical Architecture, it served the purpose to get you this far, which is much further then sitting in a cubicle hoping everything might just magically come together one day.

    By Blogger Tarwn, At April 19, 2009 7:49 PM  

  • Pragmatic. I like it. You have to start somewhere.

    But it is unlikely that you receive funding for any Technical Architecture improvements unless you can articulate a benefit to the business; particularly in today's economy.

    Ultimately, obviously, you must do both.

    By Blogger Troy Worman, At June 17, 2009 11:58 AM  

  • Clearly it is a question on how to manage people and make the organization think in a different way then it did before the EA program portfolio was implemented.

    In other words the technical stuff matters; however it is people who works with the processes who really bring the value to the Enterprise Architecture (or simply just the enterprise).

    In the other hand it is the "business side" of the organization that creates the revenue ( and later profits (π)) for the organization so eventually it becomes a business/ organization / IT project with a scope of obliterating the business processes and initiating a way of thinking and doing business.

    To summarize: I agree that many CIOs or CTOs don't have a clue of the business processes or how the employees do their jobs and therefore it becomes a necessity that SMBs and large companies create a Coherency Portfolio Office which ultimately handles the transformation of organization.

    By Blogger RackWrack, At September 23, 2009 12:22 PM  

Post a Comment



<< Home