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. Let’s look at this in more detail by way of mapping the activities between BABOK v2* and the TOGAF 9 Framework*.

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:

The diagram below is a draft mapping between BABOK® and TOGAF 9, more work is required on this.

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.

http://www.theiiba.org/am/

Business Architects are supposed to manage Business Architecture, but who are they, what are their skills? How are they different to a Business Analyst or even a Project Manager?

Business Analysts are on the way to becoming Business Architects. Sometimes called IT Business Analysts, they are not strictly business or IT specialists. They write business cases (with very few technical terms), identify business requirements and often are part of a Development Team.

Based on many job descriptions and my observation below, is a grid of standard skills and responsibilities related to the function of a Business Analyst. In the second column, are the responsibilities also applicable to a Business Architect and in the last column comments on how TOGAF 9 recommend the activities to be addressed.

Expected skills and activities	Business Analyst	Business Architect	Comments related to TOGAF 9
Is an intermediary between IT and the business users, follows the implementation strategy with respect to getting stakeholder buy-in and support.	x	x	Both roles require to be positioned between IT and business.
In particular business processes of a line of business.	x		The Business Architect considers the organization’s strategy and less focused in a specific line of business.
Acts as catalyst to implement strategic and tactical change for the business.	x	x	The Business Architect will focus more on strategic changes.
Works with end-user groups to assist with aligning IT to the department's business goals. Conduct feasibility studies to define the purpose, functions, and overall structure of business processes	x	x	The Business Architect in TOGAF 9 will use Business Scenario techniques.
May be involved in Business Process Management (BPM).	x	x
Performs analysis and documents business processes leading to process change and/or system implementation.	x	x	The Business Architect will model and process the business processes.
Operating as a more-or-less independent group that is focused on delivering BPM services	x		The Business Architect will be working at a strategic level and will be less focused on the delivery of BPM services.
Does not have an IT background, but had, instead, a background in quality control.		x	The Business Architect must have a perfect knowledge of the business.
Translates user requirements into software requirements that IT can then use to develop software	x		A Business Architect would not develop and review design specifications for software application. This would be the role of the Application Architect during Phase C.
Analyze and resolve software errors in a timely and accurate fashion	x		A Business Architect is not in charge of managing incidents linked to applications. IT operations may escalate this to the Development Team, or the vendor. Once a first level of diagnostic done, it will be transferred to one of the architects depending on the domain (technology, application).
Helps to develop and maintain software to support the business processes. Assist in developing system/application architecture.	x		The Business Architect does not contribute to software development. This is done by the Solution Architect.
Leads and validates enterprise system designs across multiple business applications.	x		The Business Architect does not lead Application Architecture. This will be done by the Application Architect and potentially the Solution Architect.
Creates and executes test plans to ensure that the functional and business requirements are met by the proposed solution	x		The Business Architect does not contribute to test plans. This is done probably by the Solution Architect.
Documents and defines processes, eliminating activities that don't add value and straightening out the flow of the activities.	x	x	In the TOGAF 9 Phase B we would do this by documenting the baseline and target architecture and do a gap analysis, identifying the various business architecture building blocks to be eliminated.
Determining how business policies are implemented in business rules.	x	x	Business rules have to be identified and implemented when business processes documented in both baseline and target architecture. Can be done at both strategic and tactical level.
Analyses customer needs and the processes customers go through to interact with an organization are key skills that any business process practitioner needs to be effective.	x	x	Business scenarios would be used to identify business requirements.
Creates, manages and maintains an optimum business architecture that includes informational, organizational, process, performance and systems architecture.		x	The Business Analyst focus more on projects delivery. The Business Architect is mostly focused on the delivery of the Business Architecture.
Defines, socializes and implements Business Architecture. Reviews roadmap projects for impact and compliance.		x	Business Architecture roadmaps will be delivered from the gap analysis.
Identifies and facilitates cross divisional continuous business improvement initiatives.		x	The Business Architect works at a strategic level and focus mostly on Strategic Architecture.
Member of the Architecture Board, composed of representative process owners who approve any cross organizational business process changes.	x		Business Architects should be part of the Architecture Board.
Identifies and maintains an up to date picture of opportunities and risks.	x	x	Risks have to be identified during both the Architecture vision phase and the development of the solution.
Experienced in business/process architecture including broad skills in the area of strategy mapping, business analysis skills, conceptual data and process modeling/design, EA frameworks.		x	The Business Architect must have these skills. The Business Analyst may focus on process modeling only.
Strong work experience in Project and Change management.	x	x	Both roles require these skills.
Proven track record for working effectively with technical and business functions.		x	The Business Architect must work with other domain's architects.

