Project Charter

for

TOGAF-SABSA integration

Version 1.0

Prepared by Pascal de Koning

Getronics

July7th 2010

Project Charter for TOGAF-SABSA integrationPage 1

Table of Contents

1.Project Description

2.Business Objectives and Success Criteria

3.Stakeholders

3.1.Project sponsor

3.2.Project manager

3.3.The Open Group

3.4.The SABSA Institute

3.5.Working group members

4.Vision

5.Project Scope

6.Assumptions and Dependencies

7.Risks

8.Resources

9.Approval of the deliverables

10.Planning

Revision History

Name / Date / Reason For Changes / Version
Pascal de Koning / June 30th 2010 / Initial version / 0.1
Pascal de Koning / July 7th 2010 / Approved in conference call / 1.0

1.Project Description

The Open Group Architecture Framework (TOGAF) descibes an Architecture Development Method (ADM) that can be used to deliver an Enterprise Architecture. A current development is the integration of security into TOGAF.

A framework for Enterprise Security Architecture is offered by Sherwoods Applied Business-driven Security Architecture (SABSA). SABSA is owned by the SABSA Institute. Both SABSA and TOGAF are business-driven. The thought is that SABSA can fill in the security-aspects within TOGAF. When the link between SABSA and TOGAF is defined, it will be easier to use SABSA for organizations that already use TOGAF.

The aim is:

  • to describe SABSA in TOGAF-words, emphasizing some strong and useful concepts of SABSA. This whitepaper will act as a basis for other artifacts, e.g. flyers, presentations, booklet, etc.
  • to present useful TOGAF principles to security architects. For example, the ADM cycle can be used as a delivery model for a security architecture.

To achieve this, the TOGAF & SABSA Integration workgroup is established as a joint initiative of the Architecture Forum and Security Forum plus representatives from the SABSA Instituteon April 29th2010 in order to write a whitepaper on integrating TOGAF & SABSA.

2.Business Objectives and Success Criteria

The working group will deliver one or more whitepapers, containing the following elements. These elements will be worked out in project streams:

  1. Common glossary for TOGAF and SABSA
  2. Position of SABSA within the TOGAF architecture metamodel
  3. Mapping of SABSA elements to deliverables, artifacts and building blocks
  4. Review list of Security Forum TOGAF gaps and determine what would be closed by SABSA integration with TOGAF
  5. Explore the added value of using the SABSA business attributes concept as a model for TOGAF requirements management. Note: beware that this is going beyond the scope of security.

Critical Success Factors are:

  • Education on both TOGAF and SABSA for members of workgroup (2 day workshop in Amsterdam, October 2010)
  • Member participation – both Supplier and Customer members and both Architecture Forum and Security Forum members and also representatives from the SABSA Institute.
  • Gear depending projects to one another

Communication plan, to ensure that the project wins and maintains support

across the board (and the Board(s)):

  • Publication of the results. This should be done via:
  • adding the content of the whitepaper to the content of the TOGAF book.
  • adding the content of the whitepaper to the SABSA and TOGAF course material.
  • publishing the whitepaper on both the official Open Group and SABSA websites.
  • mailing to SABSA and TOG e-mail list member.
  • The working group will present its proceedings and results at the TOG conference and at the SABSA World conference at COSAC. This way, people that are interested are able to join the discussion and this way contribute to the development process.
  • Quarterly the working group will report proceedings to the Architecture Forum, the Security Forum and the SABSA Institute Board.
  • Every six weeks (in between TOG conferences) there will be a conference call with the theproject board.
  • Every working group member will receive invitation to The Open Group conference, including an outline of the agenda regarding the working group activities.
  • Every working group member will receive invitation to SABSA World conference at COSAC. These must be seen as lateral discussion and information exchange sessions.

3.Stakeholders

The following stakeholders are regarded as the project board.

3.1.Project sponsor

We are not aware of sponsoring/funding via The Open Group, other than the provisioning of facilities.

Via the SABSA Institute there will be no sponsoring.

Working group members who are not member of the Open Group are entitled to use the conference early bird rate. There is a special code available for this.

3.2.Project manager

The working group has two co-chairs.

On behalf of the Architecture Forum:

Pascal de Koning

Getronics

+31-6-29525365

On behalf of the Security Forum:

Francois Jan

Arismore

01 55 57 21 72 / 06 75 69 86 24

3.3.The Open Group

The Open Group Architecture Forum

Director:

Dave Hornford

The Open Group Security Forum

Director:

Ian Dobson

VP:

Jim Hietala

3.4.The SABSA Institute

Principal Architect:

John Sherwood

3.5.Working group members

Working group members are qualified IT architects or security architects.

What is the reward for working group members?

  • challenging questions
  • network opportunities
  • publication of names of contributors in the whitepaper.

