Enterprise analysis - using business architecture to clarify the muddle (Part 1)

by John Barris on 29/06/2011 06:43

Earlier this month I delivered an IIBA presentation, with the same title 'Enterprise analysis - using business architecture to clarify the muddle', to around 80 attendees in Wellington, New Zealand. The presentation was well received. This post, plus the Part 2 post to follow, summarise some of the key points from the presentation.

The challenges that Business Analysts face

  • Business change is complex – as we undertake requirements at a project level we realise that we need to understand people, processes, information and rules. We realise that processes cross departmental boundaries and people will have to change work habits. The discoveries go on and on adding to the complexity of a change initiative.
  • Project requirements often lack context – we let ourselves down by approaching requirements workshops with the question ‘what do you want?’ rather than properly understanding the full business context.
  • The scope problem: what’s in and what’s out – we tend to state what we will do rather than what is going to change.
  • The solution vs problem dilemma – we find ourselves defining a solution. For example, we define a screen for a new application, before we understand the business rationale behind it, and legitimise it by calling it user centred design.

Enterprise Analysis vs Business Architecture

Enterprise Analysis and Business Architecture have emerged and are taking us a step closer to what should be at the heart of the Business Analysis profession - the Business. So what is enterprise analysis and business architecture?

  • Enterprise analysis – the activities performed to understand a business for the purpose of changing it.
  • Business architecture – a blueprint of a business to identify, analyse, communicate and manage business change.

Using Business Architecture

Some of the major constructs of business architecture include:

  • Business Domain – the business that is the focus of study
  • Business Goals – the statements of intent required to achieve the Vision (the desired state)
  • Primary Activities – what a business does
  • Business Capabilities – what the business needs to do what it does. Business capabilities are groupings of resources such as People, Processes, Systems and Information (and sometimes Assets)

In the next post Enterprise Analysis - Using Business Architecture to Clarify the Muddle (Part 2) I will discuss how enterprise analysis and business architecture address the challenges that Business Analysts face and offer some tips for using business architecture.

Recorded webinar: achieving clarity - your core business analyst competency


Get blog posts by email

New call-to-action
New call-to-action