My observations are:

Business Analysts are much closer to IT. They often are assigned to a specific Line of Business, which is close to the Development Team, and are implicated in software development. They may be part of the Development Team or the Project Management Office. The Business Architect reports to managers or senior managers who may be business or IT but are independent of any project. They have a global view on most business and will be responsible for modeling the business as a whole, then working top down to "architect" encompassing end to end business processes. Their role is more horizontal and is considered a neutral voice and because of that will make more critical decisions than a Business Analyst.

Business Analysts document requirements as defined by users during workshops. A Business Architect documents and may contribute to define a business strategy using requirements provided by the users if that strategy is not finalized. The Business Architect must have the ability to think in both a strategic and tactical manner whereas a Business Analyst is normally tactical.

The Business Analyst operates within the confines of a predetermined application and technology architecture. A Business Architect is a part of the decision making process to define the IT architecture (Data, Application and Technology). He will have a strong influence directing information technology to meet business needs, and assist in identifying business inefficiencies and opportunities.

Business Architect must be cognizant of enterprise strategies whereas a Business Analyst is normally concerned with specific projects independent of enterprise strategy.

The objective of that phase is to formulate recommendations for each implementation project, and govern and manage an architecture contract covering the overall system implementation and deployment. In companies where the maturity is high, it would be perfectly acceptable to have the Solution Architect acting in the name of the Enterprise Architecture team and coordinate activities during the phase G.

TOGAF defines objectives during that phase and each of them may be detailed as follows.

• To formulate recommendations for each implementation project (Source: TOGAF 9)

The Solution Architect with the Enterprise Architecture team and the Development Team:

• Participates in assessment of solutions needs consistent with the global business strategies
• Re-analyzes business practices.
• Provides business analysis and documents process design of system functions and processes as identified in the phase B.
• Recommends application design within the development team. Supervises and ensures quality delivery of the analysis, design, and build of the hardware, network, and common software platform components of software releases with the development team.
• Assesses identified technologies from the phase D, and makes sure that solution options are based on the target architecture. Note: He will be directly accountable for the acceptance of technology architecture deliverables by the client.
• Participates in the planning, development, maintenance, installation, configuration, documentation, training and implementation of new applications/solutions. He is accountable for the documenting requirements (hardware, network, and configuration) captured during the previous ADM phases. He may also develop the engineering documentation.
• Participates in the development of functional specifications for developers related to modifying functionality, report development, outputs and interfaces.
• Works with internal customers, external consultants, IT staff and other stakeholders to refine requirements when needed.
• Leads and participates in developing and facilitating end user workshops for the solution.
• Supports existing applications within the company’s active portfolio and extends their use where appropriate according to the gap analysis.
• Coordinates and/or participates in the planning and execution of application testing.
• To govern and manage an Architecture Contract covering the overall implementation and deployment process (Source: TOGAF 9)

He identifies if there are any issues between the architecture and the implementation organization.

• To perform appropriate governance functions while the solution is being implemented and deployed (Source: TOGAF 9)

He will refer to existing governance best practices such as IT Service Management, Project Management, Risk Management, Security Management, and Audit management (for example).

• To ensure conformance with the defined architecture by implementation projects and other projects (Source: TOGAF 9)

He will Review ongoing implementation governance and architecture compliance for each building block.

• To ensure that the program of solutions is deployed successfully, as a planned program of work (Source: TOGAF 9)

He will Review ongoing implementation governance and architecture compliance for each building block.

• To ensure conformance of the deployed solution with the Target Architecture (Source: TOGAF 9)

He will support the architecture design review using a customized checklist as defined in TOGAF.

• To mobilize supporting operations that will underpin the future working lifetime of the deployed solution (Source: TOGAF 9)

The Solution Architect with the Enterprise Architecture team and the IT Operation Team:

• Helps to monitor and supports the operations architecture of for hardware, network, and common software platforms (including configuration approach, deployment, approach, and monitoring approach).
• Supports all hardware, network, and common software platforms in Development, Production, and Operations environments. Must be aware of the status of the system in all environments, and must communicate and manage environment related risks and activities.
• Supports build team by managing configuration of hardware, network, and common software platforms (like Application Servers).
• Establishes and maintains relationship with key clients with-in client IT organization
• Develops and implements plan for increasing level of technical architecture skill in program staff.
• Ensures consistent implementation of technical components across release activities with the IT Service Management team if it exists (e.g. release manager).
• Identifies production infrastructure related issues in the production environment with the help of both the Service Desk and the System Management team if they exist. Creates and implements issue resolution plans that have to be escalated to the Enterprise Architecture team.

