Client Side Encryption Techniques

HTTPS is the obvious solution to build secure connection between client and server. Unfortunately, it may not the answer to all web applications. For some reasons, you cannot afford SSL or it's not necessary to use it. Anyway, even if you don't have SSL you can still provide security one level up. Because of that most of users use same password for all online web applications, their accounts are vulnerable. Same password might be used for online banking and any simple web forums. If I capture a password used in a forum web site I'm able to use same password to access the victim's online banking account. For that reason, you have to be more careful when you connect public wireless network.

client side encryption

It's always possible to listen and monitor the network and capture packages which is sent and received between client and server. If your client's password is sent in a plain text to your server, it can be captured easily by listening your client's network. In order to protect your client's password you can use MD5, SHA-1, and SHA-2 which are cryptographic hash functions. On client side, you can encrypt your client's password then send it to the server to validate. On server side, passwords must be stored in your database  by using cryptographic hash functions to match two encrypted strings; one of them sent by client and another stored on database. Because, when it's encrypted by cryptographic hash functions it cannot be decrypted into the original string. This solution is called one-way encryption.

As I said, this doesn't provide comprehensive safe environment. But it protects password in plain text to be seen by watchers who listen your client's network.

Here you can find open source project written in javascript to encrypt plain text by using cryptographic hash functions.
http://code.google.com/p/crypto-js/

TOGAF Architecture Governance

Architecture Governance is scrutiny and crucial activity to have successful implementation in any organization. In TOGAF, Architecture Governance is executed in Phase G- Implementation Governance. By applying Architecture Governance you can cover the management and control of all aspects of the development and evolution architectures. Governance is essentially about ensuring that business is conducted properly. It's about guidance and effective and equitable usage of resources to ensure sustainability of an organization's strategic objectives. If your organization is not large you don't have to apply all Architecture Governance Framework and methodologies.

Architecture Governance can include the following as distinct domains with their own disciplines and processes:

• Corporate Governance
• Technology Governance
• IT Governance
• Architecture Governance

Remember that each of these domains may exist at multiple geographic levels which are global, regional and local.

Architecture Board
Architecture Boards is the main point for successful architecture governance. Architecture Board should represent the key stakeholders and contains of a group of executives who are responsible for the review of the architecture.  Architecture Board is the sponsor of the architecture within the enterprise but Architecture Board needs support from executive levels. In most organizations, CIO is the first person who is in the Architecture Board. As an Enterprise Architecture, you shouldn't overlook company's board of directors. They are responsible for and have significant impact on the business vision, objectives and strategies. Because, nowadays, IT is the core of any business and shouldn't be thought without another.

What about the size of Architecture Board
According to TOGAF, Architecture Board includes four or five permanent members. I wrote permanent members because sometimes they might not find enough time to attend the architecture review meeting or review the ongoing architecture. In order to keep architecture governance running you are able to find a way how to rotate the members of Architecture Board to senior managers. After the work of Architecture Board is reviewed by executive sponsors, remember to update the Architecture Compliance review process.

If the organization is large Architecture Board can be separated into three levels :

• Local
• Regional
• Global

Each board should be identified with responsibilities, decision making capabilities and authority limits.

When do you need to set up the Architecture Board?
According to TOGAF there are a few reason to establish the Architecture Board :

• If organization employees a new CIO
• If your company is being merged or acquire a company
• If your organization decides to change current forms of computing 
• If IT doesn't fulfill or meet business needs
• If your organization decides to apply a new enterprise architecture program
• If your organization's business changes significantly or business grows rapidly
• Requirements for complex, cross-functional solutions

In which ADM phase do you set up the Architecture Board?

Architecture Board should be defined at the beginning of the enterprise architecture. In TOGAF, this is preliminary phase. In preliminary phase, as an enterprise architect you should specify Architecture Board with support framework to provide business process and architecture governance through enterprise architecture.

What are the expectations from Architecture Board?

In TOGAF Architecture Framework, the responsibilities of Architecture Board have to be achieved are written below:

• Consistency between sub-architectures
• Identifying re-usable components
• Flexibility of enterprise architecture
• to meet changing business needs
• to leverage new technologies
• Enforcement of Architecture Compliance
• Improving the maturity levels of architecture
• 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

Further responsibilities from an operational perspective should include:

• All aspects of monitoring and control of the Architecture Contract
• Meeting on a regular basis 
• Ensuring the effective and consistent management and implementation of the architectures
• Resolving ambiguities, issues, or conflicts that have been escalated
• Providing advice, guidance, and information
• Ensuring compliance with the architectures, and granting dispensations that are in keeping with the technology strategy and objectives
• Considering policy (schedule, Service Level Agreements (SLA), etc.) changes where similar dispensations are requested and granted; new form of service requirement
• Ensuring that all information relevant to the implementation of the Architecture Contract is published under controlled conditions and made available to authorized parties
• Validation of reported service levels, cost savings, etc.

From a governance perspective, the Architecture Board is also responsible for:

• The production of usable governance material and activities
• Providing a mechanism for the formal acceptance and approval of architecture through consensus and authorized publication
• Providing a fundamental control mechanism for ensuring the effective implementation of the architecture
• Establishing and maintaining the link between the implementation of the architecture, the architectural strategy and objectives embodied in the enterprise architecture, and the strategic objectives of the business
• Identifying divergence from the architecture and planning activities for realignment through dispensations or policy updates

Architecture Governance Framework
Architecture Governance needs to be supported by an Architecture Framework. In TOGAF, Architecture Framework has 2 sections which are Conceptual Structure and Organizational Structure.
Conceptual Structure : Context, Process and Content are fundamental to the support of the architecture governance initiative. It's possible to add new governance material without excessively impacting the processes. As you see the figure below, Architecture Governance Framework is part of Enterprise Continuum. While executing the processes you can use different type of content. This gives you flexibility to implement proven methods.

Conceptual Structure

• Policy Management and take-on: In this process all kind of documents, contracts and supporting information are collected to ensure that they are managed and audited.
• Compliance: SLAs, OLAs, standards and regulatory requirements will be implemented on an ongoing basis to be sure stability, conformance, and performance monitoring.
• Dispensation: It's always possible that a compliance assessment might be rejected. If it happens there is an alternate route is provided through dispensations. Time which is not indefinite is given to set of identified service and operational criteria to meet service and operational levels.
• Monitoring and Reporting: It's required to ensure that operational and service components are managed against an agreed set of criteria.
• Business Control: It's used to make certain compliance with the organization's business policies.
• Environment Management: In order to make sure that repository-based environment supports architecture governance framework effectively.

Organizational Structure : Architecture Governance is the approach to ensure enterprise architectures and  any other architectures are managed. In order to do that it's necessary to have the proper organizational structure. In the figure below, you can see main part of the organizational structure elements. 

Organizational Structure

There are three main areas of architecture management. 

• Develop
• Implement
• Deploy

One or more groups in organization is responsible for each main area. As you see the below of the Organizational Structure figure, Enterprise Continuum support all major areas with artifacts.

Architecture Compliance
Essential point of view of Architecture Governance is to ensure each project in organization is finished in compliance with architecture contracts. In term of TOGAF it's called Architecture Compliance. Terminology usage in TOGAF about Architecture Compliance is explained below:

Levels of Architecture Compliance

Architecture Compliance Review Process

Architecture Compliance Review is needed to understand the level of Architecture Compliance. As follows, Architecture Compliance Review Process is explained by TOGAF. The main purpose of the process is to create an assessment report of the architecture. In this process, people in organization collaborates to produce assessment report which is prominent to review and define the level of architecture compliance. The report shows that how the architecture is implemented to address the business requirements. The level of architecture compliance is explained in TOGAF. You are free to customize it in accordance with your organization.

Architecture Compliance Review Process

Below, you can find 12 steps of Architecture Compliance Review Process and the roles which takes responsibility in each step.

1. Request Architecture Review: Anyone with an interest in or responsibility for the business area.
2. Identify responsible part of organization and project principals: Architecture review coordinator
3. Identify lead enterprise architect and other architects: Architecture review coordinator
4. Determine scope of review: Architecture review coordinator
5. Tailor checklists:Lead Enterprise Architect
6. Schedule architecture review meeting:Architecture review coordinator with collaboration of lead enterprise architect.
7. Interview project principles:Lead enterprise architect and/or architect, project leader, and customers
8. Analyzed completed checklists:Lead enterprise architect
9. Prepare architecture compliance review report: Lead enterprise architect
10. Present review findings: Lead enterprise architect
11. Accept review and sign-off: Architecture board and customer
12. Send assessment report/summary to architecture review coordinator: Lead enterprise architect

