Architecture Governance – In TOGAF what does it mean

If you are clear about what governance means then you can skip the next section. However, if you have heard the term – Corporate Governance, SOA Governance, IT Governance – but you are not exactly sure about what it really means, then here is an explanation.

Suppose you are interested that an entity works in a way you want it to work. If you are managing the entity then you have the necessity authority to ensure it. However, you don’t manage the entity directly then what do you do? To do anything you need to have some authority or influence over the entity. You can discuss with the management team of the entity and come to an agreement on what needs to be done. Then you also come to an agreement on how to ensure that what you have agreed is followed.

In other words, you lay down a governance framework. Let us look at an example.

Government wants the corporate to follow certain guidelines – some dos and don’ts. But, government do not and cannot manage each and every corporate directly. So, they have in place Sarbanes–Oxley Act or SOX which is also known as ‘Public Company Accounting Reform and Investor Protection Act’ or ‘Corporate and Auditing Accountability and Responsibility Act’. This is corporate governance. Similarly, you also have Basel II for banks, which try to ensure that banks don’t take too much risk with money invested with them.

To put governance in place you need to have:

  1. Discipline = Commitment to adhere to procedures, processes, and authority structures
  2. Transparency = Actions and decision support available for inspection
  3. Independence = Mechanisms to minimize or avoid potential conflicts of interest
  4. Accountability = Groups who take actions or make decisions are authorized and accountable
  5. Responsibility = Contracted party to act responsibly
  6. Fairness = No unfair advantage to any one particular party


How does TOGAF Define Architecture Governance?

If you had gone through my earlier posts (What is TOGAF?, Defining Requirement and Planning a project) you would realize that TOGAF is not about solution design or application development. It provides a set of guidelines of what the final solution should adhere to. That is what the Architecture Governance all about. It talks about:

  • Control: Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization
  • Compliance: Implementing a system to ensure compliance with internal and external standards and regulatory obligations
  • Management: Establishing processes that support effective management of the above processes within agreed parameters
  • Accountability: Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization

How do you enforce the governance?

TOGAF will normally be initiated by CIO, but for it to succeed broad support from the rest of the organization is needed.

So the aim is to get the authority from top management in the Preliminary Phase. To ensure that the authority is recognized by the rest of the organization an “Architecture Board” in constituted. TOGAF recommends that the board should 4 to 5 permanent members, the upper limit being 10. The important point is to include all the important people in the organization.

TOGAF also recommends that there is an “Architecture Contract” for all the work that needs to be executed. Architecture Contracts are joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose.

What does the Architecture Board do?

It acts as the approving and controlling authority for the following:

  • Consistency between sub-architectures
  • Identifying re-usable components
  • Flexibility of enterprise architecture; to meet business needs and utilize new technologies
  • Enforcement of Architecture Compliance
  • Improving the maturity level of architecture discipline within the organization
  • Ensuring that the discipline of architecture-based development is adopted
  • Providing the basis for all decision-making with regard to changes to the architectures
  • Supporting a visible escalation capability for out-of-bounds decisions

The Meaning of Architecture Compliance

Finally, I find the following representation of “what different types of compliance are” to quiet nice:

Irrelevant

No relation between Standard & Implementation

Consistent

There is overlap between Standard & Implementation properly

Compliant

Implementation is a subset of Standard and is done properly

Conformant

Standard only covers part of implementation but that part is done properly

Fully Compliant

Implementation is exactly as per Standard

Non-Conformant

The square indicates that overlap has deviation

Advertisements

Is the Cloud Secure

Obviously, the answer is it depends … on your security needs … on what you are comparing it with … on which cloud offering you are looking at.

Therefore, instead of providing a one word “Yes” or “No” answer let me ask you a set of questions that will help you answer the question for yourself. These questions will help you in identifying, for your given context, if the cloud application that you are evaluating is more or less secure compared to status quo or the alternatives that you are considering. The important point is to decide what threats are more significant than others and what can become a show stopper. In short:

  • What am I comparing?
  • What threats are relevant and I need to consider seriously?
  • Are there any show stoppers?
  • Do I have the necessary facts?
  • Is lack of knowledge clouding my perception?

