Carnival of Business Analysts # 8 - Enterprise Analysis

Previously in the Carnival of Business Analysts we have investigated several of the knowledge areas described in the BABOK (v1.6)

• Solution Assessment and Validation
• Requirements Communication
• Requirements Analysis
• Requirements Elicitation
• Requirements Planning
• The BA and Quality
• The role of the BA

This month we are looking at Enterprise Analysis area of BABOK(v1.6).

The BABOK defines Enterprise Analysis as:

"Enterprise Analysis is the Knowledge Area of the Business Analysis Body of Knowledge (BA BoK) that describes the Business Analysis activities that take place for organizations to (1) identify business opportunities, (2) build their Business Architecture framework, and (3) determine the optimum project investment path for the enterprise, including implementation of new business and technical system solutions."

There is a great chart (Table 1.0 in Chapter 2 of the BA BoK) that shows the activities involved in Enterprise Analysis and what the role of the Business Analyst is in each of them. An enterprise level view is needed to ensure that the business value of projects meet the needs of the entire organization.

When looking for good articles on Enterprise Analysis, there are some resources out there that can be leveraged. Now that Enterprise Architecture is beginning to mature as a field, there are more and more resources available to help you improve your skills or give you ideas on what to do to be successful.

In his blog, Andy Blumenthal has an article called The Business Analyst and Enterprise Architecture. This article is a great description of how the Business Analyst relates to the Enterprise Architect. I don't agree with every word, but I think he gets pretty close to the crux of the matter.

In the article The rise of the enterprise architect Daljit Roy Banger talks about what a good enterprise architect needs to know. He also takes a stab at describing how to choose someone as an enterprise architect. Once you've decided that you need more Enterprise Analysis this is a good piece to get you started on what makes a good Enterprise Architect. It is heavily tilted toward the technical side of EA which is both good and bad depending on your organization.

At Agile EA, there are several whitepapers that address doing Enterprise Architecture in an Agile manner. The first two are about how to do Enterprise Analysis using an Agile methodology. They're a good idea for how to go about the process of Enterprise Analysis. The crosswalk between the two sets of activities needs to be done, but the Agile methodology works well for collaborative efforts - I'm sure it can bring some value to the Enterprise Analysis area as well.

The “Building a case for Agile Enterprise Architecture pt. 1” whitepaper at Agile EA references The Open Group Architecture Framework (TOGAF) quite a bit. Definitely a group worth reviewing when implementing the Enterprise Analysis practice area.

At BA Insight, there is an article from May of last year that still has value today. On Enterprise Analysis and Strategic Thinking talks about how Enterprise Analysis should be performed by BAs but is quite often ignored.

And of course, we can't forget our own with this great post by Craig which includes a link to some EA community blogs.

Enterprise Analysis is a key part of any business so it is the best interest of every business analyst to understand how to do it.

Project Management
Business Analyst

A beginners guide to Enterprise Architecture

Here are some Enterprise Archiecture resources that may assist in your research on the topic. They are presented as a starting point for research into the role and the issues that the profession faces today.

Your comments about the contents are encouraged as I am fairly new to the topic. Any other suggestions for inclusion on this list are very welcome.

• The Journal of Enterprise Architecture published by the Association of Enterprise Architects
• The Association of Open Group Architects
• Bredemeyer Consulting have an interesting and long links/references page for Enterprise Architecture
• You can read blogs on EA via this Technorati link
• Robert McIlree also hosts a Blog carnival for Enterprise Architects at his blog
  

Project Management
Business Analyst

Enterprise Architecture and Business Analysis

There is a community of Enterprise Architects out there with a handful of activie bloggers. (You may have read my post a few days ago from Nick Malik for example.)

When you look at the role of the EA you see it's about planning and macro level design of the technology environment of an organisation. It addreses the need to balance the short term needs to get things done with the need for a scalable an uncertain future.

The Enterpise Architects I have met came to the role from business analysis, so it's not surprising that the BABOK (v1.6) identifies Enterprise Analysis as one of the key knowledge areas for Business Analysts. (Solution architects I know tend to have been developers.)

"Enterprise Analysis is the Knowledge Area of the Business Analysis Body of Knowledge (BA BoK) that describes the Business Analysis activities that take place for organizations to

1. identify business opportunities,
2. Build their Business Architecture framework, and
3. determine the optimum project investment path for the enterprise, including implementation of new business and technical system solutions."

The BABOK goes on to characterise Enterprise Analysis as mainly pre-project work that is involved in project portfolio planning, feasibility studies, strategic planning and busienss architecture.

It's focus is on the business side of the business/technology divide, but as a consequence of that macro level view technology infrastructure is included in it's application.

The Business Architecture describes the businesses strategy, its long term goals and objectives, the high level business environment through a process or functional view, the technological environment, and the external environment. It also defines the relevant stakeholders, such as the government, regulatory agencies, customers, employees, etc.

According to the BABOK, business architecure is one of five dimensions of Enterprise Architecture;

1. Business Architecture
2. Information Architecture
3. Application Architecture
4. Technology Architecture
5. Security Architecture

This context is interesting and is part of a wider conversation about the degree to which IT drives business decisions and how appropriate that is.

I am sure it is one our Enterprise Architect friends have views on.

Project Management
Business Analyst Enterprise Architect

Nick Malik on Enterprise Architecture

One of the roles that project managers and business analysts interact with is the Enterprise Architect. PMs and BAs are different to Architects, but they all play around in the same space of designing and implementing the future of the organization.

I thought I should explore the role to deepen my understanding of it. So I went to Nick Malik, blogger and Enterprise architect at Microsoft, which is a largish organization that some of you may have heard of.

He was generous enough to share his views with us here;

1. EA, done right, gets involved before PMs do.

There is no project yet... just a business goal. EAs help the business decide if they should create a project, and if so, what area of the IT infrastructure to focus that project on. Once the project starts, EA is basically a governance job. So if you dislike governance (and we all do), and you find yourself wondering what value EA adds, perhaps you are missing all the work that goes on when you aren't in the room.

2. EA has two jobs: Project portfolio and Application portfolio.
If you look at their work from the standpoint of one, and not the other, EA people will appear to do crazy counterproductive things. You have two choices: try to see the world from both viewpoints, or trust your EA.

3. Business architecture adds the most value when they point out that the business is about to spend money on something foolish.
If your job as BA is to demonstrate alignment, without ever demonstrating a lack of alignment, then you are skipping the fun (and valuable) part.

4. The future cannot be found in an ivory tower.
That said, if someone doesn't spend a LOT of time envisioning the future, then an IT division is doomed to wander aimlessly. Support the envisioning work that your EA is doing. On the other hand, the ability to envision may or may not come attached to the ability to communicate. If you can't see how to use the work of an EA in your project, ask him or her to explain it to you. If he cannot, tell his manager. Don't let it lie. Things get worse when you (a) ignore the EA, or (b) allow a bad EA to linger. Every profession has a few turkeys.

5. Some EA folks assume that the PM will simply accept EA requirements into their project and "go sell" the requirements back to the customer.
If you meet an EA of this stripe, tell him to sell the requirements back to the customer himself. If he cannot, then the EA should pony up either the governance, or the cash, to get standardized or external requirements into your project. Don't sign up to spend your customer's money on standardized or external requirements unless the business signs off or funding appears from another source. EA is not free. Make him work for it. But once a requirement is in, treat it as seriously as any business requirement. If it is in, and funded, make sure it happens.

6. The EA is not responsible for organizing your project or bringing it to fruit.
The PM is. However, the way in which the project is partitioned, in the architecture, may place intricate interdependencies into the system, making a well designed project impossible to deliver. Therefore, keep you architect on a tight leash. If he creates an intricate design, especially one based on SOA, get him to also detail out the order in which the components are to be coded, integrated, tested, and rolled out. If you don't, you could end up signing up to drive in the Indy 500... in a bus... backwards.

If you would like to read more of Nick’s thoughts, his blog is “Inside Architecture”.

Project Management
Business Analyst