This diagram is a high level representation of the Solution Architect’s activities interacting with all parties involved in the architecture development and delivery.

This approach where many activities are led by a designated Solution Architect. The alternative being to share the role between several architects from the Enterprise Architecture team.

Companies such as Oracle, Cisco, SAP and others have roles called Solution Architect but with little apparent agreement to what that role is.

Some commonalities between various skills are:

• Strategic business acumen (understand business requirements and strategy)
• Technical analysis
• Broad and deep technical knowledge
• Technical leadership (the trusted, technical advisor for assigned line of business, providing thought leadership and application of technology to business problems)
• Data Architect
• Shapes the evolution of company’s products
• Maps product requirements and business problems to re-usable end-to-end technology solutions
• Uses methodologies and frameworks (using best practices and common patterns, including database, component layers, user interfaces, web services, and integration patterns)
• Builds and deploys new functionality and extend applications (driving the development of those solutions by guiding and mentoring the development team through the entire development process. Some development will be required for shared services and components or technically challenging areas where the skills of an architect are needed)
• Software architect (must understand and contribute to all levels of design needed for the solution (business, data, application, technology))
• Deep experience developing enterprise solutions using all aspects of the .NET platform, open source or Java (or any other environment), Web Services, multithreaded programming, designing and building frameworks, enterprise patterns, SQL design and development, and database tuning
• Coder (build and code prototypes and frameworks)
• Hands-on experience
• Performance and load testing, development tools
• Works with major lines of business and IT Development teams
• Is a member of the Enterprise Architecture team
• Documents solution designs and how they interact with the larger Enterprise Architecture

Now looking at TOGAF, we need to consider a few definitions such as the Architecture Building Blocks (ABBs) and the Solutions Building Blocks (SBBs).

Building Block – A (potentially re-usable) component of business, IT or architectural capability

• Architecture Building Block (ABB)
• A constituent of the architecture model that describes a single aspect of the overall model
• Describe required capability
• Shape the specification of SBBs
• Solutions Building Block (SBB)
• Represents components that will be used to implement the required capability
• A candidate physical solution for an Architecture Building Block (ABB); e.g., a Commercial Off-The-Shelf (COTS) package that is a component of the Acquirer view of the architecture

All ABBs will be stored in the Architecture Landscape of the Architecture Repository. These ABBs will have different levels of granularity to suit different architectural objectives.

The Architecture Definition Document which describes an architecture will contain all artifacts describing as views the building blocks.

During the Phase E, Opportunities and Solutions, we identify work packages and group them into projects, consolidate the gap analysis results from phases B to D, identify the building blocks to be developed or acquired reusing the existing ones (stored in the Architecture Repository) as much as we can. From there, we identify the SBBs which could potentially address one or more gaps and their associated ABBs. Existing SBBs have obviously also to be considered taking the interoperability requirements and dependencies into consideration.

The Solution Architect has a key role in this phase as (s)he will probably be the best qualified to identify the appropriate SBBs. He or she participates in the definition of any Transition Architectures, identifies potential solutions, and helps to formulate a high-level implementation and migration strategy.

During the Migration Planning phase they also have an important mission to ensure that SBBs are properly designed or that acquired solutions support business requirements. The Solution Architect may work closely with the vendor if a COTS solution is considered. A solution includes the hardware, software, and supporting people and documentation to solve a problem.

"The gaps in the existing enterprise solutions framework need to be identified and the specific Solution Building Blocks (SBBs) required to fill these gaps will be the identified by the solutions architects. These SBBs may have a one-to-one or many-to-one relationship with the projects. The solutions architects need to define exactly how this will be done. There may be other projects working on these same capabilities and the solutions architects need to ensure that they can leverage best value from these investments."

When the Implementation Governance phase is started, the Solution Architect will work in partnership with the procurer/acquirer in addition to the development team and/or the vendor. He will ensure that the development will comply with the target architecture.

When the solution building blocks are developed or integrated with other existing solutions, the Solution Architect will be working with the development team. His role will be to contribute to the design, development, integration and testing of the new components. This may be considered as being the Solution Architecture activity.

