What is Enterprise Analysis: does it differ from Enterprise Architecture?

Featured
86965 Views
3 Comments
27 Likes

Business ArchitectureEnterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?

At first sight, business opportunities are not always considered as being part of an Enterprise Architecture initiative, more as an activity which should be considered as an input. But let’s look at this in more detail.

Let’s look at this in more detail by way of mapping activities between BABOK v2* and the TOGAF 9 Framework*. The BABOK is the collection of knowledge within the profession of business analysis and reflects generally accepted practices. It describes business analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in the execution:

BABOK v2 Knowledge Area
Activity in Enterprise Analysis

BABOK v2 Definition

Enterprise Architecture (e.g TOGAF 9)

Differences, observations

Requirements Elicitation

This describes the interview and research process-how to best extract needs from stakeholders (and even how to recognize needs they don't know they have).Elements such as metrics (tracking the amount of time spent eliciting requirements) and elicitation techniques (prototyping and brainstorming are just a couple) among the topics covered

Phase A: Architecture Vision is the initial phase of an architecture development cycle. It includes information about scope, the key steps, methods, information requirements and obtaining approval for the architecture development cycle to proceed

Business scenarios are a useful technique to articulate an Architecture Vision.

A Business Scenario describes, a business process, an application or set of applications enabled by the proposed solution , the business and technology environment, the people and computing components (called “actors”) who execute it, the desired outcome of proper execution

To build such a Business Scenario, workshops with business users (stakeholders) would be organized

Business Requirements Analysis

This describes how to write/state requirements that will meet business needs. Key objectives include methods for prioritizing and organizing requirements, as well as the most beneficial techniques for requirements presentation (including state diagrams, prototyping, data flow diagrams, and process modeling, and more).

Business Requirements for future project investments are identified and documented.

They are defined at a high level, and include goals, objectives, and needs are identified

Business Requirements are collected from business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above).

That document identifies what will be the business solutions in generic terms

The Enterprise Architects will define the Architecture Vision phase based on the goals, and objectives of the enterprise gathered from the business.

There are two steps:

  1. Business people will have defined the goals and the objectives of the enterprise independently from the Enterprise Architecture team
  2. The Enterprise Architecture team which include business people gather the requirements based on the previous activity

Enterprise Analysis

Begins after a Business executive team develops strategic plans and goals

This outlines the crucial (and sometimes political) process of keeping everyone in the loop and on the same page regarding project's direction and progress. This activity delves into such details as the requirements review and approval processes (including record-keeping).

Most of these activities are taken into account in doing Enterprise Architecture or done directly by the Business executive team before starting an new Enterprise Architecture project

 

 

Strategic plan development

 

Done outside of the Enterprise Architecture process by business people but is a key source of information

 

Strategic goal development

 

This is done outside of the Enterprise Architecture initiative by business people but is a key source of information

 

Business Architecture development

 

Done during Phase B:Business Architecture, looking at the baseline and target architecture, delivering a gap analysis, a plan and a roadmap

 

Feasibility Studies

 

Done during Phase A: Architecture Vision (with a Business Scenario)

 

Business Case Development

 

Done during Phase A: Architecture Vision (with a Business Scenario)

 

New Project Proposal

 

This is done in two steps: during the Phase A where we identify a Business solution and during Phase F; Migration Planning

 

Selecting and Prioritizing New Projects

 

This is done in two steps: during the Phase A where we identify a Business solution and during Phase F; Migration Planning

 

Business Opportunities

 

This is done during the Phase A: Architecture Vision and the Phase E: Opportunities and Solutions

 

Launching New Projects

 

This is done during Phase F: Migration Planning

 

Managing Projects for Value

 

This is done during Phase F: Migration Planning

 

Tracking Project Benefits

 

Once the project is in production, it is no longer part of the Enterprise Initiative

Solution Assessment and Validation

Details how to choose the best solutions for specific business needs (as well as assessing how well the chosen solution worked after its implementation).This should also cover risks, dependencies, and limitations that must be identified before proposing any solution

Solutions are identified during Phase E.: Opportunities and Solutions.

This phase is directly concerned with implementation, identifying major work packages to be undertaken and creating a migration strategy.

Risk management, dependencies are taken into consideration.

 

Business Analysis Planning and Monitoring

