Welcome!

SOA & WOA Authors: Elizabeth White, Michael Thompson, Rachel A. Dines, Frank Huerta, Adrian Bridgwater

Related Topics: SOA & WOA, Java

SOA & WOA: Blog Feed Post

Defining Requirements – The TOGAF Way

How is it different?

If you are new to TOGAF, you may be wondering how this process is different from what you do in a typical “Requirement Analysis” phase of software development. Once I tell you that the many of the techniques recommended in TOGAF are what you are already using, like UML modeling techniques like Activity Models, Use-Case Models and Class Models, you may think why bother with TOGAF?

What you really do differently in TOGAF is that you take a much wider perspective of the requirement. There are three important things that you need to do:

  1. Explicitly document the current state, the expected future state and identify the gap
  2. Assess impact of the change on other projects and other organizational initiatives
  3. State the change from the perspective (viewpoint) of different stakeholders and get their buy in

While doing this, you need to keep in mind the following:

  1. Are you adhering to all the relevant organizational standards & guidelines?
  2. Have you made an explicit attempt of reuse?

Steps for Defining the Requirement

We had discussed the following lists (without the 3 steps in “Define Requirement”) in my earlier posts –
What is TOGAF? & Planning a project.

  1. Tailor TOGAF to suit your need
  2. Define scope of work and prepare plan for rollout
    1. Define the scope and get approval from the sponsor
    2. Define requirement in terms of how the business process will change, what data, application and technical infrastructure is required for accomplishing the work
      1. What should the new business process be?
      2. What application & data do we need to support the changed process?
      3. What technology infrastructure do we require to implement the change?
    3. Select a suitable solution and make the implementation plan
  3. Oversee development and implementation
  4. Manage post-implementation change

What about defining Services? The SOA approach? TOGAF has some recommendations but it looks more like a force fit - we will cover it later.

Here are some of the terminologies used in TOGAF and their meaning as used in TOGAF.

View & Viewpoint

  • View = What you see or what a stakeholder sees
  • Viewpoint = Model or description of the information contained in a view

Baseline, Target & Gap

  • Baseline = Where you are now
  • Target = Where you want to be
  • Gap = What needs to change

Deliverable & Artifact

  • Deliverable = Contractually specified document – formally reviewed, agreed, and signed off by the stakeholders
  • Artifact = Architecture from a specific viewpoint – can be a Catalog, a Matrix or a Diagram

What artifacts do you may produce?

For Business Architecture:
Catalog

  • Organization/Actor catalog
  • Driver/Goal/Objective catalog
  • Role catalog
  • Business Service/Function catalog
  • Location catalog
  • Process/Event/Control/Product catalog
  • Contract/Measure catalog

Matrix

  • Business Interaction matrix
  • Actor/Role matrix

Diagram

  • Business Footprint diagram
  • Business Service/Information diagram
  • Functional Decomposition diagram
  • Product Lifecycle diagram
  • Goal/Objective/Service diagram
  • Use-Case diagram
  • Organization Decomposition diagram
  • Process Flow diagram
  • Event diagram

For Data Architecture:
Catalog

  • Data Entity/Data Component catalog

Matrix

  • Data Entity/Business Function matrix
  • System/Data matrix

Diagram

  • Class diagram
  • Data Dissemination diagram
  • Data Lifecycle diagram
  • Data Security diagram
  • Data Migration diagram
  • Class Hierarchy diagram

For Application Architecture:
Catalog

  • Application Portfolio catalog
  • Interface catalog

Matrix

  • System/Organization matrix
  • Role/System matrix
  • Application Interaction matrix
  • System/Function matrix

Diagram

  • Application Communication diagram
  • Application and User Location diagram
  • System Use-Case diagram
  • Enterprise Manageability diagram
  • Process/System Realization diagram
  • Software Engineering diagram
  • Application Migration diagram
  • Software Distribution diagram

For Technology Architecture:
Catalog

  • Technology Standards catalog
  • Technology Portfolio catalog

Matrix

  • System/Technology matrix

Diagram

  • Environments and Locations diagram
  • Platform Decomposition diagram
  • Processing diagram
  • Networked Computing/Hardware diagram
  • Communications Engineering diagram

More Stories By Udayan Banerjee

Udayan Banerjee is CTO at NIIT Technologies Ltd, an IT industry veteran with more than 30 years' experience. He blogs at http://setandbma.wordpress.com.
The blog focuses on emerging technologies like cloud computing, mobile computing, social media aka web 2.0 etc. It also contains stuff about agile methodology and trends in architecture. It is a world view seen through the lens of a software service provider based out of Bangalore and serving clients across the world. The focus is mostly on...

  • Keep the hype out and project a realistic picture
  • Uncover trends not very apparent
  • Draw conclusion from real life experience
  • Point out fallacy & discrepancy when I see them
  • Talk about trends which I find interesting
Google