How to bring TOGAF to life

Why Enterprise Architects should use TOGAF

2007-10-20T02:33:00.000-07:00

Objective: To understand why a company should use TOGAF as the methodology to define its IT vision and architecture.

Tool: The management of chaos

Topic: Enterprise Architecture and The Open Group Architecture Framework

When the famous architect, Christopher Wren, designed the Saint Paul’s Cathedral for London in 1673, he envisioned a monument to a single purpose that would remain unchanged for generations. Many software solutions have been built with the same end in mind and have become redundant within a single generation, due to the demands of a single requirement . . . unlike Cathedrals, technology solutions have to adapt to an environment in which there is constant change.

Technology solutions, therefore, must be more like eco-systems than traditional architectures. Eco-systems describe environments that evolve, meaning that they remain viable in the face of change and they strike a balance between flexibility, manageability and adaptability.

Anyone who has studied Complex Systems Theory will recognise the fact that the balance between flexibility, manageability and adaptability is a very fine line. It was defined by Langton in the 1980s, as The Edge of Chaos. The point where systems are:

stable enough to remain viable, and yet
adaptable enough to be spontaneous, adaptive, and alive.

Does all the current discussion in IT regarding agile computing come to mind here?

Successful complex systems tend to locate themselves at the edge of chaos, where there is sufficient innovation to keep the system vibrant, but enough stability to prevent a collapse into anarchy. Examples include companies operating in the marketplace, the human brain and (of course) an Enterprise Architecture.

In complex systems theory, turbulence is caused by the spontaneous interactions between parts of the system and the changing environment. It is this turbulence that creates the service interruptions that businesses struggle against each day, in both their competitive environment and their technology environment.

This was clearly demonstrated in early client/server systems which poured new technologies into the environment before the management tools and processes were in place, creating unpredictable imbalances in service and, in some cases, true chaos.

Warren G Bennis once said "The factory of the future will have only two employees: a man and a dog. The man will be there to feed the dog. The dog will be there to stop the man touching the computer." We clearly have a way to go yet. Most of today's computers have so may men touching them that forensic scientists dream of using them for fingerprint practice, and corporations are employing so many dogs that new service industries are appearing just to administer the leads.

In any modern enterprise Information Technology has become a complex eco-system, with the applications being used to support the business sitting along side the systems being used to monitor those applications, and all the time, the environment is clearly changing, both for the business and the technologies.

So what complex systems theory helps us to understand is that we could focus our efforts on:

Flexibility, to the extent that our systems become unmanageable
Control, to the extent that our systems cannot respond to new circumstances
Change, to the extent that we fail to exploit successful models and patterns

IT professionals can use this information to reinforce a fundamental principle, that flexibility and adaptability must be balanced by visibility and manageability. In other words, we must wrap our eco-system within a framework of principles, governance and planning, as shown here:

Companies should select The Open Group Architecture Framework (TOGAF) because it provides a structured means of envisioning and describing the Enterprise Architecture plus the planning and governance required to ensure success during its implementation and operation.

TOGAF defines the deliverables (artefacts) of Enterprise Architecture as:
“the technical specification of all behaviour that goes on in an organization, the data that is processed, who does what, where everything is, and why everything is done”. It is therefore one of the tools you need to survive at the edge of chaos, along with strong governance processes and a commitment to an agile environment such as a true service oriented architecture.

This blog (with its various postings) provides a practical approach to making TOGAF work for you. I am usually involved in projects that are categorized by the Open Group as “top down planning” where the whole meta-enterprise is designed as a single entity, albeit composed of a multitude of collaborating components, but the same tools and techniques should apply for projects where the scope may not be the entire enterprise ... let me know what you think.

Start by thinking about the Business Architecture . . .

Blogger:

How to develop a complete picture of an organization's baseline architecture for TOGAF

2007-10-20T02:11:00.000-07:00

Objective: To capture a view of the current state of an organization's existing IT architecture, as a baseline for comparing with the defined target state, identifying gaps that must be addressed and planning a programme of work for the migration.

Tool: Current state architecture modelling and documenting

Pre-requisite reading: Business Architecture (TOGAF phase B)