A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high level business and/or IT system specifications and a portfolio of implementation tasks.

Solution architecture starts with an understanding of the problem, which should be documented in the business scenario, and this is where so many projects fail. Too many people have the idea that solving a problem is all about coding.

The Solution Architect is a member of the Enterprise Architecture team but becomes at a later stage also a member of the Development team. His role is mixed; he is the bridge between concepts and implementation. However, the Solution Architect does not operate at the Strategic Architecture level (at the level of the Enterprise) but mostly at Segment and Capability Architecture levels.

"The Solution Architect has the responsibility for architectural design and documentation at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the Solution Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing."

There is no mapping for a Solution Architect in the TOGAF Skills Framework, but I would suggest, based on my experience, the following proficiency levels:

TOGAF proficiency levels:

This approach is related to the current situation in the market for Solutions Architects, where we see that most of their activities are limited to phases E to G. Another approach would be to consider a Solution Architect being involved in all phases of the TOGAF ADM from phase A and on-wards. A follow-up paper will describe how to address solutions from Phase A , when constraints exist, defining the role and responsibilities of a Solution Architect.

Service Design has five aspects:

• Design of the service solutions
• Design of the Service Portfolio (and other supporting systems)
• Design of the technology architectures and management systems
• Design of the processes
• Design of the measurement systems, methods and metrics

Section 3.6.3 on page 35, provides a specific context for the terms "architecture" and "system" which is well aligned with ISO/IEC 42010:2007 definition used by TOGAF 9.

"Architecture" is defined as:

"The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution."

"System" in this definition is used in the most general, not necessarily IT, sense:

"A collection of components organized to accomplish a specific function or set of functions."

"architectural design" as:

"The development and maintenance of IT policies, strategies, architectures, designs, documents, plans and processes for the deployment and subsequent operation and improvement of appropriate IT services and solutions throughout an organization."

In ITIL V3, IT policies and strategies are defined by senior management during the Service Strategy phase of the service lifecycle. These policies may be also be reused during the Preliminary Phase of TOGAF 9. The Preliminary Phase allows us to establish the business context, customize TOGAF, define architecture principles, and establish the governance structure. Architectural Principles are general rules and guidelines that support the way in which an organization sets about fulfilling its mission. These principles should be the source for the creation of IT policies.

Service Architects and Designers will need to consider several resources such as (budgets, infrastructures, applications, information, and people) and capabilities (management, organization, processes, knowledge, and people) of the organization defined by TOGAF 9. This will have to be coordinated with the business requirements which may have been collected from a Business Scenario (TOGAF). Using inputs from the business and Service Strategy in ITIL V3, the design needs to take into consideration, people, processes, products, and partners. Also designers will have to take into consideration, the vision, mission, goals, and objectives in order to translate them into critical success factors, key performance indicators, metrics and measurements.

Documents in ITIL V3 may be considered as being artifacts in TOGAF 9. Artifacts consist of plans, contracts (Architecture contracts or other forms of contracts), job descriptions, organizational structures, process workflows, procedures, instructions, configuration, diagrams, catalogs, lists, and databases among many other document types.

One of the major difficulties for the designer will be to sort through this documentation and remove that which is obsolete, duplicated, incomplete, or erroneous. TOGAF with its Architecture repository may also help to store documents related to IT Service Management. You may also think of combining a CMDB with an Architecture Repository…but that would be another topic to discuss.

Although plans should be considered as documents, it is important to identify and sift through the myriads of plans that are in use in the organization. Plans may be produced by different lines of business including IT, issued by business planning committees, PMO, etc. Some of the difficulties will include gathering them (business plans, IT plans, operational plans, contingency plans, financial plans, etc.), making sense of them and more importantly, making sure they are aligned. For these reasons, the TOGAF Migration Planning phase helps to coordinate different business areas and create a common plan.

The term architecture within ITIL V3 may be aligned with the 4 architecture domains from TOGAF:

• Business Architecture: for Business, organization and enterprise
• Data Architecture: for data and information, databases
• Application Architecture: for applications
• Technology Architecture: for hardware (desktops, mobile devices, servers, and mainframes), network, telephony and software

Some aspects may not be covered by architecture domains such the Environment (heat, ventilation, AC, etc.), or the physical workspace including safety (this would be covered by Security Architecture considered during the ADM phases).

Services would be a combination of the four domains.

The Service Design activities and processes covers:

• Service Level Management
• Availability Management
• IT Service Continuity Management
• Supplier Management
• Information Security Management
• Capacity Management
• Service Catalogue Management

These processes can be designed when building the Technology Architecture with the Technical Reference Model (TRM).

Page 37 of the Service Design book refers to many documented practices available for designing, deploying, and operating service architecture. It lists Enterprise Architecture frameworks, one of them being TOGAF!

As an example, PMI has introduced a standard for Portfolio Management, and portfolio managers have a resource to help them develop professionally and achieve success for themselves and their enterprise. Within an organization, a portfolio represents a collection of active programs, projects and other work undertaken at a specific point in time to help the organization achieve strategic objectives. In essence, a portfolio reflects the priorities, investments and resource allocations.

Project Portfolio Management (PPM) may be part of an enterprise governance framework. It is a management process designed to help the organization‐:

• To ensure that the organization is doing the "right things", optimally allocating scarce resources toward the enterprise’s objectives
• To acquire and view information about all projects
• To sort and prioritize each project according to certain criteria, such as strategic value, resource impact, cost, and so on.

PPM has several activities which are similar to the objectives of managing a financial portfolio:

• The identification of all the individual demands in the portfolio
• The development of a "big picture" view and a deeper understanding of the collection as a whole
• The sensible sorting, adding, and removing of items from the collection based on their costs, benefits, and alignment with long term strategies or goals.

In a nutshell, Portfolio Management can help zero in on the projects that are most worth their effort; project management can help execute those projects most efficiently.

These activities can be perfectly integrated with Phase H of TOGAF. Once the work packages, projects and building blocks inventory is created, the enterprise architecture team with the portfolio managers (and other important stakeholders) will examine each project and prioritize it according to established criteria. They will probably assign a business value; conduct a cost business analysis for each project (done in collaboration with business people); identify the risks to the projects.

The overall list of projects is then considered to develop a well‐balanced list of supported projects and provide an input for a detailed implementation and migration plan. It will also help to confirm the Transition Architecture defined in the phase E. The use of an Architecture definition increments table is highly recommended to list these projects.

Some projects will be given high priority and extensive support, some will be given moderate priority, and still others will be placed on hold or dropped entirely from the list. This will also help to finalize the Architecture roadmap. Finally, resources will need to be identified and made available.

Other Governance domains may also be to be integrated in the PPM process and Phase H, such as Risk Management (e.g. RiskIT), Project Management (e.g. PMI, PRINCE 2), etc.

Companies who are mature in Portfolio Management activities may integrate their existing work practices easily with TOGAF. This would enforce the relationship between the Enterprise Architecture team and the PMO (or the PPM team).

TOGAF provides a methodology for analyzing your specific situation and turning that analysis into deliverables and actionable artifacts. Artifacts may have different shapes as defined in TOGAF 9. They may be: Catalogs, matrices or diagrams. EA artifacts may also help to define a standard set of document types such as education, strategy, decision, policy, standard, guideline, etc. It is also recommended that you set up a simple online discussion thread or wiki for each artifact to solicit feedback from artifact consumers.

Enterprise Architects should ensure that their efforts to create architecture documentation produce meaningful results by creating artifacts that connect with the consumer, drive decisions, and will allow the development of reusable building blocks.

If we consider the various architecture domains, they may have different forms.

As examples-

in Business Architecture, they could be the views of the Business stakeholders. The matrices between business strategy and the main business functions. The diagrams showing the relationship between processes and information. The Value Chains. Business and Operating models of the Enterprise. Customizing the configuration of the Business Functions according to model --- and more.

The artifacts for data or Information architecture may refer to an information map or diagram. It could also show the mapping between data items and the Business Information map. Artifacts for Application Architecture, could show the key interconnections between applications, middleware connection matrices. There may also exists views for Portal Architecture, Enterprise Content Management, Identity management, Business Intelligence, ERPs and CRMs. Last but not least, Technology Architecture artifacts may propose servers and storage technology diagrams, office views (file, printing, data base servers, etc...), LAN/WAN/Voice Network architecture diagrams, applications and interconnections mapping to technology servers and networks, infrastructure security diagrams. In addition to that, there may be a certain numbers of artifacts related to the company’s organization, organization chart, lines of business mapping to business functions, organization roles in organization units and job descriptions.

Many graphical tools may aid to develop diagrams or document matrices but may also be quite costly. The use of spreadsheet may be a first step in building artifacts such as matrices. The following examples illustrate how they may simply be build with Excel.

