Marc Guindon

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Login

What is Business Architecture?

Posted by on in Business
  • Font size: Larger Smaller
  • Hits: 2882
  • Print

Recently the terms Business Architecture, Business Model and Business Process have been used in discussions. However, I can’t tell you how many times I’ve heard people use them interchangeably. So, what do they really mean? Well, basically all of these terms mean very different things.

I decided that I would take some time and try to bring some clarity to Business Architecture.

So what is a Business Architecture? Is it a business process? Is it your governance? Is it your business capabilities?


Well, it would be a mixture of all of these things, and more. The Business Architecture:

  • Provides a common, enterprise-level business language and framework for documenting how the business is organised.
  • Describes the business in terms of its capabilities, governance, processes, and business information


I can almost hear you say: “What does that really mean?”


You can view the Business Architecture as multiple layers:

  1. Strategic Layer: describes the business vision and mandate of your organization. This would also include things such as business challenges, strategic outcomes, operating performance requirements.
  2. Business Capability Layer: describes the capacity, materials and expertise an organization needs to perform its core business functions
  3. Organizational Layer: includes roles and responsibilities, business context. It describes the business itself (the internal organization). Who does what?
  4. Business Process Layer: includes the key business processes that represent capabilities of the organisation
  5. Human Resources Layer: describes the skill sets required for the business, communication strategy, HR strategy, etc
  6. Geographic Layer: describes where the work would be completed. For example, where would you locate your data center, help desk, application development team, etc


Below you will find a picture of the various layers forming the Business Architecture











Here are some assumptions when developing the Business Architecture:

  • Not every organization will require full blown business architecture. For example, in some cases, we focus on the strategy, organization and business process layer 
  • Build the architecture on the future state (to be) model 
  • Build the architecture from a top-down approach 
  • Build the architecture based on a tailored methodology


Why go through the exercise of documenting the Business Architecture. What is the Value Proposition?

  • Increase business efficiency and effectiveness by mapping and modeling the business to the organization's vision and strategic goals. 
  • Identify areas of opportunity as well as gaps between the “As-Is” and “To-Be” state. (processes, activities, people, and tools). 
  • Put in place an organisation and human resources that aligns with the business processes and business capabilities 
  • Better understanding of where and how the work is being done


Don’t see the business architecture as one big deliverable. It can be broken down into various products. Deliverables could include diagrams and/or documents.

Hope this brings some clarity to the wonderful of Business Architecture.


Twitter: @MarcGuindonMGIS


Founder and CEO @ MGIS Inc.- Entrepreneurial spirit with a passion for Business Architecture, BPM, and a desire to work more effectively and efficiently.

Follow me on Twitter: @MarcGuindonMGIS


  • Rob Vens
    Rob Vens Friday, 08 February 2013

    No offense, but your explanation looks suspiciously like a model or a modelling language :D
    For architecture to survive as a term describing overarching principles regarding the design of "things" (enterprises being among them) I think we need to include other things, like an architecture process, and the notion of what I call transitive dependencies (change something here, and somewhere else not directly connected an unexpected effect occurs).
    Would you agree that it might be advisable to include these aspects in a definition of architecture?

  • Super User
    Super User Tuesday, 23 April 2013

    My apologies for not responding sooner but I was busy writing my ebook 'Business Architecture Made Easy'. I was tempted to call it made simple - but it never is, as much as what you have described confirms.
    I believe it can be quite a while before business architecture can describe the capability of the business.
    It is likely the first piece of work will be a series of value streams that make up a priority area that the business requires to be addressed.
    But in collecting the capability of common guides and enablers at play in the value streams it will produce an analysis footprint into 'the business' as a whole. Each assignment will require less analysis as we rely on what has gone before.
    Eventually the business will realise this is an amazing investment that allows hypothesising and prototyping on the fly. No more waiting six months for analysts to try and work out what it is we are trying to achieve. No more trying to specify functional requirements of the top of somebody's head.
    No more spending fortunes replacing systems based on the opinions of a few.
    Collaborative Design Teams replacing the 'Ask the Boss' mentality.
    I do find it interesting that your surround wall paper is construction architecture. I think you would enjoy my book.
    Bernard Morris

  • Please login first in order for you to submit comments

Become a Fan

MGIS Bloggers

Marc Guindon
3 post(s)
Founder and CEO @ MGIS Inc.- Entrepreneurial spiri...
Carl Courneya
15 post(s)
Business Analyst @ MGIS Inc. Passionate about mak...
Matt Page
12 post(s)
As the Director of Professional Services for MGIS ...