A fundamental activity during phases B, C and D of the TOGAF methodology involves developing complete views of an organization’s current state (baseline) and future state (target) processing capabilities. It is by comparing these two views, in the context of the IT vision and principles, which you developed during TOGAF phase A, that you can start to identify the gaps that must be addressed and the migration plan for achieving it.

This blog concentrates on the technique I have used successfully, to develop a baseline view that can develop a practical and useable understanding of an organization’s current state.

I will use other blogs to explain:

How to build a complete picture of an organization’s targetstate. This will include the organization’s goals and objectives.
How to conduct TOGAF phase E. This is where you’ll identify the gaps between the baseline and the target state.
How to develop a migration roadmap. This plan will comprise a set of investment projects aimed at delivering new capabilities, and a set of reengineering projects aimed at transforming the existing cost structure.

FIRST PRINCIPLES: Before you start developing your baseline view, there are a few principles you should bear in mind:

Structure: You must organize the information you capture in a way that makes it accessible to the people who need to understand it and, more important, the people who will rely on the information to rapidly specify and execute the programme of migration projects you will identify during TOGAF phase E.

The primary elements of structure you need are:
- the ability to capture lists or catalogues,
- the ability to cross-reference one catalogue against another, and
- the ability to print, export and share the information.
Packaged Enterprise Architecture tools provide this structure and are functionally rich. However, spreadsheets provide an adequate tool for capturing information on the baseline view, since they deliver ease of use as well as the structure you require. This blog assumes that you are using a spreadsheet to capture your current-state information.

I will refer to this spreadsheet as the Enterprise Architecture Workbook or EAW. You will constantly build up workbook until you reach phase E in the TOGAF methodology (Opportunity and Solutions Management) that represents the pivot point in your Enterprise Architecture project, where the focus switches from data collection to planning. Phase E is where you start to analyse the current and target state information you've captured, identifying gaps and seeking solutions to those gaps.

Outcome: Keep in mind that the information you collect must provide the justification, scope and objectives for the various migration projects. Be thorough but focus your effort on the areas where the organization will benefit from most. My blogs on business architecture and the value chain should help you in this regard.

Artefacts: The information regarding the baseline architecture, which you capture in your Enterprise Architecture Workbook (EAW), will comprise the following elements:
1. Catalogues: These are essentially separate lists (worksheets) of things that you wish to describe, including organizations, stakeholders, processes, applications, etc. Picture each list as a set of rows in a worksheet, with columns for each of the attributes you wish to record.
2. Cross references: These are essentially worksheets where you map one catalogue against another so that you can record additional information in the intersecting cell. For example: if you cross reference organizational units against applications, you could record which departments use which applications (perhaps using colour) and the release level currently implemented (perhaps as text).

DEVELOPING YOUR CATALOGUES: Which may include the following:

Catalogue of business scenarios: A catalogue of the organization's value chain functions