List of Metadata

Data-Business process matrix

Application Inventory List

These are very basic example of what artifacts may look like. They may rapidly be created and are definitely a way to explain to the EA stakeholders how the first deliverables of our baseline architecture looks like.

Capabilities are in fact the building blocks of business. A business capability typically defines what a business unit‘s purpose is (goals and objectives), its core competencies, and is therefore directly bound to business objectives and strategy. Capabilities provide a black-box view of those things the business can do, i.e. working on business artifacts (e.g. Business Processes, Catalogs).

The business processes and resources involved in providing the capabilities are not exposed (business service orientation). Capabilities aren‘t isolated but form hierarchical value-networks with relationships that materialize the business processes. At a lower level, capabilities are modeled using traditional activity diagrams used for the design and implementation of IT solutions.

The key elements of capabilities-based planning are a conceptual framework, an analytical framework and a building block approach to applying the frameworks.

• A conceptual framework allows for business planning under uncertainty by emphasizing flexibility, robustness and adaptive capability
• The analytical framework provides a way to assess business capability options at the operational level and choose among capability alternatives
• A building block approach allows us to define, develop and test individual capabilities within their own business domains

Capabilities them can be developed and evaluated within smaller architecture domains from phase B to phase D, and then later combined to describe joint forces capabilities in Transition Architectures identified in phases E-F.

Capability Based Planning also revolves around the establishment of the capacity and ability to execute a designated set of generic tasks, bringing enormous help when entering the Opportunities & Solutions and Migration Planning phases. It is an effective way of selling the value of Enterprise Architecture to the business, without being too much theoretical...

TOGAF 9 introduces significant enhancements to the previous version of the standard and represents a departure for enterprise architecture frameworks in general. It’s larger, more mature, and modular to allow people to enter it from a variety of perspectives. It takes on a much more significant business services and accomplishments perspective. TOGAF 9 includes new material, describes more topics, like capability-based planning, security architecture and SOA. The new Architecture Content Framework includes a detailed content meta-model that formalizes the definition of an enterprise architecture (EA) and also establishes clear links between business and IT objects. It also show in detail how the Architecture Development Method (ADM ) is considering other It governance domains such as Risk management, Operations management, Project and Portfolio management. In general more attention is given to business issues and business alignment.

TOGAF 9 is an evolution of TOGAF 8 and has been designed for greater usability. It is more focused on holistic enterprise change and provides more consistency of outputs. In all areas, the specification adds detail and clarity above and beyond previous TOGAF versions.

What’s new in TOGAF 9?

Modular Structure

TOGAF allows for the concepts in each part to be developed with limited impacts on other parts. The modular structure in TOGAF is intended to support greater usability, as each part has a defined purpose and can be read in isolation as a stand-alone set of guidelines.

Content Framework

This is a significant addition to TOGAF. The TOGAF content framework provides a detailed model of architectural work products, including deliverables, artifacts within deliverables, and the architectural building blocks that artifacts represent.

• It provides a comprehensive checklist of architecture outputs
• It promotes better integration of work products if adopted across an enterprise
• It provides a detailed open standard for how architectures should be described

Extended Guidance on Adopting TOGAF within an Enterprise

This version of TOGAF features an extended set of concepts and guidelines to support the establishment of an integrated hierarchy of architectures being developed by teams that operate within an overarching architectural governance model. In particular, the following concepts are introduced:

Partitioning

• This abstracts away from the specific rows and columns of the Zachman matrix, while retaining the underlying principle of articulating different architectural views and domains in a systematic manner.

Architecture Repository

• The Architecture Repository is a logical information store for outputs of executing the ADM:
• The Architecture Metamodel describes the architecture framework in use within the Enterprise
• The Architecture Landscape shows the state of the operating Enterprise at particular points in time
• The Reference Library contains re-usable architecture work products
• The Standards Information Base defines the compliance criteria for work governed by architecture
• The Governance Log captures results of governance activity, such as compliance assessments
• The Architecture Capability describes the organisation, roles, skills and responsibilities of the Enterprise Architecture practice
• The Architecture Repository is a logical information store for outputs of executing the ADM:
• The Architecture Metamodel describes the architecture framework in use within the Enterprise
• The Architecture Landscape shows the state of the operating Enterprise at particular points in time
• The Reference Library contains re-usable architecture work products
• The Standards Information Base defines the compliance criteria for work governed by architecture
• The Governance Log captures results of governance activity, such as compliance assessments
• The Architecture Capability describes the organisation, roles, skills and responsibilities of the Enterprise Architecture practice

