Business Architecture is part of Enterprise Architecture

25 February 2009

Enterprise Architecture does by definition include Business Architecture. Any other view is now rather out of date. 

Enterprise Architecture should include several domains: 

  •  Strategy 
  • Business Architecture 
  • Information/Data Architecture 
  • Application Architecture 
  • Infrastructure Architecture

In addition there are other sub-domains for Process Improvement, Governance, Audit, Security etc. 

All EA frameworks including Zachman, Archimate, IAF and TOGAF 9 recognise these distinct domains in some form. 

TOGAF 9 is increasing mature and the image at http://tinyurl.com/btxqga 
is a good baseline for understanding the various domains. 

Of course over the history of the maturing of the Enterprise Architecture discipline, it was nearly always the case that Architects came out of the IT function.

IT trained staff are more likely to be good modellers and think in rational formal ways necessary to produce good Architecture models.

Business staff on the other hand like to own their business models and have been less precise and formal about how they modelled what they do.

This is improving of late with BPMN and BMM models becoming more acceptable for business focused staff to use.

The Enterprise Architect is also increasingly becoming a Strategy & Architecture discipline and an Enterprise Architecture (as opposed to a Solution Architect) likely not to have an IT background. Many are from a Business Analysis, Programme Management, Portfolio Management background.

The ideal EA team today will have a mixture of all kinds off staff from different disciplines and will not report to the IT function.

EA is a corporate level function and not just a Business or IT function.

4 Responses to “Business Architecture is part of Enterprise Architecture”

  1. Dirk Schmele Says:

    YES, THANKS! All together this is EA from my point of view, but one essential part is missing: COMMUNICATION. If you are “just” a domain expert (e.g. IT) you can not provide the necessary glue to all domains. At least an EA should be able to listen, talk and learn. At best an EA is capable to convince others.


    • I reckon that up to 40% of an Enterprise Architect’s time is spent on communication. There is usually a constant need to communicate the benefits of EA and to discover and discuss the current and future state enterprise architecture models and resulting transition roadmap. I’m always concerned when clients tell me that there is no need to communicate, and desire the EA deliverables to be developed behind closed doors.

  2. Mike Says:

    Just passing by.Btw, you website have great content!

    ______________________________
    Don’t pay for your electricity any longer…
    Instead, the power company will pay YOU!

  3. Curtis Says:

    Hi there,
    Agree with the most part… v.good.

    Can I ‘communicate’ a point that a Solution Architect and Enterprise Architect are truely seperate roles, there is enough room (and work) in an Enterprise/Organisation for the definition of both… where an EA will be responsible for the communication, relationship and ‘modelling’ between the domains, the SA has the responsibility for the ‘Target’ planning (i.e. strategy) for initiatives (projects) within the various departments… granted they work close (if not in the same team/group), but are different.


Leave a comment