Use the value chain concept to develop an understanding of the organization's primary and secondary activities. Refer to my blog on the value chain model for some ideas [click here].
1. Add a new worksheet to your EAW, to catalogue the value-chain functions.
2. Name this worksheet Catalog Business Processes.
3. Start with these columns:
  1. Column A = Identity: Every business activity must have a unique number (e.g., BS-sss (where sss is the value chain activity or scenario number).
  2. Column B = Name: Every business activity must have a unique name conforming to the convention “Action” “Object” (e.g., “Manage Relationships”, “Manage Sales & Orders”).
  3. Column C = Description: Every business activity must be clearly described so that you and others can start to have meaningful discussion.
4. Add a separate row to describe each business scenario you identify in the value-chain analysis. You should expect to have a catalogue of between 10 and 20 business activities for a typical small-to-medium sized enterprise or a division of a larger organization.
Catalogue of business processes: A catalogue of the organization's business processes by value chain function (scenario)

Use your model of the organization’s value chain(s) as a skeleton for developing a view of its business processes. Build upon that understanding by reading any available material and by conducting interviews with key business and technology decision makers and subject-matter experts. Review my blog on business architecture interviews, to get some ideas on how this can be done effectively [click here].
1. Reuse the same worksheet you just added to your EAW and named Catalog Business Processes.
2. Insert rows for 10 or more business processes, under each of the scenarios (activities) you identified during your value-chain analysis. Expect this number to grow over time, as you learn more about each part of the business. Focus on the value chain activities that fall within the scope of your project, although that may have to comprise processes that are effectively interfaces (that hand off work) into other competencies.
3. Reuse the same columns:
  1. Column A = Identity: Every business process must have a unique number in the form BS-sss-ppp (where ppp is the number for the business process).
  2. Column B = Name: Every business process must have a unique name conforming to the convention “Action” “Object” (e.g., “Administer Leads”, “Administer Contract”). Note: I used the term "administer" for processes that are a collection of use-cases that include create/read/update/delete/list/view/etc.
  3. Column C = Description: Every business process must be clearly described so that you and others can start to have meaningful discussion.
Catalogue of stakeholders and/or organizational units: A catalogue of entities linked to value chain activities

The breadth of detail you need about organizational units will relate to the scope of your Enterprise Architecture project and may focus on strategic business units and their main departments, or may focus on the teams in one department or business unit, or some other scope. Defining this scope is an important part of the framework phase in TOGAF.

Validate your list of stakeholders (or organizational units) against your list of value chain functions. Make sure that you understand which stakeholders fulfil each function and the various provider/consumer relationships between them.
1. Add a new worksheet to your EAW.
2. Name this worksheet Catalog Stakeholders.
3. Choose suitable columns (for example):
  1. Column A = Business Unit: Every business unit must have a unique number (e.g., BU-uuu).
  2. Column B = Name: Every business unit (and stakeholder) must have a name.
  3. Column C = Description: Document what the business unit or stakeholder does.
  4. Insert rows for every business unit and/or department within the scope of your project.
  5. Additional rows for individual stakeholders may be added under each business unit (e.g., BU-uuu-sss).
Catalogue of current-state applications: A structured list of all the applications being used across the organization

There are many ways to develop a complete inventory of existing applications so I will use a separate blog to describe the approach I prefer to use. For the purposes of this blog, let’s assume that you’ll simply capture a list of applications as you become aware of them, perhaps organized hierarchically within either the business unit or the value chain where they are used.
1. Add a new worksheet to your EAW.
2. Name this worksheet Catalog CS applications.
3. Choose suitable columns (for example):
  1. Column A = Identity: Every application must have a unique number and a row in the worksheet (e.g., CS-sss-aaa where sss is the value-chain identifier and aaa is the application number).
  2. Column B = Name: Every application must have a name.
  3. Column C = Description: Document what the application does.
  4. Column D = Vendor: Record the name and details of the supplier.
  5. Column E = Asset: For companies that manage or monitor applications using a specific mechanism, then you’ll find it useful to include that tag as a cross-reference (e.g., the application’s number in the asset register or the Enterprise Management tool like OpenView).
  6. Add any other columns that are appropriate to your project. I often include columns for the platform type (e.g., Linux, Windows, ...), the container type (Tomcat, JBoss, .Net, ...) the database type (e.g., Oracle, Open Source, Sql Server, ...) and various attributes such as “Stores sensitive data”.

The various catalogues you have developed above represent raw facts. In order to build an understanding of the baseline architecture you now need to use these facts as the dimensions of a matrix, in which you can start to add details that will enable you to analyse the information and justify decisions you make later in the TOGAF process. So, let’s talk about a few matrices you might find useful.

DEVELOPING CROSS-REFERENCES BETWEEN CATALOGUES: Which may include the following:

Processes versus Stakeholders: A mapping of business scenarios and business processes against organizational units and/or stakeholders.

This cross-reference worksheet is used to understand the link between value chain activities (described using your process catalogue) and the various business units, departments or user communities (described using your stakeholder catalogue).
1. Add a new worksheet to your EAW.
2. Name this worksheet Map Process-to-Stakeholder.
3. Link the rows to the “Catalog Business Processes” so that columns A (identity) and B (name) get replicated automatically.
4. Link the columns (starting at column E) to the “Catalog Stakeholders” so that rows 1 (identity) and 2 (name) get replicated automatically.
5. Fill in the content of the intersecting cells with any information that is appropriate to the goals of your enterprise architecture project. This might typically include an indication of which stakeholders are responsible for (i.e., own) the process, which provide input (i.e., supply) to the process, and which care about the output (i.e., demand) from the process. This knowledge will prove very useful when you want to interview people about the process, to understand it in greater detail.
Processes versus Applications: A mapping of business scenarios and business processes against applications that currently exist and are performing that function.

This cross-reference worksheet is used to understand the link between value chain activities (described using your process catalogue) and the various applications that are being used around the organization (described using your current-state application catalogue).

Two significant points to mention here:
- First, your catalogue of business processes must be defined at a consistent level of detail. Therefore, it is quite normal that many applications will be performing more than one process. It is also quite possible that one application is not performing all of the processes you’ve specified for a scenario, because people buy tools that meet their needs rather than all their wants.
- Second, you should expect that more than one application (and possibly several) will be performing the very same set of processes, since process redundancy is a common curse in enterprises everywhere.
1. Add a new worksheet to your EAW.
2. Name this worksheet Map Process-to-Application.
3. Link the rows to the “Catalog Business Processes” so that columns A (identity) and B (name) get replicated automatically.
4. Link the columns (starting at column E) to the “Catalog CS applications” so that rows 1 (identity) and 2 (name) get replicated automatically.
5. Fill in the content of the intersecting cells with any information that is appropriate to the goals of your enterprise architecture project. This might typically include a simple indication of which applications are performing that function and any details you wish to record about how the application operates (e.g., limitations in functionality, where manual intervention is required, where interfaces are available). This knowledge will prove very useful when making decisions over which of the existing (baseline) applications are good candidates for migration to the future state.
Applications versus Organizations: A mapping of existing applications against the organizations that currently use them.

This cross-reference worksheet is used to understand the link between the various applications that are being used around the organization (described using your current-state application catalogue) and the business units or departments within the scope of your project (described using your organization catalogue).
1. Add a new worksheet to your EAW.
2. Name this worksheet Map Application-to-Organization.
3. Link the rows to the “Catalog CS applications” so that columns A (identity) and B (name) get replicated automatically.
4. Link the columns (starting at column E) to the “Catalog Stakeholders” so that rows 1 (identity) and 2 (name) get replicated automatically.
5. Fill in the content of the intersecting cells with any information that is appropriate to the goals of your enterprise architecture project. This might typically include a simple indication of which applications are being used by which part of the organization. This knowledge will prove to be useful when you need to understand which parts of the organization will be affected by the transformation plans you develop later.

Blogger:

How to get the most out of Enterprise Architecture interviews

2007-09-29T02:29:00.000-07:00

Objective: To gain the best understanding of an organization and to gain the most actionable information from interviews conducted throughout the TOGAF Enterprise Architecture methodology.

Tool: Interview Technique

Topic: Business Architecture (TOGAF phase B)

To use the TOGAF Enterprise Architecture methodology successfully, you will need a thorough understanding of the organization, business unit, department – whichever is the scope of your project. In order to obtain this knowledge you, as Enterprise Architect, need to read all the available material and discuss the business with key stakeholders.

Although your selection and analysis of material is relatively easy (e.g., strategic plan, annual report, marketing and operational documentation, etc.) because they have a structure that is inherently organised and accessible, the same is not true for the discussions you will have with the stakeholders.

This blog explains the technique I have used successfully, to organize, structure, document and analyse interviews with leaders of a company.

The fact is that an Enterprise Architect will constantly be conducting interviews, but there are specifically two points in the TOGAF methodology where it becomes the primary tool of the job. They are during the:

Business Architecture, when the aim is to understand the existing business model and the goals of the company.
Information Systems Architecture, when the aim is to understand the existing application portfolio and the value-chain functions (business processes) being performed by each application.

The answer is, as always, to prepare and to be prepared. Here are some suggestions regarding business architecture interviews that I’ve used and have found to be successful . . .

Before I talk about the actual interviewing process, it’s worth reminding you (since you may have missed my other blogs) that I prefer to document my Enterprise Architectures using spreadsheets, because the ability to easily add columns and create cross-references between dimensions becomes extremely useful later (especially after TOGAF phase D). So, the following blog will keep referring to the Enterprise Architecture workbook, which comprises a large number of worksheets, some of which are catalogues (lists of things) while others are cross-references (mapping two catalogues against each other with additional information at the intersections).

Business Architecture Interviews

Identify the business activities of the organization’s value-chain

value-chain of the company

secondary value-chain activities

Prepare a catalogue of value-chain functions

value-chain functions (business activities)

Catalog Business Processes

Column A = Identity: Every business activity must have a unique number (e.g., BS-nnn).
Column B = Name: Every business activity must have a unique name conforming to the convention “Action” “Object” (e.g., “Manage Relationships”, “Manage Sales & Orders”).
Column C = Description: Every business activity must be clearly described so that you and others can start to have meaningful discussion.

Prepare a catalogue of interview scripts per business activity

What are the primary deliverables (products) and where do they go next?
What are the primary inputs (materials) and where do they come from?
What are the stages that create the deliverables from the inputs? What are they called? Who owns each of them?
Which systems (whether IT, manual or another means) are used at each stage?

Catalog Interview Scripts

Catalog Business Processes

Column A = Identity: Every interview script must have a unique number (e.g., IS-nnn).
Column B = Name: Should match the name of the Business Activity used in the Catalog Business Processes.
Column C = Description: The script itself comprising a set of numbered questions, grouped into logical discussion topics.

Prepare a catalogue of target business units

Catalog Business Entities

Column A = Identity: Every business entity must have a unique number (e.g., BU-nnn).
Column B = Name: Should match the description commonly used in the organization.
Column C = Description: A statement about what the team, group, department or business unit does, plus its location and main contact name (such as its leader or administrator).

Identify your target audience

Map Interviewee-to-Script

Column A = Business Entity: As listed in your catalogue of business units.
Column B = Name: The interviewee’s name.
Column C = Description: The interviewee’s job title.
Column D = Appointment: The date and time of the meeting.

Map the target audience to the appropriate interview scripts

your

Map Interviewee-to-Script

Column E-onwards = Scripts: The name of a script (and business activity). One column for each, linked to the Catalog Interview Scripts.

Interview Etiquette

Be on time (so, don’t book two meetings back-to-back without time to transfer).
Thank the participant for making the time available (at the start and again at the end).
Explain the process and its mandate, but do it quickly and don’t get drawn into discussion about it (simply offer to send material later).
Mention that you’ll take notes and will send them to the interviewee later for review (this creates the opportunity to ask those follow-up questions). Note that you send the notes for review and validation (as factually correct) but not for approval, since you do not want anyone creating barriers to the use of this material.
Introduce each topic before diving in with questions (e.g., “I’d like to understand more about ...”, “I’d like to switch topics to ...”).
Write down the reply carefully. If this creates a short silence, then tell the interviewee what you are writing, as a means of validation.

Capture the discussion material

rows

Interviewee: With the actual name in column B.
Position: With the interviewee’s actual job title in column B.
Business unit: With the actual business unit / department / group / team name in column B.
Date: With the actual date of the meeting in column B.
Purpose: With the primary topic of the meeting in column B.
Role: A short description of what the interviewee does, captured from the introductions at start of the meeting.
Business Activities: There is a row in the template for each of the value-chain functions you previously listed in your worksheet titled Catalog Business Processes. Remember that your interview scripts also map to these same value-chain functions, so there is one row for each of the interview scripts.
Even when you clone this template, to use it to document a specific meeting, do not delete the rows that seem irrelevant. Simply leave them as empty placeholders. Enter your notes into column B of the rows that relate to the interview script.

Validate and extend the notes

Analyse the discussion material

everything you need to know about Managing Orders and Sales, including who to ask about what ...

Now that you know how to plan and conduct interviews, click here for some ideas on how to plan and develop a full understanding of the baseline architecture . . .

Blogger:

Understanding the drivers of change on a company

2007-09-23T12:56:00.001-07:00

Objective: To gain an understanding of the drivers for change that are acting on a company and the marketplace it is operating within, so that the Enterprise Architect (using TOGAF) can understand why existing solutions are coming under pressure and which solutions may be successful in the future.

Tool: Five-Forces analysis

Topic: Business Architecture (TOGAF phase B)

When an Enterprise Architect is asked to develop or change an IT strategy for a company, something important has changed. Organizations do not embark upon such an expensive, and potentially high-impact, process unless compelled by some event, and it’s important that you, as the Enterprise Architect, find out what that change is.

It is not enough to assume that it’s a matter of timing or personality (e.g., “the company just hired a new CIO and she wants an architecture”) because they may just be symptoms. You need to seek the actual cause and that will be, or should be, an event that has made an impact on the business itself or that the senior leaders anticipate may happen. In fact, if you find that it isn’t, and it’s just the whim of a senior leader with a bit of spare cash, then you start at a disadvantage, because no one else will care about your work or support your proposals.

Michael Porter developed a useful tool, known as the Five Forces model, for understanding the pressures acting upon a business and, more important, what has changed. I use it all the time and thoroughly recommend it.

Essentially, the model analyses the forces acting upon a company within the context of its industry. The aim is to understand the drivers of each force and their respective strength. A change to either may be driver that has caused the need for Enterprise Architecture work.

Porter segments the various forces into five categories: competition, product substitution, the power of suppliers, the power of customers, and new entrants to the market.

To understand the model, think of a cake. The cake represents all the money that can be made in an industry or market segment (e.g., PC sales). You are developing an Enterprise Architecture for one of the businesses that sells products or services to earn a slice of that cake, and their business strategy aims to get a bigger slice every year. However, there are five forces preventing the company get all of the cake:

The extent and nature of competitive rivalry: Businesses change their prices, introduce new products or start to promote their products differently, in an effort to take a larger slice of the cake.
The threat of substitutes: There are other products or services that might prove to be more attractive and which drain away some of the money to be made in a market segment, thereby reducing the overall size of the cake.
The ease of entry to the industry: Newcomers see a chance to take a slice of the cake by using skills or products they have developed in a similar market segment. Unless they bring something new to the market that increases the overall size of the cake, then one or more of the existing players has to suffer.
The power of buyers: The value of the cake comes from the customers who buy the products or services being created and those customers will constantly seek to change the balance of power (meaning the price per unit they pay) in their favour. Common techniques that buyers employ include purchasing in larger volumes, playing suppliers off against each other, and building the product themselves.
The power of suppliers: The products that are manufactured, and the services that are delivered, earn the money represented by the cake. These product and services rely, in turn, upon other raw materials or services that are provided by suppliers. These suppliers can exert pressure on a company by increasing prices or reducing product quality.

So, how does this model help you as the Enterprise Architect?

First, when you interview the senior leaders of the organization, to gain an understanding of the business, your questions should cover these five forces. Talk to the marketing director about changes in customer habits (i.e., the demand side) and the effect that product promotions are having on the marketplace. Talk to the procurement director about equivalent changes in the supply chain. Talk to sales about innovations they see arriving in the marketplace and new competitors that have entered. Most important, ask them what has changed and what they think your enterprise architecture can do about it.

To learn about a technique I use to fully understand a business, please click here.

Second, once you’ve discovered what has changed, before you dive in and announce what IT should do to help the company respond to the change, take a step back for a moment. Envision what kind of organization would thrive and survive best in these new circumstances. Companies die from a thousand cuts, constantly making minor adjustments in response to market conditions without understanding the new marketplace. It may be time to do things entirely differently. Enterprise Architects have to envision the best solution as well as the minimum solution. The business case for each must calculate the switching costs (from the current state to the future state) and weigh them against the benefit. This is where you discover how important it is, that other people care about your work and support your proposals, because you’ll need their help when developing the business cases.

Finally, understand that, as Enterprise Architect, you are responsible for:

Creating economies of scale which provide a cost advantage to the business that it can use to tease ‘share of cake’ away from competitors.
Raising barriers to entry that make it harder for rivals and potential competitors from entering the marketplace. Technology can produce excellent barriers to entry, whether it be the best-in-industry web site, world-class customer relationship management or a patented widget.
Introducing innovation that can differentiate products and services, creating a price advantage to the business. So, researching and embracing new technologies is an important part of the role.
Making decisions that improve the organization’s status with respect to the five forces. A typical mistake that IT departments make is allowing themselves to be drawn into using technologies that are only available from one company. The power of suppliers is clearly greatest where there is no substitute product or service available, or where a product becomes essential to the company. Only technologies that can be purchased from multiple suppliers should be considered, except those that help the company differentiate itself in the marketplace. By the way, this rule explains (and justifies) the rise of open standards, since openness fundamentally alters the balance of the five forces to a position more favourable to the buyers of IT services at the expense of the suppliers.

Blogger:

Understanding how a company creates value and competitive advantage

2007-09-22T09:20:00.000-07:00

Objective: To gain an understanding of how a company creates value and competitive advantage, so that the solutions defined by the Enterprise Architect (using TOGAF) achieve the most benefit for the organization.

Tool: Value-chain analysis

Topic: Business Architecture (TOGAF phase B)

The term Value Chain was coined by Michael Porter in his book "Competitive Advantage: Creating and Sustaining Superior Performance" (1985).

The purpose of any business is to create value for its customers at a level that is greater than the cost to produce that value. Michael Porter described this process of value creation as a chain, implying that value is not all created at one point, but is increased continuously along a series of inter-connected business processes or activities, known as value-chain functions. By collaborating, these functions create the products and services that deliver value into the marketplace and (hopefully) create a competitive advantage for the company.

Porter identified five (generic) primary activities that would be found in most types of company: inbound logistics, operations, outbound logistics, marketing/sales, and service. He also identified four secondary activities: procurement, technology development, HR and infrastructure services. This generic value-chain is useful but identifying, characterizing and understanding the value-chain functions and the process by which your organization creates value is one of the first things you, as the Enterprise Architect, must do ... and here's why ...

Some value-chain functions will be considered core competencies whereas some will simply support other business activities. Core competencies are the primary business activities that generate value for the company. They may or may not be the activities that product products and services. Enterprise Architects must make a strategic decision on the solution for each value-chain function. A decision to invest in a new solution for one business activity may be balanced by outsourcing or divestment of another business activity. Any roadmap of development or deployment should give a high priority to core competencies.

No modern business is an island. Value-chains are now inter-connected across divisions, subsidiaries, companies and even international borders. In fact, Porter described collaborating value-chains as a value system. These collaborative connections are crucial to the success of the overall value-chain and represent flows of information, goods and services, as well as systems and processes for adjusting activities. Enterprise Architects must make decisions over these connections or interfaces along the value-chain, the technologies they will use, the security they require and the information that must be exchanged to make the value-chain efficient.

Value-chain functions may also be shifted up or down in the value-chain, but may never be deleted. For example, in a value-chain comprising functions A – B – C – D, if B decided to work directly with D, then the result is simply A – Bc – D rather than A – B - D. C has been disintermediated from the value chain but that business activity must still be performed somewhere, although it may now be achieved in an entirely different way. Enterprise Architects must make a strategic decision over the changes they make to the value-chain. New technology and new business processes can have a significant impact on the value chain, potentially creating a far more effective business ... or chaos.

Companies that do not want to become victims of disintermediation must give themselves a comparative advantage over competitors; whether by being the lowest cost provider of that product or service, or by delivering something else considered important or valuable to its customers (e.g., superior service, an innovative process, a patented technology). New solutions must, therefore, raise barriers to entry against competitors and against potential disintermediation. To achieve this, Enterprise Architects must understand what comparative advantage they delivering with their solutions.

To learn about a technique I use to understand the influences, and the drivers of change, on a company, please click here.

Blogger:

Creating a Business Architecture using TOGAF

2007-09-22T02:30:00.000-07:00

Topic: BUSINESS ARCHITECTURE (TOGAF Phase B)

The activities of TOGAF Phase B include documenting, discussing and understanding the business architecture of the organization, whether your scope is the complete enterprise or some subset of it.

The purpose and the benefit is to ensure that you can link your solution back to the things that are important to the business, at that point in time.

Although Business Architecture is positioned as Phase B in TOGAF, after the preliminary work and the specification of the architecture vision, the TOGAF documentation mentions, quite rightly, that an understanding of a company’s Business Architecture is a prerequisite for any architecture work and is therefore the first architecture activity that must be completed.

It is certainly where I start, having learned that any project which cannot be clearly and directly linked back to business needs and objectives, fails to galvanize the enduring commitment it needs to succeed.

There will be two primary tracks of work in your plan for this phase. The first will studiously capture and discuss the “baseline” (“as-is” or “current state”) business architecture. The second will capture and challenge the “target” (“to-be” or “future-state”) business architecture.

I will be adding various blog postings to discuss tools and techniques that can make the development of a Business Architecture productive and, surprisingly, more enjoyable.

I would be interested in hearing about any of your tricks of the trade!

Related Postings:

Understanding how a company creates value and competitive advantage.

Understanding the drivers of change acting on a company.

How to get the most out of Enterprise Architecture interviews.

How to develop a complete understanding of an organization's baseline architecture.

Blogger: