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

Requirements Re-use - Myth or reality?

Years ago, back when RM tools were in their infancy, (are they mature yet?) I advocated to my employer that a database of requirements would be a great idea.

It would save time in eliciting requirements, socialising them across management and stakeholder team and constructing requirements documents

The database, if implemented, would create a more consistent approach to requirements which would in turn make solution design faster and cheaper and provide a platform for better solution architecture and better requirements (through review and continual improvement activities.)

I understand they have now implemented such a database, but it doesn’t look what I had in mind, and it doesn’t come with the management processes (above) that I had wrapped around the database.

That experience and my other experiences in large enterprises lead me to conclude that capacity for requirements re-use is a rare talent, and that, for most businesses there are a lot of other investment priorities ahead in the queue.

The development of the BA and Enterprise Architecture professions are steps towards capability for re-use of requirements, but really, it’s not effectively happening anywhere I have worked.

It’s coming, but… it’s a rare enterprise that has it organised at this stage.

Have a look at this model I put together and think about the issues involved in requirements re-use. Are your requirements re-useable for other projects for the same system? Will they be useable on other system developments within your existing programme? Will they be re-useable on totally new projects?

Overlay the ideas against the People, Process and Technology lenses and have a think about the issues you could face.

What’s re-useable on your project?

Project Management
Business Analyst

Enterprise Analysis

What is Enterprise Analysis?

According to version 1.6 of the BABOK, Enterprise Analysis is the strategic part of the project life cycle. It includes

• developing strategic goals and a strategic plan to get there,
• understanding and developing the business architecture,
• selecting the right solution approaches for projects and developing their business cases, and
• initiating projects and making sure they deliver value to the sponsor

All of these things are strategic activities that bookend the project life cycle.

Chapter 2 of the BABOK (v1.6) describes these activities in more detail and you should go check it out today. It’s a fascinating topic and I commend the IIBA for including it in the practitioners’ guide.

Project Management
Business Analyst

What is Enterprise Analysis?

According to version 1.6 of the BABOK, Enterprise Analysis is the strategic part of the project lifecycle. It includes;

• developing strategic goals and a strategic plan to get there,
• understanding and developing the business achitecture,
• selecting the right solution approaches for projects and developing their business cases, and
• initiating projects and making sure they deliver value to the sponsor

All of these things are strategic activities that bookend the project lifecycle.

Chapter 2 of the BABOK (v1.6) describes these activities in more detail and you should go check it out today. It’s a fascinating topic and I commend the IIBA for including it in the practitioners’ guide.

Project Management
Business Analyst

Picture originally from

Coach Carol, here at Flickr.

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

Service oriented architecture for organisational design

SOA is a term developed for IT architecture. It's an equally valid concept for organisational architecture.

High level it's about creating a number of service oriented components that can be called upon to deliver services. It goes nicely with business process management systems.

Think of a system that takes an applications for a loan, calls out to a credit checking tool, get a result and move to the next step, calls out to a document generator and produces a letter of offer, gets a result and then proceeds to the next step. That's service orientation.

Now transfer this idea to business process design and organisational design - business architecture.

Tom Peters wrote a piece called The PSF is Everything! a few years ago calling on departments and teams everywhere to become service oriented in order to support an organisation's quest to be excellent. I recommend reading it for a bit of TP style inspiration, but also to get the idea around the importance of taking on a service oriented approach to teams and departments in order to do well at the big picture level.

The same principles apply to business as in IT: Loosely coupled, easy interface business units that provide a reliable and high quality service make for a more agile and efficient business. These feature provide for less rework, less errors and waste, and more working together as a team to face whatever monster we are up against this month/quarter/year.

Let me list out these key points for you;

• Loosely coupled
• Easy interface
• High quality

When you look around at the corporations you find that most businesses don't work like this. Instead high performing individuals (often boundary spanners) are the ones that oil the machine into working.

When you are designing the future state of your organisation, what, as an analyst or change agent, can you do to improve things?

Project Management
Business Analyst

Top Down, Bottom Up Analysis

Taking a top down and bottom up approach to business analysis is a useful method, especially when working with business processes.

I recommend it to analysts who are mapping a whole business or large departments. It helps check whether the purpose of a business process is actually being met by the myriad details below it; a reconciliation.

It also helps analyse whether activities are aligned with the strategic objective of the process. If not it's a trigger to investigate and challenge the activity a bit more rigorously.

The assumption is when you investigate the top level process with senior execs, they are most closely aligned with the business strategy, and that as you drill into the detail front line workers are much less likely to be aligned with strategy and more likely to be focused on their local turf, which may be based on things such as customer experience, timeliness or cost.

While front line activities may seem sensible and good, they may not be aligned with business strategy. Or short term satisfaction may be gained at the cost of the overall customer experience. (Jonathan Babcock presents a hypothetical example of this in his blog.)

Whether you are analysing the current state or designing the future , make sure you include the top down part of the analysis and don't just go work shopping and interviewing your way through front line workers activities. It may eem like extra effort today, but it will mean your work will be of a higher quality and of more business value.

Project Management
Business Analyst

Image Details: View of Manhattan from Empire State Building

Author: Luigi Scarantino
URL: http://www.infoturisti.com