Since I am a) still sick and b) bored I thought I'd ramble a bit about business analysis.
It is often useful to know where a business is, and where it wants to be.
Baseline and Target  Business Process Modelling (BPM)  will provide some of this picture. In particular how the business currently works, and how it wants to work in the future.
But BPM tends to focus on what
is done. In more detailed models that will feed into system requirements, this extends to how
things are done. 
And whilst most BPM notations do deal with who
to an extent, generally by assigning activities to business roles the attention can be somewhat cursory.
This also leaves a gaping hole labelled as why
This is where the Business Motivation Model
(BMM, full specification available here
) can come in handy for completing the understanding of baseline and target business architecture.
The first link shows a very
abbreviated summary of the core concepts. Specifically the separation of Ends (why does the business exist, what is the business trying to achieve) from Means (What does the business do to achieve the ends), as well as environmental issues.
There's a lot more to it than that. In particular there's a recursive structure within the BMM that breaks these concepts down into more granular levels.
For example within the general category of Ends there are Visions (high level, qualitative) amplified by Goals (more operational, still qualitative)  which in turn are supported by quantifiable Objectives. 
But more important is the disciplined framework for separating the questions "why are we here" and "how will we achieve this" in a way that sits above BPMs, and provides context for the BPMs to sit within.
This gives you a business architecture  that can be used to identify problems (in the baseline) and opportunities/changes (in the target).
 The terms "As-Is" and "To-Be" are also used.
 I prefer to use levelled activity diagrams
to manage span-of-control issues. The Business Process Modelling Notation
is also gaining in popularity but can be overly complex sometimes.
 At least to the level of identifying tasks for which system support will be provided. The form of that support is another topic for another day.
 In Australian federal government agencies the Visions and Goals map neatly to the Outcomes and Outputs defined in the portfolio budget statements.
 Continuing the example, these map neatly to the KPIs reported for Outcomes/Outputs in Annual Reports.
 I'm wary of using the term enterprise architecture
as I usually see that used in a more technical sense whereas what I do tends to be somewhat independent of technology, or the concepts of shared services etc (which I regard as a technical design rather than business analysis issue).