The Questions

Q1. What are you comparing it with…?

  1. …in-premise infrastructure
  2. …data centre owned and managed by you
  3. …data centre owned by you but managed by third party
  4. …data centre hosted on a third party infrastructure but managed by you
  5. …data centre hosted on a third party infrastructure but managed by somebody else

Q2. What cloud services are you looking at…? (Here is a detailed discussion)

  1. …virtual machine instances (IaaS) like Amazon AWS or Rackspace Cloud Servers
  2. …cloud platform (PaaS) like Google GAE or Microsoft Azure
  3. …hosted Email like Gmail
  4. …hosted CRM like Salesforce.com
  5. …hosted ERP like SAP Business By Design
  6. …office suit in the cloud like Google Apps
  7. …any other

Q3. Which of the generic security threats do you consider very important? Threats that…

  1. …attempt to steal sensitive information
  2. …comes from inside, from disgruntled employee
  3. …exploit existing software bugs and vulnerabilities with the intent of crashing a system
  4. …are intended to overwhelm critical system resources such as CPU and RAM
  5. …convert compromised computers into a network of bot-nets in order to mount additional attacks

Q4. Is there any cloud specific security threat that needs to be considered? Threats like…

  1. …software bug leading to accidental exposure of information to other parties sharing the resources
  2. …sensitive data retrieved and leaked out from released resources
  3. …insecure interface and API exposed by the cloud provider
  4. …losing control over their ability to ensure strong authentication at the user level

Q5. Do you need to comply with any government regulation like…?

  1. …HIPAA
  2. …SOX
  3. …PCI
  4. …Data location restriction
  5. …others

You can see from this Google Trends chart how cloud security concerns are growing.

Here are some relevant links:

Defining Requirement – the TOGAF way

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

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? 

Catalog Matrix Diagram
Business Architecture
  • Organization/Actor catalog
  • Driver/Goal/Objective catalog
  • Role catalog
  • Business Service/Function catalog
  • Location catalog
  • Process/Event/Control/Product catalog
  • Contract/Measure catalog
  • Business Interaction matrix
  • Actor/Role matrix
  • 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
Data Architecture
  • Data Entity/Data Component catalog
  • Data Entity/Business Function matrix
  • System/Data matrix
  • Class diagram
  • Data Dissemination diagram
  • Data Lifecycle diagram
  • Data Security diagram
  • Data Migration diagram
  • Class Hierarchy diagram
Application Architecture
  • Application Portfolio catalog
  • Interface catalog
  • System/Organization matrix
  • Role/System matrix
  • Application Interaction matrix
  • System/Function matrix
  • 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
Technology Architecture
  • Technology Standards catalog
  • Technology Portfolio catalog
  • System/Technology matrix
  • Environments and Locations diagram
  • Platform Decomposition diagram
  • Processing diagram
  • Networked Computing/Hardware diagram
  • Communications Engineering diagram

Is Cloud losing its Value Proposition

We all know that hardware prices always comes down – but have you noticed any such trend in cloud computing? So, what happens when hardware prices keep coming down and cloud services pricing remains steady? The cloud value proposition of lowering IT costs slowly disappears … right?

There is no doubt that the range of services available has significantly increased but on the price front there has been very little movement. Yes, if you want to try cloud for free then you have more alternative today – for example Amazon has introduced a micro instance.

Google App Engine prices have remained more or less the same since the launch. Same is true for Microsoft Azure. Amazon is not much better. Since the launch of the AWS there has hardly been any price reduction. Between mid and end 2009 Amazon announced around 15% price reduction on a range of its services is probably the only instance.

Compare this with the drop in price of available processing power and storage where the prices have been halving every 2 year. Have a look at the statistics given below. The footprint has also been reducing with the price thereby also reducing the management overhead.

If you superimpose this steady pricing of the cloud service what can you conclude?

  1. What was very cost effective (50% less) 2-3 year back may only be marginally cost effective.
  2. If the cloud cost does not come down, cloud services will cease to be cost effective.