Explains how to decide what you need to do to complete an "analyst effort" (in other words, how to plan a project). This helps intelligently decide which stakeholders, tools, tasks and techniques we will need to get the job done

Covered mostly in the Architecture Vision phase, then in the Business Architecture Phase

Stakeholder management techniques are used within TOGAF, tools and techniques are identified in the Business Architecture phase (modelling, reference models, viewpoints)

Requirements Management and Communication

Describes how to identify business needs (the why of the project; whereas requirements are the how) and state the scope of their solutions. This is a crucial piece of the analyst's work. SMART criteria of measurement, SWOT analysis and other measurement factors that make identifying this root cause data objective and tangible are used

Business Requirements are collected with the business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above).

SMART techniques are equally used.

Communication plans are defined.

This diagram below is a draft map BABOK® and TOGAF 9; more work is required!

Observations

There are obviously overlaps between Enterprise Analysis and Enterprise Architecture, but activities are not always done in the same sequence.

  • Enterprise Analysis is more a business initiative than an Enterprise Architecture which includes both business and IT people

  • Enterprise Analysis provides the context in which an Enterprise Architecture should be conducted

  • Enterprise Analysis is about defining the strategic goals and the strategic planning taking into account the environment and market trends, identify business issues, focus on remaining competitive, profitable, efficient. Enterprise Architecture is reusing all this information.

  • Enterprise Analysis is only covering the initial activities of Enterprise Architecture but does not address other Enterprise Architecture activities such as: - Application Architecture, Data Architecture, Technology Architecture (and Solution Architecture).

  • Enterprise Analysis does not include all aspects related to governance such as the IT Governance and the Enterprise Architecture Governance Framework. Touch points with other frameworks are not addressed.

  • Enterprise Analysis may not completely address the need of working with other parts of the enterprise such as IT, PMO, development teams, IT partners.

  • Enterprise Architecture suggest a Preliminary phase which is about defining ‘‘where, what, why, who, and how” Enterprise Architecture will be done, establishing the business context, customizing the framework, defining the architecture principles, establishing the Architecture Governance structure.

Enterprise Analysis complements Enterprise Architecture but also overlaps in some areas. Organization looking into Enterprise Architecture and specifically TOGAF 9 may consider adopting a Business Analysis framework such as BABOK and integrate them in the Preliminary Phase. If both approaches exist in a company, this would be a great opportunity for optimizing the alignment between Business and IT, and to run an Enterprise Architecture program from a complete business perspective.

About Business Analysis Body of Knowledge® (BABOK®)

The Business Analysis Body of Knowledge® (BABOK®) is the collection of knowledge within the profession of Business Analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the Business Analysis professionals who apply it in their daily work role. The BABOK® Guide describes Business Analysis areas of knowledge, their associated activities and the tasks and skills necessary to be effective in their execution. The BABOK® Guide is a reference for professional knowledge for Business Analysis and provides the basis for the Certified Business Analysis Professional™ (CBAP®) Certification.

BABOK® Guide 2.0 represents the development of a common framework to understand and define the practice of business analysis.

About TOGAF™

TOGAF is an industry standard architecture framework that may be used freely by any organization wishing to develop an information systems architecture for use within that organization.

TOGAF has been developed and continuously evolved since the mid-90’s by representatives of some of the world’s leading IT customer and vendor organizations, working in The Open Group's Architecture Forum. Details of the Forum, and its plans for evolving TOGAF in the current year, are given on the Architecture Forum web site.

About TOGAF Version 9 Enterprise Edition

TOGAF Version 9 Enterprise Edition ("TOGAF 9" for short) is a detailed method and set of supporting resources for developing an Enterprise Architecture. Developed and endorsed by the membership of The Open Group's Architecture Forum, TOGAF 9 represents an industry consensus framework and method for Enterprise Architecture that is available for use internally by any organization around the world - members and non-members of The Open Group alike - subject to license conditions - see Downloading TOGAF 9

As a comprehensive, open method for Enterprise Architecture, TOGAF 9 complements, and can be used in conjunction with, other frameworks that are more focused on specific aspects of architecture or for vertical sectors such as Government, Defense, and Finance

Author: Serge Thorn, CIO of Architecting the Enterprise

