7 years, 2 months ago

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

Enterprise 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

DefinitionEnterprise Architecture (e.g TOGAF 9)Differences, observations
Requirements ElicitationThis 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 coveredPhase 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 ValidationDetails 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 MonitoringExplains 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 doneCovered mostly in the Architecture Vision phase, then in the Business Architecture PhaseStakeholder management techniques are used within TOGAF, tools and techniques are identified in the Business Architecture phase (modeling, reference models, viewpoints)
Requirements Management and CommunicationDescribes 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 usedBusiness 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!




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.


7 years, 3 months ago

UK Elections 2010 and IT – Labour Party Manifesto 2010

The Labour Party Manifesto 2010 which I referenced for the purpose of this blog can be accessed on this link.The most relevant mention of harnessing the power of Information Technology can be found in section 9:5 of the above listed document. The extra…

7 years, 3 months ago

UK Elections 2010 and Information Technology (IT)

As the UK elections 2010 campaigning gathers momentum, all three major political parties have published their manifestos, all PM candidates have already done two televised debates and hit the ground running in various parts of the UK to make us aware o…

7 years, 3 months ago

Key SOA Governance Considerations – Part 4

So far the articles 1, 2 and 3 in the series have addressed the SOA governance aspects such as, understanding the context, defining the objectives and parameters, understanding various components such as timing and artefacts to govern, roles and respo…

7 years, 3 months ago

Enterprise Architecture – Wikipedia

I was looking at the Wikipedia entry for EA and found this chart which does a great job showing the differences of ENTERPRISE Architecture vs. SOLUTION Architecture across several categories.  This really gets at the heart of a misconception many peop…

7 years, 3 months ago

Managing MSIT’s Enterprise Platform Portfolio

I have the fortunate opportunity to manage the Enterprise Platform portfolio for Microsoft IT and thought that I’d share some tidbits how I do it.

In Microsoft IT, the Enterprise Platform Portfolio (EPP) is only one program portfolio peer to other program portfolios like our Line-of-Business (LoB) specific portfolios such as Sales, Marketing, Services, HR, Legal, IT (yes, even IT is a LoB to us), etc. The EPP is a portfolio designed to manage our platform systems and encourage them to deliver more value to the company.