4.Vision

For IT architects who need to take security into account, the whitepaper containing TOGAF & SABSA integration is a guide that seamless integrates a business driven security architecture into the IT architecture. Unlike regarding security as a separate product, the whitepaper gives a practical approach that makes the security requirements and services available as common TOGAF artefacts.

5.Project Scope

TOGAF and SABSA integration.

Out of Scope:

  • the development of new SABSA or TOGAF course material

6.Assumptions and Dependencies

Other projects running in both Architecture and Security Forum:

  • Modelling of TOGAF
  • TOGAF MSC
  • TOGAF Maintanance
  • Uncertainty Management
  • Integration of Security into TOGAF
  • Enterprise Security Architecture (ESA) Guide: Updating our 2004 ESA Guide.
  • Security Reference Architecture: Developing a reference architecture to demonstrate how to build secure EAs.

7.Risks

In Rome it became clear that considerable restructuring of TOGAF is

being discussed - what TOGAF should say and where it should remain silent.

What is 'core TOGAF' and what is 'optional'. As this is not in the TOGAF book, it is essential that working group members can take notice of this.

 This will be addressed in the information exchange session in Amsterdam.

 Absent members will receive a summary of the sessions. (provided that someone takes notes). This is a responsibility of the stream leader.

There is also a difference between the SABSA book and the current thinking on SABSA. This is addressed the same way as above.

Contribution is based on volunteer, pro-deo basis. How to get commitment?

 Make realistic estimation of time needed. Ask people in advance if they can provide this time.

The quality of the papers might be poor due to lack of knowledge. How to get results of good quality?

Working group members should be qualified. Preferably a mix of people who

  • are both SABSA and TOGAF certified (bridge)
  • have good SABSA knowledge (SABSA expert)
  • have good TOGAF knowledge (TOGAF expert)

 Assign “Guru” roles to lead architects, that can be asked to assist by the working group streams.

8.Resources

The Open Group provides space for live meetings combined with the conferences. It also provides conference call facilities.

Working group members are subscribers to the project email list

arch-int@opengroup.

There is also a project Web page at

The project will be executed in 3-5 streams, with a minimum of three participants per stream, preferably representing all three stakeholder groups.

9.Approval of the deliverables

The Open Group approval procedures for White Papers is clearly defined, and will be managed by the nominated Open Group staff member from either of the participating Architecture Forum or Security Forum.

The procedure to obtain approval from the SABSA Institute will be handed over by John Sherwood. He’s also responsible for this procedure being executed.

Project deliverables require the approval of both The Open Group and the SABSA Institute before they can be published. This may require a legal agreement on joint copyright. Any legal requirements are to be addressed in the formal approval procedures.

10.Planning

  • finalize project charter (July 2010)
  • input and approval from stakeholders mentioned in project charter

Milestone: Project charter approved

  • finalize call for participants text, based on project charter
  • set up e-mail lists
  • The email list is
  • set up document exchange environment
  • send call for participants to e-mail lists, project charter attached
  • include the Rome round table session attendees
  • include SABSA Institute members that are interested
  • include members of Security Forum and Architecture Forum
  • include SABSA.org mailing list
  • confirm membership to participants. Goal is to have a balanced number of all three parties. (August 2010)

Milestone: Working group assembled

  • Kick-off conference call (August 2010)
  • Introduction
  • Goals of working group
  • Inform on current thinking within TOGAF and SABSA. Not just the books.
  • Identify existing work on security in TOGAF and take that as a starting point if possible (don’t neglect it). This could possibly be introduced by working group “Integration of security into TOGAF”.
  • Project organization: streams
  • Assign members to streams

Milestone: Project execution initiated

  • TOG conference in Amsterdam (Sat 16/Sun 17 October 2010)
  • Information exchange SABSA and TOGAF: Set up a 2-day tutorial session on the Saturday and Sunday preceeding the conference, where on one day a TOGAF person would explain TOGAF to SABSA people, and on the other day a SABSA person would explain SABSA to TOGAF people.
  • Holding an initial project meeting session involving the interested parties at a mutually agreeable time during the conference week (18 – 22 October 2010)
  • Work out roadmap and deliverables per stream, including an outline of the headings to be used in writing the white paper
  • Work out streams to first draft results (November / December 2010)
  • Present draft results to group (TOG conference San Diego - February 7 - 11, 2011)
  • Discussion
  • Solve open issues
  • Work out conference results into whitepaper.chapter (Februar / March 2011)
  • Present final results to working group (April 2011, conference calls)
  • Review phase (April / May 2012)
  • Approval final versions (June 2012)

Milestone: Approval by The Open Group and SABSA Institute

  • Present result at TOG conference (July 18-22, 2011)
  • Present result at SABSA conference (COSAC, September 2011)

Milestone: Project execution completed