Currently developing and delivering new Enterprise Architecture consulting - training services (TOGAF 9) for many companies (Banking-Pharma-Major IT vendors). Implementing Governance and managing IT Operations within a consultancy company.

Before in charge of International Governance and Control implementing different best practices around IT Finance/Procurement, Audit/Risk management, Vendors Management (with Service Level Management) in a Bank.

Previously in a Pharmaceutical (Chemical) company, in charge of the worldwide Enterprise Architecture program and Governance, the IT Research & Innovation, following the reorganization of the IT Department, implementing Service Management based on ITIL Best Practices and deploying new processes: Change, Configuration, Release, and Capacity/Availability Management, responsible for the Disaster Recovery Plan and for the System Management team.

Prior to this, responsible of the Architecture team in an international bank, I have a wide experience in the deployment and management of information systems in Private Banking and Wealth Management environments, and also in the IT architectures domains, Internet, dealing rooms, inter-banking networks, Middle and Back-office. Also have been into ERP and CRM domains.

His main competences covers the perfect understanding of banking activities, and industry, the design of new systems, IT strategies, IT Governance and Control, Innovation, new technologies, Enterprise Architecture (including BPM) , Service Management (ITIL V 3), Quality System ISO 9001:2000, team management, project and portfolio management (PMI), IT Finance, organization and planning.

You can reach the author at www.architecting-the-enterprise.com or you can [email protected].

Like this article:
  27 members liked this article
Featured
86965 Views
3 Comments
27 Likes

COMMENTS

JulianSammy posted on Sunday, May 30, 2010 4:50 PM
I did a similar analysis a few years ago with TOGAF 8, and came to almost identical conclusions--though with a lot less detail! Thanks for the information.

It appears to me that the biggest differences between the BABOK and TOGAF are:
1. The BABOK is weighted toward execution of projects; TOGAF is weighted toward initiation of projects at the enterprise level.
2. The BABOK specifies dependencies in tasks, where TOGAF specifies a sequence of tasks. Practically this is often similar to an order of operations, but I have found it can lead to overly sequential actions instead of useful overlaps where possible.

I'm not sure your diagram mapping TOGAF to BABOK makes sense. If TOGAF is an enterprise-focussed implementation of the BABOK (as I posit above), then TOGAF A to H are all primarily related to three KAs: EA (most enterprise focus), SAV (straddles enterprise and project focus) and BAPM (more project focus, but with a strong enterprise view). The other KAs (E, RA, RMC) are executed primarily in the context of a project, and would connect (mostly) to the TOGAF 'Requirements' circle. Enterprise Architecture and Business Analysis can't be executed without these three.

From this perspective, the work an enterprise architect and and enterprise BA is what IIBA calls a 'hybrid BA' role; in this case, the EA or EBA has design and business analysis responsibilities. This is explicit (if muted) in BABOK v2, where the EA KA talks about proposing conceptual solutions to business problems (that's my wording, not the BABOK wording). It's the only place where BAs are expected to do 'design'. It's consistent with the definition of the role because it's part of the need-solution pair that should appear in a business case.

...I didn't expect to rant here. I liked the post, and will enjoy your response.
juliansammy
Jeff posted on Tuesday, June 1, 2010 10:06 AM
THis is a very helpful analysis and posting. I have been struggling with a good way to map the two different and growing fields (BA and EA) in a way that can be explained to a layperson. In practice there is an important dialog about who performs what role and it is crtical that the two groups work well together.

Thank you Serge for helping bring some clarity here.
wayraw
Anonymous User posted on Tuesday, June 15, 2010 4:32 PM
This is a well considered piece of analysis within the perspective and assumption that these two frameworks define 'Enterprise Analysis' and 'Enterprise Architecture' respectively. However I and many others consider both of these frameworks to fall well short of this ideal, as they reflect constrained, IT viewpoints of both areas, probably because they have been put together largely by IT people, and those looking at the world from an IT projects perspective.

When the scope of 'enterprise architecture' is cast in a broader perspective, where the locus of change is business rather than IT, 'enterprise analysis' becomes simply part of what is done in designing an 'enterprise architecture', with the focus on why/what, rather than how.
Anonymous
Only registered users may post comments.

 



 




Copyright 2006-2024 by Modern Analyst Media LLC