I’ve distilled the EPP’s Charter (aka Team Model, Process Model and Delivery Approach) into the following points to help articulate how I manage the EPP:

  1. Fund Platforms only. It seems simple enough, but defining what is a Platform and what isn’t like Application, Vendor Products, Processes, Capabilities, Locations, etc can be a bit tricky. We pulled our definitions from our Enterprise Information Model and elaborated on them to help communicate what qualifies for funding from the EPP and what doesn’t. We use a couple of views, one that is more loose and one more explicit to help communicate to different audiences. Here are a couple of diagrams that we use:

      Architecturally-pure Platform Diagram Exec-ready Platform Diagram 
      Enterprise Platform Definition 1 Enterprise Platform Definition 2

            • An Enterprise Platform is a set of Components where one or more of those Components are used by more than one Application. More than one Line of Business uses these Applications.

            • An Enterprise Platform may master a Data Facet.

        • Fund non-discretionary costs first, then allocate the remaining budget based on criteria intentionally used for the Platform to deliver business value. Here is our prioritization criteria as a reference:

            Business Alignment


            Relation to Goal Prioritization

            Does the Platform relate to highest priority Business Goals?


            Capability Assessment

            Does the Platform relate to priority Business Capabilities Assessment (Value, Performance and Maturity)


            Business on-boarding Commitment

            Can the Platform demonstrate commitment from multiple businesses?

            Portfolio Simplification  

            # of Redundant Apps and Plats

            • Will the Platform reduce redundant Applications/Platforms?

            • Will the Platform retire similar functioning Applications/Platforms slated for retirement?


            Retirement of Unsupported Vendor Products

            Will the Platform retire the use of unsupported vendor products?

            Platform Excellence


            Information Quality

            Will the Platform improve information quality; make information more accurate and available?


            Regulatory Compliance

            Will the Platform help Microsoft comply with Regulatory Compliance?


            Security and Privacy Policy Alignment

            Does the Platform comply with Security and Privacy Policies?


            Flexibility, Maintainability

            • Flexibility to support many Business Processes

            • Self-service

        • Solicit senior Architects to form a role-based Team Model. I’ve created a Team Model with 5 voting members filled by Microsoft IT’s most senior Architects. Each advocate 5 different perspectives of our Platforms investments; Business Advocate, Enterprise Architecture Advocate, Technology Use and Incubation Advocate, Platform Software Quality Advocate, Operations Advocate. It’s important not to make this team model reflective of the organizational team model but rather a set of perspectives of a platform. This avoids the situation of having organizational-bias in the voting and commentary of Programs in the Portfolio.
        • Platform Roadmaps. We use Platform Roadmaps to document what the Platform will do. The entities on a Platform Roadmap mirror the information in our Prioritization Criteria. That is, a Platform Roadmap includes all associated Business Goals related to the Program affecting the Platform, Business Capabilities and Process Flows improved, Applications and Platforms that will be retired as a result of the Platform, supporting Vendor Products, etc. We equate Platform Roadmaps to a sort of contract or agreement that the Program must adhere to. During the Program’s delivery, we run current Program information and compare it to the Roadmap to determine we the Program is on-plan or not. From the EPP’s perspective, the Platform Roadmap is the scope of the Program.
        • Enterprise Architecture to manage the EPP. Managing the EPP is the responsibility of our Enterprise Architecture team. This is important because the Platforms are an enterprise concern and require skills plus organization position to perform the necessary analysis to optimize our platform portfolio. For example, we perform analysis to form our Platform Strategy that includes cross-LoB needs analysis, associations to our enterprise data facets, application and platform consolidation methods, vendor products analysis to optimize our licensing and support contracts. Also, being positioned outside of the typical IT value chain (LoB-facing resources, engineering/development, and support) allows us to easily traverse the organization and remove organizational bias.
        • Data-driven funding allocation process flow to balance the portfolio. I’ve put together a relatively simple funding allocation process flow which allocates funding to Programs via decision points. For example, if a Program is in-flight, we allocate funds to ensure its original scope is delivered. If a Program requires funding to become compliant, we allocate compliance funds. One thing that we do to help spread the funds so that we don’t find ourselves shoveling all our available funds into one or two programs is utilize the concept of ‘seed’ funding. Seed funding is a limited amount of funds to allow a team to prove themselves per our Prioritization Criteria listed above. In our situation, we have some platforms that veer off-plan, therefore, score low on our Prioritization Criteria. In these situations, we limit funding to simply allocating non-discretionary funding and then seed fund them to get them back on track. This allows us to spread the funds further and fund new Programs and course-correct existing Platforms. Our customers perceive this as IT being more agile to changing business needs. For our funding allocation process flow to work, we must make the decisions data-driven to remove opinion and bias as much as possible. This is where my senior architects come into play. That is, they vote Y/N on each Prioritization Criteria for each Program. Those that rank higher are pushed through the funding allocation process first. We iterate through the funding allocation process flow until all available budget is allocated. Then draw the line leaving us with a list of which Programs are funded, what scope is being funded.
        • Continuously invest in Portfolio Management maturity. There are always improvements to ensure the platform portfolio is managed to deliver the most business value possible. The more mature the portfolio management, the more business value realized. Capabilities such as:

          • Portfolio Optimization in terms of
            • Program Dependency Analysis to understand when Programs can be hydrated to optimize resource allocation.
            • Program Overlaps and suggestions for what should happen to them.
            • Platform Strategy to understand where we want Platforms to go directionally and how to get there via promotion of Applications, retirement of Applications and Platforms, etc
            • Program Gaps to be filled as a results of analysis of Business Strategy
          • Strengthening the Portfolio Management Team to sit on funded Program Teams to guide and ensure delivery to stated Platform Roadmaps
          • General continuous improvement

        I’m curious to learn what others do to manage platforms. Please share your thoughts if you have a moment.

        Categories Uncategorized
        7 years, 3 months ago

        A Good Cloud and A Bad Cloud…

        An interesting time to write about cloud, what with the ash cloud from Iceland volcano grounding air travel in and out of Europe to complete halt. Usually the views from my office window are dominated by planes which are either taking-off or landing at…