Business objectives communicate what the organisation wants to achieve and set parameters and goals for all initiatives within the organisation. They should be aligned with the overall Business Mission to ensure the basis for continued business and measurement of planned changes, and are not necessarily totally financial but may include organisational aspects, changes to their image or market etc.

Business Objectives are closely associated with Business Mission, Business Goal's and are often a basis for deriving Business Activities and Business Service's. Ideally, they should have clear goals, be measurable and be achievable. The Scope of the engagement will be closely aligned to the Business Objectives and demonstrate how the architecture supports the goals and measures.

Different types of business issues require different types of architecture and architecture engagements. Architecture may be used to support major strategic change and planning, or as a validation and specification exercise, as a precursor to a “build” programme. The former is generally categorised as “Enterprise” while the latter is categorised as “Project”.

The primary difference between the two is in the level of detail and aspect area focus. “Enterprise” architectures tend to focus on the Business and Information aspects with a top slice across the other aspect areas whereas “Project” architectures focus on the IS and IT aspect areas (with an implicit assumption that the Business and Information aspects are defined). Similarly, an Enterprise Architecture that is created as part of a business case for major change provides just enough detail and structure to estimate costs, whereas one that is created to define which systems will be used after a merger, focuses on the current and desired structure together with life cycle management aspects of those systems and will require more detail and analysis.

The Business Objectives relevant for the engagement sets out the outcomes of the architecture. The Business Objectives communicate the issues that the architecture will address and the way that the architecture will address them.

The Business Objectives shape the roadmap for the architecture engagement. They allow the appropriate deliverables for an individual architecture engagement to be determined, and the level of analysis required to achieve a satisfactory level of confidence in the outcomes.

Business Objectives will usually be found in various sources if not explicitly available for example in strategy papers, business cases, charters for change and the likes. They usually have a clearly defined owner (especially if linked to a specific business initiative), so the stakeholder analysis input will often identify where these reside.

Business Objectives can sometimes be very qualitative in nature – should this be the case they; may need elaboration to emphasise any quantitative aspects with relevant stakeholders, or; if they remain qualitative they can be expressed as Principles.

For example, from the business point of view the issues may be portrayed as:

• Major business change programmes
• Systems that will no longer support the business
• Business developments that ask for systems innovation
• ‘Time to market’ problems

From a technology point of view the issues may be portrayed as

• Business does not define requirements clearly
• Lack of insight in current systems
• The sponsor needs a new system
• Maintenance problems
• Problems with system operations or systems management
• Technological developments that ask for systems innovation
• Diminishing costs, complexity and risks of system development projects
• Wanting systems that work and co-operate well.

Both of these perspectives are generally present, and there will often be conflict, so it should therefore be remembered that many objectives will not be achieved by an IT solution alone, but require a series of related changes to the business architecture possibly including organisational, cultural, communications, system governance, rationalisation, restructuring and standardisation.

The Business Objectives must separate these different issues and show how the architecture will or will not address them. It is important therefore to ensure that the Business Objectives are validated by all the relevant stakeholders.

A good Business Objective would be:

“Improve Decision Making by providing better management information, through a company-wide portal encompassing branch requirements.”

This architecture will define the architectural requirements for a company-wide portal encompassing the branch requirements. It will provide the management with information to improve decision making

This makes it clear what the architecture will address and what the outcomes will be and what issues are being addressed.

On the other hand:

“This architecture will provide a solution to the interfacing problem”

This is vague, the issue is unclear (where is the interfacing problem, business or technology?) and does not show who in the business will benefit. (in reality this is a design/support project objective not a Business Objective)