Business Architecture is part of Enterprise Architecture

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.

What is an Enterprise Architecture Blueprint ?

I recently saw a discussion about the word Blueprint in regard to Enterprise Architecture which reminded me of confusion I’ve encountered with some of my clients.

I regard the word Blueprint to be another name for the Future State (to Be ) Enterprise Architecture model content. this is my preferred meaning.

I have also worked in an EA team that regarded the strategy, principles, Goals, Objectives and requirements as the Blueprint layer on top of the usual 4 EA architecture domain models (i.e. Business, Information, Application and Infrastructure Architecture models).

In regard to the same discussion, I have learnt about FSAM which uses word Blueprint with my preferred meaning.

FSAM can be see and downloaded from http://www.fsam.gov/index.php.  I recommend that Enterprise Architects take a close look.

Archimate and TOGAF 9’s EA Meta model

I’ve been using Archimate since 2004 after coming across it in the Netherlands. It fills a gap in the discipline of Enterprise Architecture by providing a well thought out EA meta model that supports modelling at an enterprise level and integrates well with SOA, BPMN, UML modelling at a solution level. When I’ve explained Archimate to my clients, it has been widely seen as making a lot of good sense and easily understandable. Early EA efforts have often been no more than Enterprise IT Architecture that leaves out the Business Architecture and frequently also the Information/Data Architecture domains. Archimate unified all the architecture domains very well. It is good that Archimate has now been adopted by the Open Group. It was a shame that it wasn’t adopted for TOGAF 9 but should be more influential in TOGAF 9.1 and I expect it to become the defacto global EA modelling language standard by then. TOGAF 9 has now an EA meta model but it has some gaps and awkwardnesses that full adoption of Archimate should address. One area that I’d like to see Archimate be extended is integration with the Business Motivation Model (BMM). the TOGAF 9 EA meta model already has some concepts from BMM, but lacks the clarity and quality of Archimate.