Capability Framework

• It is intended to provide better guidance in the area of skills, organization, roles and responsibilities of architects, and a process for defining an appropriate architecture capability for any organization.

Content metamodel

• The new Architecture Content Framework includes a detailed content meta-model that formalizes the definition of an enterprise architecture (EA) and also establishes clear links between business and IT objects.

Capability Framework

• Following the lead taken by the architectural frameworks of the defence world (DoDAF and MODAF), but applying a high-level concept of business capability to the civilian world. For example, the TOGAF guide points to the relevance of concept for governments in planning horizontal interoperability and shared services
• It is a structured definition of the organizations, skills, roles and responsibilities to establish and operate an Enterprise Architecture, including:
• Terms of Reference for an Architecture Board
• Guidance on measuring levels of Architecture Compliance against Architecture contracts
• Processes and organization structures required to operate Architecture Governance
• Techniques for assessing Architecture Maturity
• An overview of the Skills required by practicing architects

Explicit Consideration of Architectural Style

• The new Part III: ADM Guidelines & Techniques brings together a set of supporting materials that show in more detail how the ADM can be applied to specific situations.
• Applying Iteration to the ADM
• Applying the ADM at different Enterprise Levels
• Security Architecture and the ADM
• Using TOGAF to define and govern SOA

Additional ADM Detail

• This version of the TOGAF specification includes more detailed information supporting the execution of the ADM.
• The Preliminary phase, which features extended guidance on establishing an enterprise architecture framework and planning for architecture development.
• The Opportunities & Solutions phase and Migration Planning phase, which feature a more detailed and robust method for defining and planning enterprise transformation, based on the principles of capability-based planning.

Summary

• TOGAF 9
• Builds a rich foundation for business execution
• Enables business solutions from solidly defined architectural capabilities
• Unites the business objectives with the IT capabilities, creating a platform for significant added value.

Detailed information on TOGAF 9 including downloads of the specification, links to white papers, information sheets, reference cards, etc is available at:

• http://www.opengroup.org/togaf/
• http://www.togaf.info
• TOGAF Version 9, "The Book"
• Document No. G091
• ISBN: 978-90-8753-2307
• www.opengroup.org
• www.vanharen.net
• TOGAF Version 9, The Pocket Guide
• Document No. G092
• ISBN: 978-90-8753-232-1
• www.opengroup.org
• www.vanharen.net

The Open Group published the first version of TOGAF in December 1995. Shortly before this the US Government had donated the US DODs TAFIM (an IT Architecture Framework for Information Management) to The Open Group as a possible common standard for IT Architecture. The newly created Architecture Forum within The Open Group developed an IT Architecture Reference Model based on TAFIM and TOGAF was born.

Over the next ten years the Architecture Forum encouraged its members to develop and adapt TOGAF to meet their own organisations IT Architecture methodology requirements. Through this shared best practice, TOGAF evolved from an IT Architecture reference model to a comprehensive framework and methodology for developing Enterprise Architecture.

The Open Group continues to publish TOGAF, now in its eighth release, providing free access to any organization wishing to develop an enterprise architecture see http://www.opengroup.org.

TOGAFs growing popularity

Many organisations, in both the private and public sector, are increasingly turning to TOGAF to help them develop Enterprise and IT Architectures. They are finding that TOGAF helps them produce

• well integrated solution portfolios
• clearly defined interfaces
• reduced complexity
• better managed IT services.

This popularity comes from a number of characteristics.

Comprehensive phased approach	The development of Enterprise and IT Architectures is at the core of TOGAF. A phased approach ensures that managers make good decisions about their business structures and IT.
Complete life-cycle management	TOGAF has the ability to manage the complete architecture lifecycle from the initial introduction and visioning of the conceptual architectures to the full specification, implementation and governance of the completed architectures.
Best practice tool support	TOGAF is supported by a large number of best practice tools and techniques. Customers have a rich infrastructure of instantly available capability to enable them to start using the method and bring it into their organizations quickly
Simplicity and depth	The appeal of TOGAF is its combination of simplicity and depth. For the CIO and CTO TOGAFs refreshing simplicity enables IT to easily engage with the business. However, TOGAF also has the depth to manage complexity and provide sophisticated IT services. This combination allows business and IT to work together to build effective business operations and infrastructures that deliver competitive advantage.