What are the Roles in Architecture Compliance Review Process?
Above, there are a few roles mentioned in Architecture Compliance Review Process. You can find the responsibilities of each roles as listed below:

• Architecture Board: To ensure that IT architectures are consistent and support overall business needs.
• Project Leader: Responsible for the whole project
• Architecture Review coordinator : To administer the whole architecture development and review process
• Lead Enterprise Architect: To ensure that the architecture is technically coherent and future-proof.
• Architect: One of the Lead Enterprise Architect's technical assistant.
• Customer: To ensure that business requirements are clearly expressed and understood.
• Business Domain  Expert: To ensure that the process to satisfy the business requirements are justified and understood.
• Project Principals: To ensure that the architects have a sufficiently detailed understanding of the customer department's processes. They can provide input to the business domain expert or to the architects.

Async Paging Plug-in by Javascript

In our project, I created a  web control to handle paging on server side. In server side code, data is retrieved from a datasource (it might be database) then generate valid HTML output and write into a web page. But what if you need to call  server side code asynchronously to retrieve data by javascript. You have to deal with paging by using client side code which is javascript.

After that, I decided to create nice and easy use client-side HTML control to manage paging by only pure javascript without jQuery. This doesn't mean I don't like jQuery. I'm using it a lot. But for this plug-in jQuery is not needed.

When you use Aysnc Paging control you'll see that data type is not important. It might be JSON, XML or simple Array.

First and foremost I thought implementing Async Paging plug-in and modifying its layout must be easy for developers. The only thing you have to do is initializing some values such as records count, an HTML element id where you want to generate and display it. As follows, you can find the code excerpt about how to initialize Async Paging Plug-in.

asyncPaging.init("paging", // element id where paging is drawn

data.length, // total record

10, // represents how many items are displayed in each list

1); // current page number

For Demo
For Implementation

What's new in TOGAF 9.1?

TOGAF version 9.1 was released in the beginning of December. In this version, there are some changes which are clarifications, consistency and some additional details in some chapter where needed. Here you can find the some changes I found it important:

• The Document Categorization Model has been removed
• The usage  of the terms application versus system have been reviewed and made consistent.
• The objectives sections of the ADM phases have been reworked and remove  techniques and list of steps to emphasize actual objectives.
• The artifacts which can be used in each ADM phases were added at the end of ADM phases. But in Part IV, chapter 35, Architectural Artifacts remained.
• The Phase E and F descriptions have been reworked to match the level of detail in other ADM phases.
• The uses of terminology for Transition Architecture / Roadmap / Implementation Strategy have been clarified and made consistent.
• The description of Architecture Principles now divides into two types only - Enterprise and Architecture - whereas before they called out IT Principles separately. IT principles are now seen as just part of Enterprise Architecture.
• Corrections have been made to metamodel diagrams and applied to aspects of the metamodel.
• The terms artifacts versus viewpoint have been clarified and made consistent.
• Some of the artifacts have been renamed to better reflect usage:
• System/Data matrix becomes Application/Data matrix 
• Class diagram has been replaced with Conceptual Data diagram and Logical Data diagram 
• System/Organization matrix becomes Application/Organization matrix
• Role/System matrix becomes Role/Application matrix 
• System/Function matrix becomes Application/Function matrix
• Process/System Realization diagram becomes Process/Application Realization diagram 
• System Use-Case diagram becomes Application Use-Case diagram 
• System/Technology matrix becomes Application/Technology matrix 
• The relationship of the Enterprise Repository to the Architecture Repository is clarified in Part V, Chapter 41

For more information about changes I recommend to read whole official document written by Open Group.

http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap04.html

Guideline for Returning Value From a Method

There are two different scenarios when you return an object from  a method. If everything goes well, you get what you expect. If not, in my opinion, there are 3 different approaches:

1. Return null
2. Return concrete object with default properties
3. Throw a meaningful exception 

For example. You have product id to be passed to a method (GetById) to retrieve concrete Product object. If Product is found on your database-resource, GetById() returns a Product object which is not null. This is best case scenario.

What if Product is not found or parameters are wrong, what should GetById() method return? null or concrete Product object whose properties have default value or a meaningful exception. Let's see all 3 approaches' advantages and disadvantages.

Returning null
When I asked my colleagues and my friends, most of all they prefer this approach, returning null. But I have concerns about it.

Disadvantages:

• Everywhere on your code you have to check whether returning object is null. 
• It's always possible to forget to check if object is null. It causes runtime error.
• Code file might be full of if statements. It makes code unreadable and dirty.

Returning concrete object which is not null but whose properties have default value

Disadvantages:

• You're always doubt about to know if record is really found on database-resource.
• You may miss a serious problem.
• You might need to check unique id of the concrete object (for instance product id) to make sure returning value is valid. However it's useless. Every object doesn't need to have unique id. Beside that, it's as same solution as checking null object.

Throw a meaningful exception
Throwing a meaningful exception is my favorite solution. By applying this practice, you eliminate all disadvantages above. But it comes with its own disadvantages which are manageble.
 
Advantages :

• You can exactly know what the problem is.
• You don't have to return an magic number to identify the result. Such as, 1 is ok, 2 is parameters are missing, 3 is object not found.
• You don't have to check if object is null. Throw the exception to up-level. Your try-catch block on up-level decides how to react.

Disadvantages :

• You need to manage exceptions properly. Some exceptions doesn't need to be logged or shown to end user.
• You might need to have custom exception classes to identify exact problem. For instance, instead of throwing object is null exception,  you might need to use ProductNotFound exception class.

Sample Code 
You can find sample code guideline about returning meaningful value from a method. Please focus on code between row number 29 - 44.

In Main method I created an int array to test all possibilities. In catch block you can decide what you want. You might need to continue the process or stop to run the code and exit the application or show error message to end user.

Id = 1; the method returns a Product object which is not null. It's the best case.
Id = 6; the method throws ProductNotFound exception.
Id = -5 and Id = 0; the method throws ArgumentOutOfRangeException.

As you see the place where I invoke GetById() method, I don't check whether object is null. All validations and strategies are handled in GetById() method which is in business layer.

   1:  public class ProductRepository

   2:  {

   3:      private List<Product> Products;

   4:      public ProductRepository()

   5:      {

   6:          Products = new List<Product> {

   7:              new Product { Id = 1, Name = "harddisk" },

   8:              new Product { Id = 2, Name = "mouse" },

   9:              new Product { Id = 3, Name = "keyboard" },

  10:              new Product { Id = 4, Name= "speaker"}

  11:          };

  12:      }

  13:   

  14:      public Product GetById(int id)

  15:      {

  16:          return Products.SingleOrDefault(x => x.Id == id);

  17:      }

  18:  }

  19:   

  20:  public class ProductManager

  21:  {

  22:      private ProductRepository repository;

  23:   

  24:      public ProductManager() 

  25:      {

  26:          repository = new ProductRepository();    

  27:      }

  28:   

  29:      public Product GetById(int id)

  30:      {

  31:          // validate input

  32:          if (id < 1)

  33:              throw new ArgumentOutOfRangeException("id=" + id);

  34:   

  35:          // run exact code

  36:          Product result = repository.GetById(id);

  37:   

  38:          // validate result

  39:          if (result == null)

  40:              throw new ProductNotFound("id="+id+" not found");

  41:   

  42:          return result;

  43:      }

  44:  }

  45:   

  46:  public class ProductNotFound : Exception 

  47:  {

  48:      private string customMessage;

  49:      public ProductNotFound(string message) 

  50:      {

  51:          customMessage = message;

  52:      }

  53:   

  54:      public ProductNotFound() { }

  55:   

  56:      public override string Message

  57:      {

  58:          get

  59:          {

  60:              return base.Message + " " + customMessage;

  61:          }

  62:      }

  63:  }

  64:   

  65:  public class Product

  66:  {

  67:      public int Id { get; set; }

  68:      public string Name { get; set; }

  69:  }

  70:   

  71:  class Program

  72:  {

  73:      static void Main(string[] args)

  74:      {

  75:          int[] ids = new int[] { 1, 6, -5, 0 };

  76:          int errorCount = 0;

  77:   

  78:          ProductManager manager = new ProductManager();

  79:          foreach (int item in ids)

  80:          {    

  81:              try

  82:              {

  83:                  Product product = manager.GetById(item);

  84:              }

  85:              catch (Exception ex)

  86:              {

  87:                  errorCount++;

  88:                  Console.WriteLine(ex.Message);

  89:              }

  90:          }

  91:   

  92:          Console.WriteLine("Error Count : " + errorCount);

  93:          Console.Read();

  94:      }

  95:  }