Moore’s Law and other related statistics

Moore’s law describes a long-term trend in the history of computing hardware. The number of transistors that can be placed inexpensively on an integrated circuit has doubled approximately every two years. The trend has continued for more than half a century and is not expected to stop until 2015 or later. The price of processing power has shown a similar decline. Here is the statistics from Wikipedia.

Matthew Komorowski has collected hard drive capacity/price data and created the graph below. The cost reduction is in the order of about 40-45% per year – which means it becomes half in 2 years. This trend is visible for last 30 years and likely to continue for some more time to come.

Planning a project – the TOGAF way

If you have no intention of adopting TOGAF then does it make any sense for you to understand how TOGAF recommends planning a project? I think the answer is yes if somebody can explain it in simple terms. Since TOGAF is flexible and it recommends many techniques which you might find useful and apply in isolation, it may make sense for you to glance through these series of posts. (In this post I am talking about a technique of Stakeholder Analysis)

As we had seen earlier, the heart of the “TOGAF – ADM” is how you define the work that needs to be done. It is done from “Phase A” to “Phase F” in a top-down manor. (See my earlier post – What is TOGAF – without jargon for an overview)

In the last post we had seen that TOGAF – ADM consists of 4 major steps. I had grouped 6 phases of ADM to call it the second step. Now let me logically break this step into 3 sub steps.

  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 – this step consists of 3 distinct phases
    3. Select a suitable solution and make the implementation plan – this step is also made of 2 ADM phases
  3. Oversee development and implementation
  4. Manage post-implementation change

Define scope and get approval

[Phase A: Architecture Vision]

“…defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals…”

Architecture Vision” means a description of where we want to be. It is to be used, among others things, to help the sponsor to sell the project to stakeholders and decision-makers.

“…it describes how the new capability will meet the business goals and strategic objectives and address the stakeholder concerns when implemented…”

New capability” in this context means whatever the enterprise will be able to do after the project is implemented which is not possible today.

Define requirement

[Phase B to Phase D]

The following table indicates what TOGAF means when it talks about different types of architecture:

Business Architecture The business strategy, governance, organization, and key business processes.
Data Architecture The structure of an organization’s logical and physical data assets and data management resources.
Application Architecture A blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
Technology Architecture The software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.

In this step you need to define, in these four dimensions, where you are (baseline), where you want to be (target) and what the gap is.

Select solution and make implementation plan

[Phase E & Phase F]

This is where you get into specific – select the actual technology – decide on make vs. buy. Here, you group requirements into specific projects, access priorities, identify dependencies and prepare the project plan. You also need to ensure that your plan is in sync with other organizational initiatives. You also will do a cost-benefit analysis of individual projects.

Stakeholders

Identifying the stakeholders, explaining to them what you are planning to achieve and getting their buy-in is a critical theme which runs across these phases. It is somewhat like the saying that “justice should only be done but should appear to be done”. You should not only plan to create a more efficient organization but everybody who matters should be convinced about it.

To achieve this you need to do the following:

  • Know who the stakeholders are
  • Understand their concerns
  • Identify how your solution is going to address their concerns
  • Create suitable documents which will explain the specific aspect of the solution that is of interest to the stakeholder – in TOGAF term it is called “Selecting a Viewpoint

We will examine Viewpoint in more detail in subsequent post.

TOGAF recommends a technique for stakeholder analysis where you produce a document like this:

Stakeholder Group Stakeholder Ability to Disrupt the Change Current Understanding Required Understanding Current Commitment Required Commitment Required Support
CIO Smith

H

M

H

L

M

H

CFO Brown

M

M

M

L

M

M

This analysis can be extremely useful. Unfortunately, this document cannot be shared – it has to be kept away from all the stakeholders. If you are an external consultant it may be easier to maintain the secracy.

In the next post I will get into more detail of how you go about defining requirement, what techniques it recomends and how much flexibility you have remaining within the TOGAF framework. I will also follow this up with more details on each individual phases.