What exactly is TOGAF?

There are three main parts which define TOGAF. These are:

• The Architecture Development Method (ADM) the centrepiece and core of TOGAF providing the process and method to create the component architectures.
• The Enterprise Continuum the set of architectures, building blocks and products which are used to create the organization specific enterprise architectures.
• The Resource Base basic best practice tools and techniques which are used to guide and create the architectures in the Enterprise Continuum.

The ADM

The ADM consists of nine phases Diagram 1 shows their inter-relationship. Each phase defines a set of activities that enable the sponsor and stakeholders to reach decisions on the enterprise architecture.

Business and IT teams work together, phase by phase, to create and manage the enterprise architecture through its life-cycle.

Preliminary phase: Scoping and identifying resources

We start with the Preliminary Phase, which scopes the enterprise and identifies the resources required to create and deliver the enterprise architecture. It is at this stage that the specific people, process, tools and governance are allocated to the enterprise architecture development work.

The enterprise architecture is created from stakeholders requirements, managed throughout the method by the Requirements Management phase.

Setting up the resources, repositories and tools are key activity areas to be addressed in the preliminary stages. Now we are ready to start the enterprise architecture work.

Figure 1

Phase A: Envisioning the future state

The next major step is to create a vision of the future enterprise architecture. We use business scenarios to review the business vision, strategy and drivers. Then we generate a set of business requirements for the future enterprise. From this articulation we create the conceptual enterprise architecture and produce the first-cut drawings and designs. These will allow the business to see what the enterprise will look like in its future state.

During this phase we assess the existing baseline enterprise architecture and capability against the vision. Analysing this, we can then assess the work to be done, timescales and costs.

Phases B, C & D: Developing architecture specifications

Phases B, C & D concentrate on developing the individual architecture specifications that make up the whole enterprise architecture. These phases create different views of the enterprise architecture from each stakeholders area of interest.

• Phase B creates the new enterprises Business Architecture covering the business process, services, function, organisation and strategies.
• Phase C creates the Information Systems Architecture that support the Business Architecture. The Information Systems Architecture is made up of the Data Architecture and Applications Architecture.
• Phase D creates the Technology Architecture that forms the foundation of the target IT infrastructure.

While the main flow of decision making is from B to C to D these are iterative phases that cycle until the final versions of each is achieved and signed off by the sponsor and stakeholders.

Phases E & F: Developing and planning solutions

Phases E and F are concerned with determining the specific solutions architecture and implementation plans to migrate from the current state to the new enterprise architecture. Any procurement and development planning decisions are made at these phases.

Phase G: Managing deployment and realising value

Implementation Governance sits in phase G and provides the architecture governance framework for solutions development and implementation. This phase ensures that the development work remains consistent with the architecture specifications and delivers the requirements of the sponsor and stakeholders.

It is at the end of Phase G that the business starts to realise the business value of the enterprise architecture for their business operations.

Phase H: Managing change

While enterprise architectures can last for many years they must also be refreshed to suit the changing needs of the business. Changes may be needed due to:

• asset management and infrastructure refresh requests
• business process improvements
• re-organizations
• market and business capacity changes
• mergers and acquisitions.

Architecture Change Management, the final phase, allows for such changes throughout both the development and the operational lifecycle of the enterprise architecture.

Now we have completed the ADM and are ready for change!

The Enterprise Continuum what have we delivered?

Using the ADM cycle we have created building blocks of business and IT capability to populate the future enterprise. In TOGAF we refer to this capability conceptually as the Enterprise Continuum.

The Enterprise Continuum consists of all the architectures, standards, reference models and deliverables that make up the enterprise architecture. These are in two parts, as illustrated in the Diagram 2.

The usual way to develop with TOGAF is to start with the basic foundation architectures and build on them until the organization specific enterprise architecture is fully defined. The architectures then guide the selection and development of the products and solutions for the organization specific business operations and infrastructure solutions.

Figure 2

The Resource Base the tools we need to do this work.

TOGAF has a resource base of simple tools and techniques to support the ADM cycles. These range from templates for Principles, Business Scenario tools, skills frameworks, case studies and mappings to other architectures.

However, there are many other tools and techniques available in the marketplace which can support the ADM. In particular, TOGAF certified software tools are available from Proforma, Telelogic and Troux. These assist in the modelling and management of the enterprise architecture products.

Who has benefited from using TOGAF?