Solution architecture: Scalable Umbraco CMS web app

From Microsoft

Medium Umbraco CMS web app configured to scale and optimal for high-traffic sites. It uses two web apps, one for your front-end app and the other for your back-office app, deployed in a single region with autoscaling enabled.

This solution is built on the Azure managed services: SQL Database, Storage, Application Insights and Redis Cache. These services run in a high-availability environment, patched and supported, allowing you to focus on your solution instead of the environment they run in.

Your estimate


Estimated monthly cost

Understand how this was calculated and customize to your needs

Pricing calculator

Deploy to Azure

Use the following pre-built template to deploy this architecture to Azure

Deploy to AzureView template source

Implementation guidance


Web Apps

Run an Umbraco CMS on the Web Apps feature of Azure App Service with the front-end and back-office apps running on the same app.

SQL Database

Store your site’s content in Azure SQL Database. The back-office web app and front-end web app use the same database. Use Azure SQL Database’s features such as backup and high availability.


Store all your media in Azure Storage, so you can reduce I/O operation on the web app file server and improve performance.

Application Insights

Detect issues, diagnose crashes, and track usage in your web app with Application Insights. Make informed decisions throughout the development lifecycle.

Redis Cache

Store session state and output cache on Azure Redis Cache to improve performance and reduce the load on your web front ends.
Posted in Business Model, Problem solving, Software architecture | Leave a comment

Run Umbraco CMS with Flexible Load Balancing on AWS

In version 7.3, Umbraco CMS the popular open source CMS introduced the flexible load balancing feature, which makes the setup of load-balanced applications a lot easier. In this blog post, we’ll follow the guidelines in the Umbraco documentation to set up a load-balanced Umbraco application on AWS. We’ll let AWS Elastic Beanstalk manage the deployments, load balancing, auto scaling, and health monitoring for us.

Application Architecture

When you use the flexible load balancing feature, any updates to Umbraco content will be stored in a queue in the master database. Each server in the load-balanced environment will automatically download, process, and cache the updates from the queue, so no matter which server is selected by the Elastic Load Balancing to handle the request, the user will always receive the same content. Umbraco administration doesn’t work correctly if accessed from a load-balanced server. For this reason, we’ll set up a non-balanced environment to be accessed only by the administrators and editors.

Create Elastic Beanstalk Environments

We’ll start by creating a single instance environment for administrators and editors. This environment will have the master database server as an RDS instance. In the Elastic Beanstalk console, choose Create New Application. Type a name for the application, and then choose Create. When you see the message “No environments currently exist for this application”, choose Create one now. Select Web server environment for the environment tier.

On the Create a new environment page, choose .NET for Platform, and then choose Configure more options.

On the next page, under Capacity, set the Environment type to Single instance. Under Database, for Engine, choose sqlserver. Set the Storage field to, at minimum, 20 GB, review the information, and then choose Create environment.

Next, we’ll create a load-balanced environment for the front-end users. Follow the steps you used to create the first Elastic Beanstalk environment. When you reach the configuration page, select High availability, and then choose Create environment.

Configure RDS Database Server Security Groups

When we created the RDS DB instance through the first environment, Elastic Beanstalk automatically configured the security to allow the servers in this environment to access the database. We’ll configure the security for the second environment manually. By following these steps, the front-end servers will be able to connect to the database:

  1. In the Elastic Beanstalk console, copy the name of the security group for the front-end environment. You will need this for step 7 of this procedure.
  2. In the admin environment, choose Configuration, and then choose RDS.
  3. Choose the View in RDS Console link.
  4. On the Details tab in the RDS console, in the Security and Network section, choose Security Groups.
  5. Choose the name of the active security group to open it in the EC2 console.
  6. In the EC2 console, you should see that Elastic Beanstalk has already added a rule for the admin environment.
  7. Choose Edit, and then choose Add Rule. For Type, choose MS SQL. For Source, paste the name of the security group for the front-end environment.

Handle Session State in a Load Balanced Environment

By default, ASP.NET stores the user’s session in memory. This means the user will lose session information if the next request goes to a different server. To prevent this from happening while keeping the default session provider, configure sticky sessions for your load balancer.

In the Elastic Beanstalk console, navigate to the front-end environment configuration. You can use the Sessions section under the Load Balancing settings to specify whether the load balancer for the application will allow session stickiness. Select the Enable Session Stickiness check box.

When you enable session stickiness, ELB will send all requests for a specific user to the same back-end web server. This can result in an imbalance of requests across all back ends, with some servers having more load than others. When you scale down, the termination of an instance can result in a loss of sessions assigned to it. For this reason, consider storing the sessions in a central location like a SQL Server database and use the SqlSessionStateStore provider.

AWS offers other options, for example, storing the sessions in a NoSQL database using the DynamoDBSessionStore provider or using the Amazon ElastiCache to store the sessions in the cloud as in-memory cache. For information, see the ElastiCache as an ASP.NET Session Store blog post.

A One-Step Alternative: CloudFormation Template

You can download and use this CloudFormation template to create resources similar to those created in the preceding steps. If you use the template, you will still have to prepare and publish your own version of Umbraco from a local machine. We’ll do that next.

The template is written to create the RDS database as a separate resource from the environments. You’ll see in the previous steps the DB is tied to the admin environment (for example, if you delete the environment, the DB will be deleted, too). This works well during development or testing, but is not ideal for production. If you should accidentally delete your database, by default, Elastic Beanstalk creates a snapshot on environment termination so it can be recovered. For information about how to decouple the DB from your environment, see Using Elastic Beanstalk with Amazon RDS in the Elastic Beanstalk Developer Guide.

Prepare the Umbraco CMS Locally

To keep things simple, we’ll download Umbraco from As of this writing, the current version is v7.5.

From IIS on the local machine, add a new website with the following settings:

File and Folder Permissions

To ensure the Umbraco installation will run smoothly, grant the read and write permissions to the application pool user for Umbraco’s files and folders. In IIS, right-click the UmbracoApp website, and then click Edit Permissions. Grant modify or full-control permissions to IIS_IUSRS. For information, see File and folder permissions in the Umbraco documentation.

When we deploy the application to AWS, we need to update the permissions for IIS_IUSRS, too. It isn’t easy to access and grant permissions to each Windows server in the environment. If we create an .ebextension, Elastic Beanstalk can automate the permissions process. It can also allow us to run extra commands during the application deployment:

    command: if not exist "C:\inetpub\wwwroot" mkdir "C:\inetpub\wwwroot"
    command: Icacls.exe "C:\inetpub\wwwroot" /grant IIS_IUSRS:(OI)(CI)F

Here is the .ebextension saved as a .config file:


Although this one is written in YAML, you can write .ebextensions in JSON, too. You can extend the .ebextension by writing a test to ensure the commands run on the first deployment only and not on redeployments. For more information, see the Configuring Advanced Logging on AWS Elastic Beanstalk blog post or the .ebextensions documentation.

Custom Machine Key

By default, ASP.NET generates a unique machine key for each server. In a load-balanced environment, this will cause validation errors and invalid view state. To fix this issue, make sure the machine key is the same on all servers. One of the simplest ways to generate a custom key is from IIS.

In IIS, on the Machine Key page, click Generate Keys. Change the settings as follows, and click Apply.

Create an Empty Database

Before running the CMS installation, we’ll create an empty database in our RDS DB server. Open AWS Explorer in Visual Studio, right-click the DB instance we created in the first step, and then select Create SQL Server Database.

If you encounter any problems connecting to the RDS server, add the IP address of the development machine to the RDS DB security group. Make sure your Windows Firewall allows outbound access for 1433 port.

Run the Umbraco CMS Installation

In IIS, click Browse. The Umbraco installation should start. Enter the required information and use the RDS DB information to complete the fields for the database configuration step.

Publish Umbraco CMS to AWS

Finally, open the UmbracoApp folder in Visual Studio. From the File menu, click Open. Click Web site, click File system, and then navigate to C:\inetpub\wwwroot\UmbracoCms. Right-click the project, and then select Publish to AWS to deploy to the admin environment and then deploy again to the front-end environment.

The EBS volumes attached to the instances in the environments are isolated and not shared. When compared to other load-balanced solutions that use shared storage, there is no extra work required to separate Umbraco logging file paths, change XML cache content settings, or update the configuration for Lucene/Examine indexes.


You now have an Umbraco application that is ready to scale up or down on AWS, and you can take this further using Elastic Beanstalk, there are many options to customize your environments, for example, associating a custom domain name or enabling HTTPS.

We hope you found the information in this post helpful. If you have questions or other feedback, please leave it in the comments below.

Posted in Business Model, Knowledge, SOA, Software architecture | Leave a comment

Cordova application architecture.


Apache Cordova is an open-source mobile development framework. It allows you to use standard web technologies – HTML5, CSS3, and JavaScript for cross-platform development. Applications execute within wrappers targeted to each platform, and rely on standards-compliant API bindings to access each device’s capabilities such as sensors, data, network status, etc.

Use Apache Cordova if you are:

  • a mobile developer and want to extend an application across more than one platform, without having to re-implement it with each platform’s language and tool set.
  • a web developer and want to deploy a web app that’s packaged for distribution in various app store portals.
  • a mobile developer interested in mixing native application components with a WebView (special browser window) that can access device-level APIs, or if you want to develop a plugin interface between native and WebView components.


There are several components to a cordova application. The following diagram shows a high-level view of the cordova application architecture.


The Cordova-enabled WebView may provide the application with its entire user interface. On some platforms, it can also be a component within a larger, hybrid application that mixes the WebView with native application components. (See Embedding WebViews for details.)

Web App

This is the part where your application code resides. The application itself is implemented as a web page, by default a local file named index.html, that references CSS, JavaScript, images, media files, or other resources are necessary for it to run. The app executes in a WebView within the native application wrapper, which you distribute to app stores.

This container has a very crucial file – config.xml file that provides information about the app and specifies parameters affecting how it works, such as whether it responds to orientation shifts.



Posted in Java, Knowledge, Programming | Leave a comment

Java Programming Tutorial OOP Exercises

Reference from

1.1  Ex: The Circle Class (An Introduction to Classes and Instances)

This first exercise shall lead you through all the basic concepts in OOP.


A class called circle is designed as shown in the following class diagram. It contains:

  • Two private instance variables: radius (of the type double) and color (of the type String), with default value of 1.0 and “red“, respectively.
  • Two overloaded constructors – a default constructor with no argument, and a constructor which takes a double argument for radius.
  • Two public methods: getRadius() and getArea(), which return the radius and area of this instance, respectively.

The source codes for is as follows:

 * The Circle class models a circle with a radius and color.
public class Circle {  // Save as ""
   // private instance variable, not accessible from outside this class
   private double radius;
   private String color;
   // The default constructor with no argument.
   // It sets the radius and color to their default value.
   public Circle() {
      radius = 1.0;
      color = "red";
   // 2nd constructor with given radius, but color default
   public Circle(double r) {
      radius = r;
      color = "red";
   // A public method for retrieving the radius
   public double getRadius() {
     return radius; 
   // A public method for computing the area of circle
   public double getArea() {
      return radius*radius*Math.PI;

Compile ““. Can you run the Circle class? Why?

This Circle class does not have a main() method. Hence, it cannot be run directly. This Circle class is a “building block” and is meant to be used in another program.

Let us write a test program called TestCircle (in another source file called which uses the Circle class, as follows:

public class TestCircle {  // Save as ""
   public static void main(String[] args) {
      // Declare an instance of Circle class called c1.
      // Construct the instance c1 by invoking the "default" constructor
      // which sets its radius and color to their default value.
      Circle c1 = new Circle();
      // Invoke public methods on instance c1, via dot operator.
      System.out.println("The circle has radius of " 
         + c1.getRadius() + " and area of " + c1.getArea());
      // Declare an instance of class circle called c2.
      // Construct the instance c2 by invoking the second constructor
      // with the given radius and default color.
      Circle c2 = new Circle(2.0);
      // Invoke public methods on instance c2, via dot operator.
      System.out.println("The circle has radius of " 
         + c2.getRadius() + " and area of " + c2.getArea());

Now, run the TestCircle and study the results.

More Basic OOP Concepts
  1. Constructor: Modify the class Circle to include a third constructor for constructing a Circle instance with two arguments – a double for radius and a String for color.
    // 3rd constructor to construct a new instance of Circle with the given radius and color
    public Circle (double r, String c) { ...... }

    Modify the test program TestCircle to construct an instance of Circle using this constructor.

  2. Getter: Add a getter for variable color for retrieving the color of this instance.
    // Getter for instance variable color
    public String getColor() { ...... }

    Modify the test program to test this method.

  3. public vs. private: In TestCircle, can you access the instance variable radius directly (e.g., System.out.println(c1.radius)); or assign a new value to radius (e.g., c1.radius=5.0)? Try it out and explain the error messages.
  4. Setter: Is there a need to change the values of radius and color of a Circle instance after it is constructed? If so, add two public methods called setters for changing the radius and color of a Circle instance as follows:
    // Setter for instance variable radius
    public void setRadius(double newRadius) {
       radius = newRadius;
    // Setter for instance variable color
    public void setColor(String newColor) { ...... }

    Modify the TestCircle to test these methods, e.g.,

    Circle c4 = new Circle();   // construct an instance of Circle
    c4.setRadius(5.0);          // change radius
    System.out.println("radius is: " + c4.getRadius()); // Print radius via getter
    c4.setColor(......);        // Change color
    System.out.println("color is: " + c4.getColor());   // Print color via getter
    // You cannot do the following because setRadius() returns void,
    // which cannot be printed.
  5. Keyword “this“: Instead of using variable names such as r (for radius) and c (for color) in the methods’ arguments, it is better to use variable names radius (for radius) and color (for color) and use the special keyword “this” to resolve the conflict between instance variables and methods’ arguments. For example,
    // Instance variable
    private double radius;
    // Constructor
    public Circle(double radius) {
       this.radius = radius;   // "this.radius" refers to the instance variable
                               // "radius" refers to the method's parameter
       color = .......   
    // Setter of radius
    public void setRadius(double radius) {
       this.radius = radius;   // "this.radius" refers to the instance variable
                               // "radius" refers to the method's argument

    Modify ALL the constructors and setters in the Circle class to use the keyword “this“.

  6. Method toString(): Every well-designed Java class should contain a public method called toString() that returns a short description of the instance (in a return type of String). The toString() method can be called explicitly (via instanceName.toString()) just like any other method; or implicitly through println(). If an instance is passed to the println(anInstance) method, the toString() method of that instance will be invoked implicitly. For example, include the following toString() methods to the Circle class:
    // Return a description of this instance in the form of
    // Circle[radius=r,color=c]
    public String toString() {
       return "Circle[radius=" + radius + " color=" + color + "]";

    Try calling toString() method explicitly, just like any other method:

    Circle c1 = new Circle(5.0);
    System.out.println(c1.toString());   // explicit call

    toString() is called implicitly when an instance is passed to println() method, for example,

    Circle c2 = new Circle(1.2);
    System.out.println(c2.toString());  // explicit call
    System.out.println(c2);             // println() calls toString() implicitly, same as above
    System.out.println("Operator '+' invokes toString() too: " + c2);  // '+' invokes toString() too

The final class diagram for the Circle class is as follows:


1.2  Ex: A Simplified Circle Class


1.3  Ex: The Rectangle Class


1.4  Ex: The Employee Class


1.5  Ex: The InvoiceItem Class


1.6  Ex: The Account Class


1.7  Ex: The Date Class


1.8  Ex: The Time Class


2.  Exercises on Composition

2.1  Ex: The Author and Book Classes (An Introduction to OOP Composition)

This first exercise shall lead you through all the concepts involved in OOP Composition.


A class called Author (as shown in the class diagram) is designed to model a book’s author. It contains:

  • Three private instance variables: name (String), email (String), and gender (char of either 'm' or 'f');
  • One constructor to initialize the name, email and gender with the given values;
    public Author (String name, String email, char gender) {......}

    (There is no default constructor for Author, as there are no defaults for name, email and gender.)

  • public getters/setters: getName(), getEmail(), setEmail(), and getGender();
    (There are no setters for name and gender, as these attributes cannot be changed.)
  • A toString() method that returns “Author[name=?,email=?,gender=?]“, e.g., “Author[name=Tan Ah Teck,,gender=m]“.

Write the Author class. Also write a test driver called TestAuthor to test all the public methods, e.g.,

Author ahTeck = new Author("Tan Ah Teck", "", 'm'); // Test the constructor
System.out.println(ahTeck);  // Test toString()
ahTeck.setEmail("");  // Test setter
System.out.println("name is: " + ahTeck.getName());     // Test getter
System.out.println("eamil is: " + ahTeck.getEmail());   // Test getter
System.out.println("gender is: " + ahTeck.getGender()); // Test gExerciseOOP_MyPolynomial.pngetter


A class called Book is designed (as shown in the class diagram) to model a book written by one author. It contains:

  • Four private instance variables: name (String), author (of the class Author you have just created, assume that a book has one and only one author), price (double), and qty (int);
  • Two constructors:
    public Book (String name, Author author, double price) { ...... }
    public Book (String name, Author author, double price, int qty) { ...... }
  • public methods getName(), getAuthor(), getPrice(), setPrice(), getQty(), setQty().
  • A toString() that returns “Book[name=?,Author[name=?,email=?,gender=?],price=?,qty=?“.  You should reuse Author’s toString().

Write the Book class (which uses the Author class written earlier). Also write a test driver called TestBook to test all the public methods in the class Book. Take Note that you have to construct an instance of Author before you can construct an instance of Book. E.g.,

// Construct an author instance
Author ahTeck = new Author("Tan Ah Teck", "", 'm');
System.out.println(ahTeck);  // Author's toString()

Book dummyBook = new Book("Java for dummy", ahTeck, 19.95, 99);  // Test Book's Constructor
System.out.println(dummyBook);  // Test Book's toString()

// Test Getters and Setters
System.out.println("name is: " + dummyBook.getName());
System.out.println("price is: " + dummyBook.getPrice());
System.out.println("qty is: " + dummyBook.getQty());
System.out.println("Author is: " + dummyBook.getAuthor());  // Author's toString()
System.out.println("Author's name is: " + dummyBook.getAuthor().getName());
System.out.println("Author's email is: " + dummyBook.getAuthor().getEmail());

// Use an anonymous instance of Author to construct a Book instance
Book anotherBook = new Book("more Java", 
      new Author("Paul Tan", "", 'm'), 29.95);
System.out.println(anotherBook);  // toString()

Take note that both Book and Author classes have a variable called name. However, it can be differentiated via the referencing instance. For a Book instance says aBook, refers to the name of the book; whereas for an Author‘s instance say auAuthor, refers to the name of the author. There is no need (and not recommended) to call the variables bookName and authorName.


  1. Printing the name and email of the author from a Book instance. (Hint: aBook.getAuthor().getName(), aBook.getAuthor().getEmail()).
  2. Introduce new methods called getAuthorName(), getAuthorEmail(), getAuthorGender() in the Book class to return the name, email and gender of the author of the book. For example,
    public String getAuthorName() {
       return author.getName();
          // cannot use as name is private in Author class

2.2  Exercise (Advanced): Book and Author Classes Again – An Array of Objects as an Instance Variable


In the earlier exercise, a book is written by one and only one author. In reality, a book can be written by one or more author. Modify the Book class to support one or more authors by changing the instance variable authors to an Author array.


  • The constructors take an array of Author (i.e., Author[]), instead of an Author instance. In this design, once a Book instance is constructor, you cannot add or remove author.
  • The toString() method shall return “Book[name=?,authors={Author[name=?,email=?,gender=?],......},price=?,qty=?]“.

You are required to:

  1. Write the code for the Book class. You shall re-use the Author class written earlier.
  2. Write a test driver (called TestBook) to test the Book class.


// Declare and allocate an array of Authors
Author[] authors = new Author[2];
authors[0] = new Author("Tan Ah Teck", "", 'm');
authors[1] = new Author("Paul Tan", "", 'm');

// Declare and allocate a Book instance
Book javaDummy = new Book("Java for Dummy", authors, 19.99, 99);
System.out.println(javaDummy);  // toString()

2.3  Ex: The MyPoint Class


A class called MyPoint, which models a 2D point with x and y coordinates, is designed as shown in the class diagram. It contains:

  • Two instance variables x (int) and y (int).
  • A default (or “no-argument” or “no-arg”) constructor that construct a point at the default location of (0, 0).
  • A overloaded constructor that constructs a point with the given x and y coordinates.
  • Getter and setter for the instance variables x and y.
  • A method setXY() to set both x and y.
  • A method getXY() which returns the x and y in a 2-element int array.
  • A toString() method that returns a string description of the instance in the format “(x, y)“.
  • A method called distance(int x, int y) that returns the distance from this point to another point at the given (x, y) coordinates, e.g.,
    MyPoint p1 = new MyPoint(3, 4);
    System.out.println(p1.distance(5, 6));
  • An overloaded distance(MyPoint another) that returns the distance from this point to the given MyPoint instance (called another), e.g.,
    MyPoint p1 = new MyPoint(3, 4);
    MyPoint p2 = new MyPoint(5, 6);
  • Another overloaded distance() method that returns the distance from this point to the origin (0,0), e.g.,
    MyPoint p1 = new MyPoint(3, 4);

You are required to:

  1. Write the code for the class MyPoint. Also write a test program (called TestMyPoint) to test all the methods defined in the class.

    // Overloading method distance()
    // This version takes two ints as arguments
    public double distance(int x, int y) {
       int xDiff = this.x – x;
       int yDiff = ......
       return Math.sqrt(xDiff*xDiff + yDiff*yDiff);
    // This version takes a MyPoint instance as argument
    public double distance(MyPoint another) {
       int xDiff = this.x – another.x;
    // Test program to test all constructors and public methods
    MyPoint p1 = new MyPoint();  // Test constructor
    System.out.println(p1);      // Test toString()
    p1.setX(8);   // Test setters
    System.out.println("x is: " + p1.getX());  // Test getters
    System.out.println("y is: " + p1.getY());
    p1.setXY(3, 0);   // Test setXY()
    System.out.println(p1.getXY()[0]);  // Test getXY()
    MyPoint p2 = new MyPoint(0, 4);  // Test another constructor
    // Testing the overloaded methods distance()
    System.out.println(p1.distance(p2));    // which version?
    System.out.println(p2.distance(p1));    // which version?
    System.out.println(p1.distance(5, 6));  // which version?
    System.out.println(p1.distance());      // which version?
  2. Write a program that allocates 10 points in an array of MyPoint, and initializes to (1, 1), (2, 2), … (10, 10).
    Hints: You need to allocate the array, as well as each of the 10 MyPoint instances.  In other words, you need to issue 11 new, 1 for the array and 10 for the MyPoint instances.

    MyPoint[] points = new MyPoint[10];  // Declare and allocate an array of MyPoint
    for (int i = 0; i < points.length; i++) {
       points[i] = new MyPoint(...);    // Allocate each of MyPoint instances
    // use a loop to print all the points

Notes: Point is such a common entity that JDK certainly provided for in all flavors.

2.4  Ex: The MyCircle and MyPoint Classes


A class called MyCircle, which models a circle with a center (x,y) and a radius, is designed as shown in the class diagram. The MyCircle class uses an instance of MyPoint class (created in the previous exercise) as its center.

The class contains:

  • Two private instance variables: center (an instance of MyPoint) and radius (int).
  • A constructor that constructs a circle with the given center’s (x, y) and radius.
  • An overloaded constructor that constructs a MyCircle given a MyPoint instance as center, and radius.
  • A default constructor that construct a circle with center at (0,0) and radius of 1.
  • Various getters and setters.
  • A toString() method that returns a string description of this instance in the format “MyCircle[radius=r,center=(x,y)]“. You shall reuse the toString() of MyPoint.
  • getArea() and getCircumference() methods that return the area and circumference of this circle in double.
  • A distance(MyCircle another) method that returns the distance of the centers from this instance and the given MyCircle instance.  You should use MyPoint’s distance() method to compute this distance.

Write the MyCircle class. Also write a test driver (called TestMyCircle) to test all the public methods defined in the class.


// Constructors
public MyCircle(int x, int y, int radius) {
   // Need to construct an instance of MyPoint for the variable center
   center = new MyPoint(x, y);
   this.radius = radius;
public MyCircle(MyPoint center, int radius) {
   // An instance of MyPoint already constructed by caller; simply assign. = center;
public MyCircle() {
   center = new MyPoint(.....);  // construct MyPoint instance
   this.radius = ......

// Returns the x-coordinate of the center of this MyCircle
public int getCenterX() {
   return center.getX();   // cannot use center.x and x is private in MyPoint

// Returns the distance of the center for this MyCircle and another MyCircle
public double distance(MyCircle another) {
   return center.distance(; // use distance() of MyPoint

2.5  Ex: The MyTriangle and MyPoint Classes


A class called MyTriangle, which models a triangle with 3 vertices, is designed as shown. The MyTriangle class uses three MyPoint instances (created in the earlier exercise) as its three vertices.

It contains:

  • Three private instance variables v1, v2, v3 (instances of MyPoint), for the three vertices.
  • A constructor that constructs a MyTriangle with three set of coordinates, v1=(x1, y1), v2=(x2, y2), v3=(x3, y3).
  • An overloaded constructor that constructs a MyTriangle given three instances of MyPoint.
  • A toString() method that returns a string description of the instance in the format “MyTriangle[v1=(x1,y1),v2=(x2,y2),v3=(x3,y3)]“.
  • A getPerimeter() method that returns the length of the perimeter in double. You should use the distance() method of MyPoint to compute the perimeter.
  • A method printType(), which prints “equilateral” if all the three sides are equal, “isosceles” if any two of the three sides are equal, or “scalene” if the three sides are different.

Write the MyTriangle class. Also write a test driver (called TestMyTriangle) to test all the public methods defined in the class.

2.6  Ex: The MyRectangle and MyPoint Classes

Design a MyRectangle class which is composed of two MyPoint instances as its top-left and bottom-right corners. Draw the class diagrams, write the codes, and write the test drivers.

2.7  Ex: The Customer and Invoice classes


The Customer class models a customer is design as shown in the class diagram. Write the codes for the Customer class and a test driver to test all the public methods.


The Invoice class, design as shown in the class diagram, composes a Customer instance (written earlier) as its member. Write the codes for the Invoice class and a test driver to test all the public methods.

2.8  Ex: The Customer and Account classes


The Customer class models a customer is design as shown in the class diagram. Write the codes for the Customer class and a test driver to test all the public methods.


The Account class models a bank account, design as shown in the class diagram, composes a Customer instance (written earlier) as its member. Write the codes for the Account class and a test driver to test all the public methods.

3.  More Exercises on Classes

3.1  Ex: The MyComplex class


A class called MyComplex, which models complex numbers x+yi, is designed as shown in the class diagram. It contains:

  • Two instance variable named real (double) and imag (double) which stores the real and imaginary parts of the complex number, respectively.
  • A constructor that creates a MyComplex instance with the given real and imaginary values.
  • A default constructor that create a MyComplex at 0.0 + 0.0i.
  • Getters and setters for instance variables real and imag.
  • A method setValue() to set the value of the complex number.
  • A toString() that returns “(x + yi)” where x and y are the real and imaginary parts, respectively.
  • Methods isReal() and isImaginary() that returns true if this complex number is real or imaginary, respectively.

    return (imag == 0);
  • A method equals(double real, double imag) that returns true if this complex number is equal to the given complex number (real, imag).

    return (this.real == real && this.imag == imag);
  • An overloaded equals(MyComplex another) that returns true if this complex number is equal to the given MyComplex instance another.

    return (this.real == another.real && this.imag == another.imag);
  • A method magnitude() that returns the magnitude of this complex number.
    magnitude(x+yi) = Math.sqrt(x*x + y*y)
  • Methods argument() that returns the argument of this complex number in radians (double).
    arg(x+yi) = Math.atan2(y, x) (in radians)

    Note: The Math library has two arc-tangent methods, Math.atan(double) and Math.atan2(double, double). We commonly use the Math.atan2(y, x) instead of Math.atan(y/x) to avoid division by zero. Read the documentation of Math class in package java.lang.

  • Methods add(MyComplex right) and subtract(MyComplex right) that adds and subtract the given MyComplex instance (called right), into/from this instance and returns this instance.
    (a + bi) + (c + di) = (a+c) + (b+d)i
    (a + bi) - (c + di) = (a-c) + (b-d)i


    return this;  // return "this" instance
  • Methods addNew(MyComplex right) and subtractNew(MyComplex right) that adds and subtract this instance with the given MyComplex instance called right, and returns a new MyComplex instance containing the result.

    // construct a new instance and return the constructed instance
    return new MyComplex(..., ...);
  • Methods multiply(MyComplex right) and divide(MyComplex right) that multiplies and divides this instance with the given MyComplex instance right, and keeps the result in this instance, and returns this instance.
    (a + bi) * (c + di) = (ac - bd) + (ad + bc)i
    (a + bi) / (c + di) = [(a + bi) * (c – di)] / (c*c + d*d)
  • A method conjugate() that operates on this instance and returns this instance containing the complex conjugate.
    conjugate(x+yi) = x - yi

You are required to:

  1. Write the MyComplex class.
  2. Write a test driver to test all the public methods defined in the class.
  3. Write an application called MyComplexApp that uses the MyComplex class. The application shall prompt the user for two complex numbers, print their values, check for real, imaginary and equality, and carry out all the arithmetic operations.
    Enter complex number 1 (real and imaginary part): 1.1 2.2
    Enter complex number 2 (real and imaginary part): 3.3 4.4
    Number 1 is: (1.1 + 2.2i)
    (1.1 + 2.2i) is NOT a pure real number
    (1.1 + 2.2i) is NOT a pure imaginary number
    Number 2 is: (3.3 + 4.4i)
    (3.3 + 4.4i) is NOT a pure real number
    (3.3 + 4.4i) is NOT a pure imaginary number
    (1.1 + 2.2i) is NOT equal to (3.3 + 4.4i)
    (1.1 + 2.2i) + (3.3 + 4.4i) = (4.4 + 6.6000000000000005i)
    (1.1 + 2.2i) - (3.3 + 4.4i) = (-2.1999999999999997 + -2.2i)

Take note that there are a few flaws in the design of this class, which was introduced solely for teaching purpose:

  • Comparing doubles in equal() using “==” may produce unexpected outcome. For example, (2.2+4.4)==6.6 returns false. It is common to define a small threshold called EPSILON (set to about 10^-8) for comparing floating point numbers.
  • The method addNew(), subtractNew() produce new instances, whereas add(), subtract(), multiply(), divide() and conjugate() modify this instance. There is inconsistency in the design (introduced for teaching purpose).

Also take note that methods such as add() returns an instance of MyComplex. Hence, you can place the result inside a System.out.println() (which implicitly invoke the toString()). You can also chain the operations, e.g., c1.add(c2).add(c3) (same as (c1.add(c2)).add(c3)), or c1.add(c2).subtract(c3).

3.2  Ex: The MyPolynomial Class


A class called MyPolynomial, which models polynomials of degree-n (see equation), is designed as shown in the class diagram.


It contains:

  • An instance variable named coeffs, which stores the coefficients of the n-degree polynomial in a double array of size n+1, where c0 is kept at index 0.
  • A constructor MyPolynomial(coeffs:double...) that takes a variable number of doubles to initialize the coeffs array, where the first argument corresponds to c0.
    The three dots is known as varargs (variable number of arguments), which is a new feature introduced in JDK 1.5. It accepts an array or a sequence of comma-separated arguments. The compiler automatically packs the comma-separated arguments in an array. The three dots can only be used for the last argument of the method.

    public class MyPolynomial {
       private double[] coeffs;
       public MyPolynomial(double... coeffs) {  // varargs
          this.coeffs = coeffs;                 // varargs is treated as array
    // Test program
    // Can invoke with a variable number of arguments
    MyPolynomial p1 = new MyPolynomial(1.1, 2.2, 3.3);
    MyPolynomial p1 = new MyPolynomial(1.1, 2.2, 3.3, 4.4, 5.5);
    // Can also invoke with an array
    Double coeffs = {1.2, 3.4, 5.6, 7.8}
    MyPolynomial p2 = new MyPolynomial(coeffs);
  • A method getDegree() that returns the degree of this polynomial.
  • A method toString() that returns “cnx^n+cn-1x^(n-1)+…+c1x+c0“.
  • A method evaluate(double x) that evaluate the polynomial for the given x, by substituting the given x into the polynomial expression.
  • Methods add() and multiply() that adds and multiplies this polynomial with the given MyPolynomial instance another, and returns this instance that contains the result.

Write the MyPolynomial class. Also write a test driver (called TestMyPolynomial) to test all the public methods defined in the class.

Question: Do you need to keep the degree of the polynomial as an instance variable in the MyPolynomial class in Java? How about C/C++? Why?

3.3  Ex: Using JDK’s BigInteger Class

Recall that primitive integer type byte, short, int and long represent 8-, 16-, 32-, and 64-bit signed integers, respectively. You cannot use them for integers bigger than 64 bits. Java API provides a class called BigInteger in a package called java.math. Study the API of the BigInteger class (Java API ⇒ From “Packages”, choose “java.math” ” From “classes”, choose “BigInteger” ” Study the constructors (choose “CONSTR”) on how to construct a BigInteger instance, and the public methods available (choose “METHOD”). Look for methods for adding and multiplying two BigIntegers.

Write a program called TestBigInteger that:

  1. adds “11111111111111111111111111111111111111111111111111111111111111” to “22222222222222222222222222222222222222222222222222” and prints the result.
  2. multiplies the above two number and prints the result.


import java.math.BigInteger
public class TestBigInteger {
   public static void main(String[] args) {
      BigInteger i1 = new BigInteger(...);
      BigInteger i2 = new BigInteger(...);

3.4  Ex: The MyTime Class


A class called MyTime, which models a time instance, is designed as shown in the class diagram.

It contains the following private instance variables:

  • hour: between 0 to 23.
  • minute: between 0 to 59.
  • Second: between 0 to 59.

You are required to perform input validation.

It contains the following public methods:

  • setTime(int hour, int minute, int second): It shall check if the given hour, minute and second are valid before setting the instance variables.
    (Advanced: Otherwise, it shall throw an IllegalArgumentException with the message “Invalid hour, minute, or second!”.)
  • Setters setHour(int hour), setMinute(int minute), setSecond(int second): It shall check if the parameters are valid, similar to the above.
  • Getters getHour(), getMinute(), getSecond().
  • toString(): returns “HH:MM:SS“.
  • nextSecond(): Update this instance to the next second and return this instance. Take note that the nextSecond() of 23:59:59 is 00:00:00.
  • nextMinute(), nextHour(), previousSecond(), previousMinute(), previousHour(): similar to the above.

Write the code for the MyTime class. Also write a test driver (called TestMyTime) to test all the public methods defined in the MyTime class.

3.5  Ex: The MyDate Class


A class called MyDate, which models a date instance, is defined as shown in the class diagram.

The MyDate class contains the following private instance variables:

  • year (int): Between 1 to 9999.
  • month (int): Between 1 (Jan) to 12 (Dec).
  • day (int): Between 1 to 28|29|30|31, where the last day depends on the month and whether it is a leap year for Feb (28|29).

It also contains the following private static variables (drawn with underlined in the class diagram):

  • strMonths (String[]), strDays (String[]), and dayInMonths (int[]): static variables, initialized as shown, which are used in the methods.

The MyDate class has the following public static methods (drawn with underlined in the class diagram):

  • isLeapYear(int year): returns true if the given year is a leap year. A year is a leap year if it is divisible by 4 but not by 100, or it is divisible by 400.
  • isValidDate(int year, int month, int day): returns true if the given year, month, and day constitute a valid date. Assume that year is between 1 and 9999, month is between 1 (Jan) to 12 (Dec) and day shall be between 1 and 28|29|30|31 depending on the month and whether it is a leap year on Feb.
  • getDayOfWeek(int year, int month, int day): returns the day of the week, where 0 for Sun, 1 for Mon, …, 6 for Sat, for the given date. Assume that the date is valid. Read the earlier exercise on how to determine the day of the week (or Wiki “Determination of the day of the week”).

The MyDate class has one constructor, which takes 3 parameters: year, month and day. It shall invoke setDate() method (to be described later) to set the instance variables.

The MyDate class has the following public methods:

  • setDate(int year, int month, int day): It shall invoke the static method isValidDate() to verify that the given year, month and day constitute a valid date.
    (Advanced: Otherwise, it shall throw an IllegalArgumentException with the message “Invalid year, month, or day!”.)
  • setYear(int year): It shall verify that the given year is between 1 and 9999.
    (Advanced: Otherwise, it shall throw an IllegalArgumentException with the message “Invalid year!”.)
  • setMonth(int month): It shall verify that the given month is between 1 and 12.
    (Advanced: Otherwise, it shall throw an IllegalArgumentException with the message “Invalid month!”.)
  • setDay(int day): It shall verify that the given day is between 1 and dayMax, where dayMax depends on the month and whether it is a leap year for Feb.
    (Advanced: Otherwise, it shall throw an IllegalArgumentException with the message “Invalid month!”.)
  • getYear(), getMonth(), getDay(): return the value for the year, month and day, respectively.
  • toString(): returns a date string in the format “xxxday d mmm yyyy“, e.g., “Tuesday 14 Feb 2012”.
  • nextDay(): update this instance to the next day and return this instance. Take note that nextDay() for 31 Dec 2000 shall be 1 Jan 2001.
  • nextMonth(): update this instance to the next month and return this instance. Take note that nextMonth() for 31 Oct 2012 shall be 30 Nov 2012.
  • nextYear(): update this instance to the next year and return this instance. Take note that nextYear() for 29 Feb 2012 shall be 28 Feb 2013.
    (Advanced: throw an IllegalStateException with the message “Year out of range!” if year > 9999.)
  • previousDay(), previousMonth(), previousYear(): similar to the above.

Write the code for the MyDate class.

Use the following test statements to test the MyDate class:

MyDate d1 = new MyDate(2012, 2, 28);
System.out.println(d1);             // Tuesday 28 Feb 2012
System.out.println(d1.nextDay());   // Wednesday 29 Feb 2012
System.out.println(d1.nextDay());   // Thursday 1 Mar 2012
System.out.println(d1.nextMonth()); // Sunday 1 Apr 2012
System.out.println(d1.nextYear());  // Monday 1 Apr 2013

MyDate d2 = new MyDate(2012, 1, 2);
System.out.println(d2);                 // Monday 2 Jan 2012
System.out.println(d2.previousDay());   // Sunday 1 Jan 2012
System.out.println(d2.previousDay());   // Saturday 31 Dec 2011
System.out.println(d2.previousMonth()); // Wednesday 30 Nov 2011
System.out.println(d2.previousYear());  // Tuesday 30 Nov 2010

MyDate d3 = new MyDate(2012, 2, 29);
System.out.println(d3.previousYear());  // Monday 28 Feb 2011

// MyDate d4 = new MyDate(2099, 11, 31); // Invalid year, month, or day!
// MyDate d5 = new MyDate(2011, 2, 29);  // Invalid year, month, or day!

Write a test program that tests the nextDay() in a loop, by printing the dates from 28 Dec 2011 to 2 Mar 2012.

3.6  Ex: Bouncing Balls – Ball and Container Classes


A class called Ball is designed as shown in the class diagram.

The Ball class contains the following private instance variables:

  • x, y and radius, which represent the ball’s center (x, y) co-ordinates and the radius, respectively.
  • xDelta (Δx) and yDelta (Δy), which represent the displacement (movement) per step, in the x and y direction respectively.

The Ball class contains the following public methods:

  • A constructor which accepts x, y, radius, speed, and direction as arguments. For user friendliness, user specifies speed (in pixels per step) and direction (in degrees in the range of (-180°, 180°]). For the internal operations, the speed and direction are to be converted to (Δx, Δy) in the internal representation. Note that the y-axis of the Java graphics coordinate system is inverted, i.e., the origin (0, 0) is located at the top-left corner.

    Δx = d × cos(θ)
    Δy = -d × sin(θ)
  • Getter and setter for all the instance variables.
  • A method move() which move the ball by one step.
    x += Δx
    y += Δy
  • reflectHorizontal() which reflects the ball horizontally (i.e., hitting a vertical wall)
    Δx = -Δx
    Δy no changes
  • reflectVertical() (the ball hits a horizontal wall).
    Δx no changes
    Δy = -Δy
  • toString() which prints the message “Ball at (x, y) of velocity (Δx, Δy)“.

Write the Ball class. Also write a test program to test all the methods defined in the class.

A class called Container, which represents the enclosing box for the ball, is designed as shown in the class diagram. It contains:

  • Instance variables (x1, y1) and (x2, y2) which denote the top-left and bottom-right corners of the rectangular box.
  • A constructor which accepts (x, y) of the top-left corner, width and height as argument, and converts them into the internal representation (i.e., x2=x1+width-1). Width and height is used in the argument for safer operation (there is no need to check the validity of x2>x1 etc.).
  • A toString() method that returns “Container at (x1,y1) to (x2, y2)“.
  • A boolean method called collidesWith(Ball), which check if the given Ball is outside the bounds of the container box. If so, it invokes the Ball‘s reflectHorizontal() and/or reflectVertical() to change the movement direction of the ball, and returns true.
    public boolean collidesWith(Ball ball) {
       if (ball.getX() - ball.getRadius() <= this.x1 ||
           ball.getX() - ball.getRadius() >= this.x2) {
          return true;

Use the following statements to test your program:

Ball ball = new Ball(50, 50, 5, 10, 30);
Container box = new Container(0, 0, 100, 100);
for (int step = 0; step < 100; ++step) {
   System.out.println(ball); // manual check the position of the ball

3.7  Ex: The Ball and Player Classes


The Ball class, which models the ball in a soccer game, is designed as shown in the class diagram. Write the codes for the Ball class and a test driver to test all the public methods.


The Player class, which models the players in a soccer game, is designed as shown in the class diagram. The Player interacts with the Ball (written earlier). Write the codes for the Player class and a test driver to test all the public methods. Make your assumption for the kick().

Can you write a very simple soccer game with 2 teams of players and a ball, inside a soccer field?

4.  Exercises on Inheritance

4.1  Ex: The Circle and Cylinder Classes

This exercise shall guide you through the important concepts in inheritance.


In this exercise, a subclass called Cylinder is derived from the superclass Circle as shown in the class diagram (where an an arrow pointing up from the subclass to its superclass). Study how the subclass Cylinder invokes the superclass’ constructors (via super() and super(radius)) and inherits the variables and methods from the superclass Circle.

You can reuse the Circle class that you have created in the previous exercise. Make sure that you keep “Circle.class” in the same directory.

public class Cylinder extends Circle {  // Save as ""
   private double height;  // private variable
   // Constructor with default color, radius and height
   public Cylinder() {
      super();        // call superclass no-arg constructor Circle()
      height = 1.0; 
   // Constructor with default radius, color but given height
   public Cylinder(double height) {
      super();        // call superclass no-arg constructor Circle()
      this.height = height;
   // Constructor with default color, but given radius, height
   public Cylinder(double radius, double height) {
      super(radius);  // call superclass constructor Circle(r)
      this.height = height;
   // A public method for retrieving the height
   public double getHeight() {
      return height; 
   // A public method for computing the volume of cylinder
   //  use superclass method getArea() to get the base area
   public double getVolume() {
      return getArea()*height; 

Write a test program (says TestCylinder) to test the Cylinder class created, as follow:

public class TestCylinder {  // save as ""
   public static void main (String[] args) {
      // Declare and allocate a new instance of cylinder
      //   with default color, radius, and height
      Cylinder c1 = new Cylinder();
            + " radius=" + c1.getRadius()
            + " height=" + c1.getHeight()
            + " base area=" + c1.getArea()
            + " volume=" + c1.getVolume());
      // Declare and allocate a new instance of cylinder
      //   specifying height, with default color and radius
      Cylinder c2 = new Cylinder(10.0);
            + " radius=" + c2.getRadius()
            + " height=" + c2.getHeight()
            + " base area=" + c2.getArea()
            + " volume=" + c2.getVolume());
      // Declare and allocate a new instance of cylinder
      //   specifying radius and height, with default color
      Cylinder c3 = new Cylinder(2.0, 10.0);
            + " radius=" + c3.getRadius()
            + " height=" + c3.getHeight()
            + " base area=" + c3.getArea()
            + " volume=" + c3.getVolume());

Method Overriding and “Super”: The subclass Cylinder inherits getArea() method from its superclass Circle. Try overriding the getArea() method in the subclass Cylinder to compute the surface area (=2π×radius×height + 2×base-area) of the cylinder instead of base area. That is, if getArea() is called by a Circle instance, it returns the area. If getArea() is called by a Cylinder instance, it returns the surface area of the cylinder.

If you override the getArea() in the subclass Cylinder, the getVolume() no longer works. This is because the getVolume() uses the overridden getArea() method found in the same class. (Java runtime will search the superclass only if it cannot locate the method in this class). Fix the getVolume().

Hints: After overridding the getArea() in subclass Cylinder, you can choose to invoke the getArea() of the superclass Circle by calling super.getArea().


Provide a toString() method to the Cylinder class, which overrides the toString() inherited from the superclass Circle, e.g.,

public String toString() {      // in Cylinder class
   return "Cylinder: subclass of " + super.toString()  // use Circle's toString()
          + " height=" + height;

Try out the toString() method in TestCylinder.

Note: @Override is known as annotation (introduced in JDK 1.5), which asks compiler to check whether there is such a method in the superclass to be overridden. This helps greatly if you misspell the name of the toString(). If @Override is not used and toString() is misspelled as ToString(), it will be treated as a new method in the subclass, instead of overriding the superclass. If @Override is used, the compiler will signal an error. @Override annotation is optional, but certainly nice to have.

4.2  Ex: Superclass Person and its subclasses


4.3  Ex: Point2D and Point3D


4.4  Ex: Point and MovablePoint


4.5  Ex: Superclass Shape and its subclasses Circle, Rectangle and Square


Write a superclass called Shape (as shown in the class diagram), which contains:

  • Two instance variables color (String) and filled (boolean).
  • Two constructors: a no-arg (no-argument) constructor that initializes the color to “green” and filled to true, and a constructor that initializes the color and filled to the given values.
  • Getter and setter for all the instance variables. By convention, the getter for a boolean variable xxx is called isXXX() (instead of getXxx() for all the other types).
  • A toString() method that returns “A Shape with color of xxx and filled/Not filled“.

Write a test program to test all the methods defined in Shape.

Write two subclasses of Shape called Circle and Rectangle, as shown in the class diagram.

The Circle class contains:

  • An instance variable radius (double).
  • Three constructors as shown. The no-arg constructor initializes the radius to 1.0.
  • Getter and setter for the instance variable radius.
  • Methods getArea() and getPerimeter().
  • Override the toString() method inherited, to return “A Circle with radius=xxx, which is a subclass of yyy“, where yyy is the output of the toString() method from the superclass.

The Rectangle class contains:

  • Two instance variables width (double) and length (double).
  • Three constructors as shown. The no-arg constructor initializes the width and length to 1.0.
  • Getter and setter for all the instance variables.
  • Methods getArea() and getPerimeter().
  • Override the toString() method inherited, to return “A Rectangle with width=xxx and length=zzz, which is a subclass of yyy“, where yyy is the output of the toString() method from the superclass.

Write a class called Square, as a subclass of Rectangle. Convince yourself that Square can be modeled as a subclass of Rectangle. Square has no instance variable, but inherits the instance variables width and length from its superclass Rectangle.

  • Provide the appropriate constructors (as shown in the class diagram). Hint:
    public Square(double side) {
       super(side, side);  // Call superclass Rectangle(double, double)
  • Override the toString() method to return “A Square with side=xxx, which is a subclass of yyy“, where yyy is the output of the toString() method from the superclass.
  • Do you need to override the getArea() and getPerimeter()? Try them out.
  • Override the setLength() and setWidth() to change both the width and length, so as to maintain the square geometry.

5.  Exercises on Composition vs Inheritance

They are two ways to reuse a class in your applications: composition and inheritance.

5.1  Ex: The Point and Line Classes

Let us begin with composition with the statement “a line composes of two points”.

Complete the definition of the following two classes: Point and Line. The class Line composes 2 instances of class Point, representing the beginning and ending points of the line. Also write test classes for Point and Line (says TestPoint and TestLine).

public class Point {
   // Private variables
   private int x;    // x co-ordinate
   private int y;    // y co-ordinate
   // Constructor
   public Point (int x, int y) {......}
   // Public methods
   public String toString() {
      return "Point: (" + x + "," + y + ")";
   public int getX() {......}
   public int getY() {......}
   public void setX(int x) {......}
   public void setY(int y) {......}
   public void setXY(int x, int y) {......}
public class TestPoint {
   public static void main(String[] args) {
      Point p1 = new Point(10, 20);   // Construct a Point
      // Try setting p1 to (100, 10).
public class Line {
   // A line composes of two points (as instance variables)
   private Point begin;    // beginning point
   private Point end;      // ending point
   // Constructors
   public Line (Point begin, Point end) {  // caller to construct the Points
      this.begin = begin;
   public Line (int beginX, int beginY, int endX, int endY) {
      begin = new Point(beginX, beginY);   // construct the Points here
   // Public methods
   public String toString() { ...... }
   public Point getBegin() { ...... }
   public Point getEnd() { ...... }
   public void setBegin(......) { ...... }
   public void setEnd(......) { ...... }
   public int getBeginX() { ...... }
   public int getBeginY() { ...... }
   public int getEndX() { ...... }
   public int getEndY() { ...... }
   public void setBeginX(......) { ...... }
   public void setBeginY(......) { ...... }
   public void setBeginXY(......) { ...... }
   public void setEndX(......) { ...... }
   public void setEndY(......) { ...... }
   public void setEndXY(......) { ...... }
   public int getLength() { ...... } // Length of the line
                                     // Math.sqrt(xDiff*xDiff + yDiff*yDiff)
   public double getGradient() { ...... } // Gradient in radians
                                          // Math.atan2(yDiff, xDiff)
public class TestLine {
   public static void main(String[] args) {
      Line l1 = new Line(0, 0, 3, 4);
      Point p1 = new Point(...);
      Point p2 = new Point(...);
      Line l2 = new Line(p1, p2);

The class diagram for composition is as follows (where a diamond-hollow-head arrow pointing to its constituents):


Instead of composition, we can design a Line class using inheritance. Instead of “a line composes of two points”, we can say that “a line is a point extended by another point”, as shown in the following class diagram:


Let’s re-design the Line class (called LineSub) as a subclass of class Point. LineSub inherits the starting point from its superclass Point, and adds an ending point. Complete the class definition. Write a testing class called TestLineSub to test LineSub.

public class LineSub extends Point {
   // A line needs two points: begin and end.
   // The begin point is inherited from its superclass Point.
   // Private variables
   Point end;               // Ending point
   // Constructors
   public LineSub (int beginX, int beginY, int endX, int endY) {
      super(beginX, beginY);             // construct the begin Point
      this.end = new Point(endX, endY);  // construct the end Point
   public LineSub (Point begin, Point end) {  // caller to construct the Points
      super(begin.getX(), begin.getY());      // need to reconstruct the begin Point
      this.end = end;
   // Public methods
   // Inherits methods getX() and getY() from superclass Point
   public String toString() { ... }
   public Point getBegin() { ... }
   public Point getEnd() { ... }
   public void setBegin(...) { ... }
   public void setEnd(...) { ... }
   public int getBeginX() { ... }
   public int getBeginY() { ... }
   public int getEndX() { ... }
   public int getEndY() { ... }
   public void setBeginX(...) { ... }
   public void setBeginY(...) { ... }
   public void setBeginXY(...) { ... }
   public void setEndX(...) { ... }
   public void setEndY(...) { ... }
   public void setEndXY(...) { ... }
   public int getLength() { ... }       // Length of the line
   public double getGradient() { ... }  // Gradient in radians

Summary: There are two approaches that you can design a line, composition or inheritance. “A line composes two points” or “A line is a point extended with another point””. Compare the Line and LineSub designs: Line uses composition and LineSub uses inheritance. Which design is better?

5.2  Ex: The Circle and Cylinder Classes Using Composition


Try rewriting the Circle-Cylinder of the previous exercise using composition (as shown in the class diagram) instead of inheritance. That is, “a cylinder is composed of a base circle and a height”.

public class Cylinder {
   private Circle base;   // Base circle, an instance of Circle class
   private double height;
   // Constructor with default color, radius and height
   public Cylinder() {
      base = new Circle(); // Call the constructor to construct the Circle
      height = 1.0; 

Which design (inheritance or composition) is better?

6.  Exercises on Polymorphism, Abstract Classes and Interfaces

6.1  Ex: Abstract Superclass Shape and Its Concrete Subclasses

Rewrite the superclass Shape and its subclasses Circle, Rectangle and Square, as shown in the class diagram.


In this exercise, Shape shall be defined as an abstract class, which contains:

  • Two protected instance variables color(String) and filled(boolean). The protected variables can be accessed by its subclasses and classes in the same package. They are denoted with a '#' sign in the class diagram.
  • Getter and setter for all the instance variables, and toString().
  • Two abstract methods getArea() and getPerimeter() (shown in italics in the class diagram).

The subclasses Circle and Rectangle shall override the abstract methods getArea() and getPerimeter() and provide the proper implementation. They also override the toString().

Write a test class to test these statements involving polymorphism and explain the outputs. Some statements may trigger compilation errors. Explain the errors, if any.

Shape s1 = new Circle(5.5, "RED", false);  // Upcast Circle to Shape
System.out.println(s1);                    // which version? System.out.println(s1.getArea()); // which version? System.out.println(s1.getPerimeter()); // which version? System.out.println(s1.getColor()); System.out.println(s1.isFilled()); System.out.println(s1.getRadius()); Circle c1 = (Circle)s1; // Downcast back to Circle System.out.println(c1); System.out.println(c1.getArea()); System.out.println(c1.getPerimeter()); System.out.println(c1.getColor()); System.out.println(c1.isFilled()); System.out.println(c1.getRadius()); Shape s2 = new Shape(); Shape s3 = new Rectangle(1.0, 2.0, "RED", false); // Upcast System.out.println(s3); System.out.println(s3.getArea()); System.out.println(s3.getPerimeter()); System.out.println(s3.getColor()); System.out.println(s3.getLength()); Rectangle r1 = (Rectangle)s3; // downcast System.out.println(r1); System.out.println(r1.getArea()); System.out.println(r1.getColor()); System.out.println(r1.getLength()); Shape s4 = new Square(6.6); // Upcast System.out.println(s4); System.out.println(s4.getArea()); System.out.println(s4.getColor()); System.out.println(s4.getSide()); // Take note that we downcast Shape s4 to Rectangle, // which is a superclass of Square, instead of Square Rectangle r2 = (Rectangle)s4; System.out.println(r2); System.out.println(r2.getArea()); System.out.println(r2.getColor()); System.out.println(r2.getSide()); System.out.println(r2.getLength()); // Downcast Rectangle r2 to Square Square sq1 = (Square)r2; System.out.println(sq1); System.out.println(sq1.getArea()); System.out.println(sq1.getColor()); System.out.println(sq1.getSide()); System.out.println(sq1.getLength());

What is the usage of the abstract method and abstract class?

6.2  Ex: Polymorphism

Examine the following codes and draw the class diagram.

abstract public class Animal {
   abstract public void greeting();
public class Cat extends Animal {
   public void greeting() {
public class Dog extends Animal {
   public void greeting() {
   public void greeting(Dog another) {
public class BigDog extends Dog {
   public void greeting() {
   public void greeting(Dog another) {

Explain the outputs (or error) for the following test program.

public class TestAnimal {
   public static void main(String[] args) {
      // Using the subclasses
      Cat cat1 = new Cat();
      Dog dog1 = new Dog();
      BigDog bigDog1 = new BigDog();
      // Using Polymorphism
      Animal animal1 = new Cat();
      Animal animal2 = new Dog();
      Animal animal3 = new BigDog();
      Animal animal4 = new Animal();
      // Downcast
      Dog dog2 = (Dog)animal2;
      BigDog bigDog2 = (BigDog)animal3;
      Dog dog3 = (Dog)animal3;
      Cat cat2 = (Cat)animal2;

6.3  Ex: Interface Movable and its implementations MovablePoint and MovableCircle

Suppose that we have a set of objects with some common behaviors: they could move up, down, left or right. The exact behaviors (such as how to move and how far to move) depend on the objects themselves. One common way to model these common behaviors is to define an interface called Movable, with abstract methods moveUp(), moveDown(), moveLeft() and moveRight(). The classes that implement the Movable interface will provide actual implementation to these abstract methods.

Let’s write two concrete classes – MovablePoint and MovableCircle – that implement the Movable interface.


The code for the interface Movable is straight forward.

public interface Movable {  // saved as ""
   public void moveUp();

For the MovablePoint class, declare the instance variable x, y, xSpeed and ySpeed with package access as shown with '~' in the class diagram (i.e., classes in the same package can access these variables directly). For the MovableCircle class, use a MovablePoint to represent its center (which contains four variable x, y, xSpeed and ySpeed). In other words, the MovableCircle composes a MovablePoint, and its radius.

public class MovablePoint implements Movable { // saved as ""
   // instance variables
   int x, y, xSpeed, ySpeed;     // package access
   // Constructor
   public MovablePoint(int x, int y, int xSpeed, int ySpeed) {
      this.x = x;
   // Implement abstract methods declared in the interface Movable
   public void moveUp() {
      y -= ySpeed;   // y-axis pointing down for 2D graphics
public class MovableCircle implements Movable { // saved as ""
   // instance variables
   private MovablePoint center;   // can use center.x, center.y directly
                                  //  because they are package accessible
   private int radius;
   // Constructor
   public MovableCircle(int x, int y, int xSpeed, int ySpeed, int radius) {
      // Call the MovablePoint's constructor to allocate the center instance.
      center = new MovablePoint(x, y, xSpeed, ySpeed);
   // Implement abstract methods declared in the interface Movable
   public void moveUp() {
      center.y -= center.ySpeed;

Write a test program and try out these statements:

Movable m1 = new MovablePoint(5, 6, 10, 15);     // upcast
Movable m2 = new MovableCircle(1, 2, 3, 4, 20);  // upcast

Write a new class called MovableRectangle, which composes two MovablePoints (representing the top-left and bottom-right corners) and implementing the Movable Interface. Make sure that the two points has the same speed.


What is the difference between an interface and an abstract class?

6.4  Ex: Interfaces GeometricObject and Resizable


  1. Write the interface called GeometricObject, which declares two abstract methods: getParameter() and getArea(), as specified in the class diagram.

    public interface GeometricObject {
       public double getPerimeter();
  2. Write the implementation class Circle, with a protected variable radius, which implements the interface GeometricObject.

    public class Circle implements GeometricObject {
       // Private variable
       // Constructor
       // Implement methods defined in the interface GeometricObject
       public double getPerimeter() { ...... }
  3. Write a test program called TestCircle to test the methods defined in Circle.
  4. The class ResizableCircle is defined as a subclass of the class Circle, which also implements an interface called Resizable, as shown in class diagram. The interface Resizable declares an abstract method resize(), which modifies the dimension (such as radius) by the given percentage. Write the interface Resizable and the class ResizableCircle.

    public interface Resizable { public double resize(...); }
    public class ResizableCircle extends Circle implements Resizeable { // Constructor public ResizableCircle(double radius) { super(...); } // Implement methods defined in the interface Resizable @Override public double resize(int percent) { ...... } }
  5. Write a test program called TestResizableCircle to test the methods defined in ResizableCircle.

7.  More Exercises on OOP

7.1  Ex: The Discount System

You are asked to write a discount system for a beauty saloon, which provides services and sells beauty products. It offers 3 types of memberships: Premium, Gold and Silver. Premium, gold and silver members receive a discount of 20%, 15%, and 10%, respectively, for all services provided. Customers without membership receive no discount. All members receives a flat 10% discount on products purchased (this might change in future). Your system shall consist of three classes: Customer, Discount and Visit, as shown in the class diagram. It shall compute the total bill if a customer purchases $x of products and $y of services, for a visit. Also write a test program to exercise all the classes.


The class DiscountRate contains only static variables and methods (underlined in the class diagram).

7.2  Ex: Polyline of Points with ArrayList


A polyline is a line with segments formed by points. Let’s use the ArrayList (dynamically allocated array) to keep the points, but upcast to List in the instance variable. (Take note that array is of fixed-length, and you need to set the initial length).

public class Point {
   private int x;
   private int y;
   public Point(int x, int y) { ...... }
   public int getX() { ...... }
   public int getY() { ...... }
   public void setX(int x) { ...... }
   public void setY(int y) { ...... }
   public int[] getXY() { ...... }
   public void setXY(int x, int y) { ...... }
   public String toString() { ...... }
   public double distance(Point another) { ...... }
import java.util.*;
public class PolyLine {
   private List<Point> points;   // List of Point instances

   // Constructors   
   public PolyLine() {  // default constructor
      points = new ArrayList<Point>();  // implement with ArrayList
   public PolyLine(List<Point> points) {
      this.points = points;
   // Append a point (x, y) to the end of this polyline
   public void appendPoint(int x, int y) {
      Point newPoint = new Point(x, y);
   // Append a point instance to the end of this polyline
   public void appendPoint(Point point) {
   // Return {(x1,y1)(x2,y2)(x3,y3)....}
   public String toString() {
      // Use a StringBuilder to efficiently build the return String
      StringBuilder sb = new StringBuilder("{");
      for (Point aPoint : points) {
      return sb.toString();

   // Return the total length of this polyline
   public double getLength() { ...... }
 * A Test Driver for the PolyLine class.
import java.util.*;
public class TestPolyLine {
   public static void main(String[] args) {
      // Test default constructor and toString()
      PolyLine l1 = new PolyLine();
      System.out.println(l1);  // {}

      // Test appendPoint()
      l1.appendPoint(new Point(1, 2));
      l1.appendPoint(3, 4);
      l1.appendPoint(5, 6);
      System.out.println(l1);  // {(1,2)(3,4)(5,6)}

      // Test constructor 2
      List<Point> points = new ArrayList<Point>();
      points.add(new Point(11, 12));
      points.add(new Point(13, 14));
      PolyLine l2 = new PolyLine(points);
      System.out.println(l2);  // {(11,12)(13,14)}

8.  Exercises on Data Structures

8.1  Ex: MyIntStack

A stack is a first-in-last-out queue. Write a program called MyIntStack, which uses an array to store the contents, restricted to int.

Write a test program.

public class MyIntStack {
   private int[] contents;
   private int tos;  // Top of the stack
   // constructors
   public MyIntStack(int capacity) {
      contents = new int[capacity];
      tos = -1;
   public void push(int element) {
      contents[++tos] = element;
   public int pop() {
      return contents[tos--];
   public int peek() {
      return contents[tos];
   public boolean isEmpty() {
      return tos < 0;
   public boolean isFull() {
      return tos == contents.length - 1;


  1. Modify the push() method to throw an IllegalStateException if the stack is full.
  2. Modify the push() to return true if the operation is successful, or false otherwise.
  3. Modify the push() to increase the capacity by reallocating another array, if the stack is full.

Exercise (Nodes, Link Lists, Trees, Graphs):


  • Study the existing open source codes, including JDK.
  • Specialized algorithms, such as shortest path.


Exercise (Maps):


  • Representation of map data.
  • Specialized algorithms, such as shortest path.


Exercise (Matrix Operations for 3D Graphics):


  • Study the existing open source codes, including JDK’s 2D Graphics and JOGL’s 3D Graphics.
  • Efficient and specialized codes for 3D Graphics (4D matrices). Handle various primitive types such as int, float and double efficiently.
Posted in Business Metrics, Business Model, Java, Knowledge | Leave a comment

Đề thi Phân tích và thiết kế hệ thống thông tin

Quản lý thu tiền điện tại một chi nhánh X

Mỗi hộ dân trong địa bàn thuộc chi nhánh điện X quản lý muốn sử dụng điện đều phải đăng ký hợp đồng sử dụng điện với sở điện lưc.

Nội dung bản hợp đồng gồm: Số hợp đồng, tên chủ hợp đồng, địa chỉ nhà, hình thức sử dụng điện (sản xuất hay sinh hoạt)

Trong phụ lục hợp đồng ghi rõ định mức tiền điện:

  • Điện sản xuất 1200đ/phút
  • Điện sinh hoạt:
    • 1-> 70         400đ/phút
    • 71 -> 99       600đ/phút
    • 100 trở lên      1000đ/phút

Sở điện lực sẽ thông báo cho chi nhánh X tiến hành lắp công tơ điện. Mỗi hộ có thể lắp loại công tơ khác nhau, có hệ số nhân khác nhau.

Mỗi công tơ có số hiệu riêng biệt

Cuối tháng nhân viên điện lực sẽ đi ghi lại số công tơ điện vào sổ ghi công tơ. Mỗi dòng có cấu trúc như sau: Số hiệu công tơ, loại công tơ, chỉ số điện.

Căn cứ vào số liệu trên chi nhánh X lập hoá đơn thu tiền điện, trong đó ghi rõ: Chỉ số công tơ tháng trước chỉ số tháng này, điện năng tiêu thụ (= chỉ số tháng này – chỉ số tháng trước nhân với hệ số của công tơ.), tổng số tiền phải nộp.

Đầu tháng tiếp nhân viên thu tiền điện căn cứ vào hoá đơn đi thu tiền điện từng hộ. Với mỗi hộ chỉ thu 1 lần: hoặc trả hết hoặc không.

Giữa tháng chi nhánh điện X phải lập các báo cáo về tình hình sử dụng điện tại địa bàn mình: Tổng số điện tiêu thụ theo từng mục đích sử dụng, danh sách các hộ còn nợ, số tiền chưa thu được.


Yêu cầu:

  • Phân tích CN hệ thống, xây dựng biểu đồ phân cấp chức năng.
  • Xây dựng biểu đồ luồng dữ liệu khái niệm (logic) mức đỉnh, mô tả đầy đủ các chức năng của hệ thống.
  • Xây dựng lược đồ quan hệ
Posted in Business Metrics, Business Model, Software architecture, Technology | Leave a comment

A Comparison of the Top Four Enterprise-Architecture Methodologies

Nguồn Microsoft

A Comparison of the Top Four Enterprise-Architecture Methodologies

Roger Sessions
ObjectWatch, Inc.

May 2007

Applies to:
Enterprise Architecture

Summary: Twenty years ago, a new field was born that soon came to be known as enterprise architecture. This paper covers a broad introduction to the field of enterprise architecture. Although the history of the field goes back 20 years, the field is still evolving—and rapidly so. (36 printed pages)


Executive Summary
A Brief History of Enterprise Architecture
Case Study
The Zachman Framework for Enterprise Architectures
The Open Group Architecture Framework (TOGAF)
Federal Enterprise Architecture (FEA)

Executive Summary

Twenty years ago, a new field was born that soon came to be known as enterprise architecture. The field initially began to address two problems:

  • System complexity—Organizations were spending more and more money building IT systems; and
  • Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need.

The bottom line: more cost, less value. These problems, first recognized 20 years ago, have today reached a crisis point. The cost and complexity of IT systems have exponentially increased, while the chances of deriving real value from those systems have dramatically decreased.

Today’s bottom line: even more cost, even less value. Large organizations can no longer afford to ignore these problems. The field of enterprise architecture that 20 years ago seemed quaintly quixotic today seems powerfully prophetic.

Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:

  • The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy
  • The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process
  • The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture
  • The Gartner Methodology—Can be best described as an enterprise architectural practice

This white paper discusses these four approaches to enterprise architecture. It does so within the context of a fictional company that is facing some very nonfictional operations problems. These problems include:

  • IT systems that have become unmanageably complex and increasingly costly to maintain.
  • IT systems that are hindering the organization’s ability to respond to current, and future, market conditions in a timely and cost-effective manner.
  • Mission-critical information that is consistently out-of-date and/or just plain wrong.
  • A culture of distrust between the business and technology sides of the organization.

How should this company choose from among these four very different approaches to enterprise architecture? This white paper traces the journey the company is likely to face in using any one of these methodologies.

When examining each of these methodologies in depth, one is struck by the fact that none of these approaches is really complete. Each has strengths in some areas and weaknesses in others.

For many enterprises, none of these methodologies will therefore be a complete solution. For such organizations, this white paper proposes another approach, one that might be called a blended methodology. Choose bits and pieces from each of these methodologies, and modify and merge them according to the specific needs of your organization. This white paper gives an approach to creating such a blended methodology that is a best fit for your organization’s needs.

But even a blended methodology will only be as good as an organization’s commitment to making changes. This commitment must be driven by the highest level of the organization. The good news is that, with a real commitment to change and a tailored methodology for guiding that change, the 20-year-old promise of enterprise architecture is within reach.

That promise hasn’t changed: reducing IT cost and complexity, while increasing business value and effectiveness—or, to put it even more simply, improving your competitiveness in an increasingly competitive world.


The year 2007 marks the 20-year anniversary of enterprise architecture. In that time, a number of enterprise-architectural methodologies have come and gone. Today, four dominate the field: the Zachman Framework for Enterprise Architectures, The Open Group Architecture Framework (TOGAF), the Federal Enterprise Architecture (FEA), and Gartner (formerly, the Meta Framework).

Should you care about a field that is 20 years old? It depends. This field was inaugurated to address two major problems in information technology (IT) that were then already becoming apparent. The first problem was managing the increasing complexity of information-technology systems. The second problem was the increasing difficulty in delivering real business value with those systems.

As you can imagine, these problems are related. The more complex a system, the less likely it is that it will deliver maximum business value. As you better manage complexity, you improve your chances of delivering real business value.

So, should you care about this field? It depends on how you feel about positively affecting your organization’s bottom line. If managing system complexity and delivering business value are key priorities for you, you should care about enterprise-architecture methodologies. If you are focused on maintaining, or rebuilding, IT’s credibility in your organization, or if you strive to promote the use of IT to maintain a competitive position in your industry, you should continue reading this white paper. If these issues don’t concern you, these methodologies have little to offer.

As systems become more complex, they generally require more planning. It is easy to see this in buildings. When Henry David Thoreau built his little cabin on Walden Pond (shown in Figure 1), he embraced simplicity and needed no architects. If you are building New York City (shown in Figure 2), simplicity is out of the question, and you will need many architects.


Figure 1. Thoreau’s cabin at Walden Pond, as drawn by Thoreau’s sister, Sophia Thoreau


Figure 2. New York City

The relationship between complexity and planning for buildings and cities is similar for information systems. If you are building a simple, single-user, nondistributed system, you might need no architects at all. If you are building an enterprise-wide, mission critical, highly distributed system, you might need a database architect, a solutions architect, an infrastructure architect, a business architect, and an enterprise architect.

This paper is about the methodologies needed to develop the overall architectural vision for an organization. This is the responsibility of the enterprise architect. This is the architect who specializes in the broadest possible view of architecture within the enterprise. This is the architect’s architect, the architect who is responsible for coordinating the work of all of the other architects. Do you need such an architect? It all depends on what you are building: Thoreau’s cabin or New York City.

Building a large, complex, enterprise-wide information system without an enterprise architect is like trying to build a city without a city planner. Can you build a city without a city planner? Probably. Would you want to live in such a city? Probably not.

Of course, hiring a city planner does not guarantee a livable city; it merely improves your chances. Similarly, having an enterprise architect does not guarantee a successful enterprise architecture. There are many examples of failed enterprise architectures in the world today, and all of them had enterprise architects (probably dozens!). Architectural methodologies can help, but they go only so far. I’ll discuss some of the reasons for these failures, and how to avoid them, also in this paper.

Before I get too far into comparing the methodologies that make up the enterprise architect’s toolkit, I need to define some terms. This is especially important in an article that is comparing methodologies, because the different methodologies sometimes use similar terms to mean different things.

For example, we have two methodologies that describe themselves as enterprise-architectural frameworks: the Zachman Framework for Enterprise Architectures and The Open Group Architectural Framework (TOGAF). Yet these two methodologies share little in common other than the words enterprise, architecture, and framework.

So, I will start by defining the terms as I will use them in this white paper. Those definitions marked with an asterisk (*) are taken mostly from IEEE-1471-2000 [01], whose definitions I use where they exist and make sense.

architect—One whose responsibility is the design of an architecture and the creation of an architectural description

architectural artifact—A specific document, report, analysis, model, or other tangible that contributes to an architectural description

architectural description*—A collection of products (artifacts) to document an architecture

architectural framework—A skeletal structure that defines suggested architectural artifacts, describes how those artifacts are related to each other, and provides generic definitions for what those artifacts might look like

architectural methodology—A generic term that can describe any structured approach to solving some or all of the problems related to architecture

architectural process—A defined series of actions directed to the goal of producing either an architecture or an architectural description

architectural taxonomy—A methodology for organizing and categorizing architectural artifacts

architecture*—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

enterprise architecture—An architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise

Now that we have a common understanding of these key terms, I can take you through the history of enterprise-architecture methodologies, discuss the problems these methodologies are trying to solve, and compare the top four methodologies in terms of their approach and their relationship to each other.

A Brief History of Enterprise Architecture

The field of enterprise architecture essentially started in 1987, with the publication in the IBM Systems Journal of an article titled “A Framework for Information Systems Architecture,” by J.A. Zachman. In that paper, Zachman laid out both the challenge and the vision of enterprise architectures that would guide the field for the next 20 years. The challenge was to manage the complexity of increasingly distributed systems. As Zachman said:

The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems. [02]

Zachman’s vision was that business value and agility could best be realized by a holistic approach to systems architecture that explicitly looked at every important issue from every important perspective. His multiperspective approach to architecting systems is what Zachman originally described as an information systems architectural framework and soon renamed to be an enterprise-architecture framework.

Zachman was a major influence on one of the earliest attempts by a branch of the U.S. Government, the Department of Defense, to create an enterprise architecture. This attempt was known as the Technical Architecture Framework for Information Management (TAFIM) [03] and was introduced in 1994.

The promise of enterprise architectures, such as TAFIM, to better align technical projects with business need was noticed by no less a body than the U.S. Congress. Most likely influenced by the promised benefits of TAFIM, Congress in 1996 passed a bill known as the Clinger-Cohen Act of 1996 [04], also known as the Information Technology Management Reform Act, which mandated that all federal agencies take steps to improve the effectiveness of their IT investments. A CIO Council, consisting of CIOs from all major governmental bodies, was created to oversee this effort.

In April 1998, the CIO Council began work on its first major project, the Federal Enterprise Architecture Framework (FEAF). Version 1.1 [05] of this framework was released in September of 1999. This document contained some innovate ideas, such as “segmented architectures”—that is, architectural focus on segmented subsets of the larger enterprise.

Over time, responsibility for federal enterprise architecture moved from the CIO Council to the Office of Management and Budget (OMB). In 2002, the OMB evolved and renamed the FEAF methodology as the Federal Enterprise Architecture (FEA). I will describe FEA in greater detail, in the section dedicated to it.

Despite the very significant enterprise-architectural activity in the Federal Government (one could argue that no organization has spent more money attempting to develop an enterprise architecture than the U.S. Government), progress has been slow and success stories are overshadowed by higher-profile failures. In 2004, a full eight years after the Clinger-Cohen Act mandated the use of effective IT planning processes, the General Accounting Office (GAO) reported the following:

Only 20 of 96 agencies examined had established at least the foundation for effective architecture management. Further, while 22 agencies increased in maturity since 2001, 24 agencies decreased in maturity and 47 agencies remained the same. [06]

Since January of 2005, the General Accounting Office (GAO, not to be confused with the OMB) has severely chastised a number of U.S. agencies for failures in their adoption or use of enterprise architecture. A few examples include the FBI [07], the Department of Defense [08], the Department of Homeland Security [09], and NASA [10].

In 1998, four years after TAFIM (remember TAFIM?) was introduced and two years after it became codified as Clinger-Cohen, TAFIM was officially retired by the Department of Defense.

The work done on TAFIM was turned over to The Open Group. They morphed it into a new standard that is today known as The Open Group Architectural Framework—better known by its acronym, TOGAF. I will discuss the TOGAF work in the section dedicated to that topic.

In 2005, about the same time that OMB was becoming the dominant EA force in the public sector, another organization was taking steps to become a dominant force in the private sector. This group was Gartner.

By 2005, Gartner was already one of the most influential organizations specializing in CIO-level consulting. However, in the specific area of enterprise architecture, the best known IT research and advisory group was not Gartner, but Meta Group.

Gartner had struggled to build an enterprise-architecture practice, but never achieved the status of the Meta Group. In 2005, Gartner decided that if they couldn’t compete with Meta Group, they would do the next best thing: They would buy it.

Following the purchase of Meta Group, Gartner/Meta spent a year looking at what each company brought to the table as far as enterprise-architecture experience and methodologies. The two companies discussed how best to reconcile their often quite different approaches.

In the end, a fairly simple algorithm was applied: If Meta Group liked it, it was in; if Meta Group didn’t like it, it was out. Gartner liked architectural frameworks. The Meta Group liked architectural process. So, frameworks were out; processes were in. I’ll discuss this Gartner/Meta process in detail, in the section devoted to Gartner.

Figure 3 summarizes this history with an enterprise-architecture timeline. This brings us up to date in the history of enterprise architecture. Now, let’s look more closely at today’s main methodologies and introduce a case study that will be used in this white paper.


Figure 3. Enterprise-architecture timeline

Case Study

So that we can compare and contrast the four major approaches to enterprise architectures, I am going to illustrate how each would approach a similar scenario. This fictitious scenario is a composite of several enterprises with which I have worked over the past several years. So, while it is fictitious, it is very realistic. I’ll first describe the scenario.

MedAMore is a chain of drug stores. It started as a regional chain in 1960. In 1995, it developed an innovative software system that enabled it to run drug stores very efficiently. It called this system MedAManage, or MAM. MAM incorporated some innovate business ideas, such as patient-relationship management, inventory management, automated insurance billing, and even utility optimization.

MAM consisted of three programs: MAM/Store, which ran on a small computer at a drug store; MAM/Warehouse, which ran on a server in a regional warehouse; and MAM/Home, which ran on a large server at the home office.

These three programs communicated through files that were transferred from one location (for example, a store) to another (for example, a regional warehouse). When reliable communications lines existed, file transfers could occur through FTP. The system was also flexible enough to accommodate transfers through courier, where necessary.

By 2000, MedAMore was doing quite well—in part, because of the cost-cutting moves enabled by the MAM system. MedAMore decided to begin expansion. To do this, it purchased three regional chains. With these purchases, MedAMore extended its reach through the southeast quadrant of the U.S.

By 2002, it was clear that the same software systems that had initially fueled MedAMore’s success were now hampering its future. Some of the problems MedAMore was running into were the following:

  • MAM/Store required regional specializations. For example, different insurance plans needed to be supported in different regions, and these all required changes to the MAM/Store module.
  • The regional warehouses that had been acquired through acquisition each had different ways of receiving orders from the retail stores and different procedures from ordering supplies from the wholesalers. Each of these differences required changes to the MAM/Warehouse module.
  • The file-transfer approach to information sharing that had worked so well when MedAMore consisted of 30 drugstores, one regional warehouse, and one home office were turning out to be difficult to coordinate among 200 drugstores, four regional warehouses, two geographic offices, and one home office. Files were often delivered late, sometimes not at all, and occasionally multiple times. This made it difficult for the home office to access reliable, up-to-date financial information, especially in the areas of sales and inventory.

It was clear to MedAMore management that the MAM system needed many enhancements. However, upgrading this system was difficult. Each of the three modules (store, warehouse, and home office) was huge, inefficient, and cumbersome, and each included functionality for everything that each entity might need.

The modules had grown to over 1 million lines of code each. It was difficult to change one function without affecting others. All of the functions accessed a single database, and changes to one record definition could ripple through the system in an unpredictable fashion. Changing even a single line of code required a rebuild of the entire multimillion-line module.

MedAManage had become MedANightmare. Debugging was difficult. Software builds were torturous. Installing new systems was hugely disruptive.

These technical problems soon created internal conflicts within the home office of MedAMore. The business side of MedAMore wanted to acquire two more regional chains, but IT was still struggling to bring the existing acquisitions online.

This resulted in a rapidly growing divide between the business and the technical sides of MedAMore. The business side saw IT as reducing business agility. The technical side saw the business side as making impossible demands and blamed it for refusing to consult IT before entering into acquisition discussions.

The distrust had reached such a point that, by 2005, the CIO was no longer considered part of the executive team of MedAMore. The business side distrusted IT and tried to circumvent it at every opportunity. The technical side built its IT systems with little input from the business folks. Several large and expensive IT initiatives were ignored by the business side and were eventually abandoned.

By 2006, MedAMore was in crisis. It clearly needed to revamp its technical systems to make them easier to specialize for regional requirements. This was going to be an expensive proposition, and MedAMore couldn’t afford for the effort to fail.

Just as importantly, MedAMore also had to rebuild its internal relationships. The constant bickering and distrust between business and IT was affecting morale, efficiency, and profitability. A company that only five years earlier was an industry leader in profitability—in large part, because of its innovative use of IT—was now struggling to stay out of the red—in large part, because of the inflexibility of those same IT systems.

Cath, the CEO of MedAMore, desperately needed a solution. At a CEO conference, she heard how many of her peers were using enterprise architectures to build stronger partnerships between their technical and business groups and deliver more cost-effective IT systems that enabled business agility.

Cath decided that this approach merited further investigation. She asked Irma, her CIO, to prepare a recommendation on the use of an enterprise architecture within MedAMore. Irma was impressed with the approach, but recognized that any such initiative needed to be driven from the top and needed to involve the business side from the start.

On Irma’s recommendation, Cath called a meeting with Bret, the Vice-President of Business, and Irma. Cath announced that she had decided to create a common enterprise architecture for MedAMore that would unite its technical and business people. This common enterprise architecture would be named MedAMore-Enterprise Architecture, or MAM-EA. After it was completed, MAM-EA would drive all new IT investment and ensure that every dollar invested in IT was delivering the maximum value to the business.

Cath knew that MAM-EA was a bet-the-company decision for MedAMore. The MAM-EA vision had to work. Cath was depending on Bret (the business side) and Irma (the IT side) to make it work.

So, that is the problem. Now, let’s see how each of the EA approaches might provide a solution for MedAMore.

The Zachman Framework for Enterprise Architectures

The first thing we need to understand about the Zachman Framework is that it isn’t a framework—at least, by my definition of a framework. According to the American Heritage Dictionary, a framework is defined as:

A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed; An external work platform; a scaffold; A fundamental structure, as for a written work; A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality. [11].

A taxonomy, on the other hand, is defined as:

The classification of organisms in an ordered system that indicates natural relationships; The science, laws, or principles of classification; systematics; Division into ordered groups or categories [12]

The Zachman “Framework” is actually a taxonomy for organizing architectural artifacts (in other words, design documents, specifications, and models) that takes into account both who the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed.

As John Zachman retrospectively described his work:

The [Enterprise Architecture] Framework as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise, as well as to the development of the Enterprise’s systems. [13]

Many proponents of the Zachman Framework see it as cross-disciplinary, with influence extending far beyond IT. One popular book on Zachman, for example, says:

…in due course, you will discover that the Framework exists in everything you do, not only IT projects. When you thoroughly understand the Framework, you can become more effective in everything you do. This means everything. This statement is not made lightly. [14]

John Zachman himself told me, in an interview that I recently conducted with him:

…the Framework schema has been around for thousands of years and I am sure it will be around for a few more thousands of years. What changes is our understanding of it and how to use it for Enterprise engineering and manufacturing. [15]

Zachman originally explained his IT taxonomy using the building industry as an analogy. In that industry, architectural artifacts are implicitly organized using a two-dimensional organization. One dimension is the various “players in the game.” For a physical building, some of these players are the owner (who is paying for the project), the builder (who is coordinating the overall construction), and a zoning board (who is ensuring that construction follows local building regulations).

A building architect prepares different artifacts for each of these players. Every player demands complete information, but what constitutes completeness differs for the different players. The owner is interested in a complete description of the functionality and aesthetics of the building. The builder is interested in a complete description of the materials and construction process. The owner doesn’t care about the placement of studs in the walls. The builder doesn’t care how the bedroom windows line up with the morning sun.

As Zachman said in his original article:

…each of the architectural representations differs from the others in essence, not merely in level of detail. [16]

The second dimension for architectural artifact organization is the descriptive focus of the artifact: the what, how, where, who, when, and why of the project. This dimension is independent of the first. Both the builder and the owner need to know what, but the owner’s need to know what is different from the builder’s need to know what. What what is what depends on who is asking the question.

In his first paper and Zachman’s subsequent elaboration in 1992 [17], Zachman proposed that there are six descriptive foci (data, function, network, people, time, and motivation) and six player perspectives (planner, owner, designer, builder, subcontractor, and enterprise.) These two dimensions can be arranged in a grid, as shown in Figure 4.

From the business owner’s perspective, “data” means business entities. This can include information about the entities themselves, such as customers and products, or information about relationships between those entities, such as demographic groups and inventories. If you are talking to a business owner about data, this is the language you should use.

From the perspective of the person implementing the database, “data” does not mean business entities, but rows and columns organized into tables and linked together by mathematical joins and projections. If you are talking to a database designer about data, don’t talk about customer demographic groups, but talk about third-normal relational tables.

It’s not that one of these perspectives is better than the other or more detailed than the other or of a higher priority than the other. Both of these perspectives on data are critical to a holistic understanding of the system’s architecture. As Zachman said:

We are having difficulties communicating with one another about information systems architecture, because a set of architectural representations exists, instead of a single architecture. One is not right and another wrong. The architectures are different. They are additive and complementary. There are reasons for electing to expend the resources for developing each architectural representation. And there are risks associated with not developing any one of the architectural representations. [18]

I discussed the historical importance of the Zachman Framework in the history section. Here, I will discuss the actual framework itself and how it could be used to help build MAM-EA, the problem proposed in the case-study section.

As I mentioned earlier, the Zachman Framework consists of six functional foci, each considered from the perspective of a major player. The Zachman Framework as it is portrayed today is shown in Figure 4.


Figure 4. Zachman grid

As you can see from Figure 4, there are 36 intersecting cells in a Zachman grid—one for each meeting point between a player’s perspective (for example, business owner) and a descriptive focus (for example, data.). As we move horizontally (for example, left to right) in the grid, we see different descriptions of the system—all from the same player’s perspective. As we move vertically in the grid (for example, top to bottom), we see a single focus, but change the player from whose perspective we are viewing that focus.

There are three suggestions of the Zachman grid that can help MedAMore in the development of MAM-EA.

The first suggestion of the Zachman taxonomy is that every architectural artifact should live in one and only one cell. There should be no ambiguity about where a particular artifact lives. If it is not clear in which cell a particular artifact lives, there is most likely a problem with the artifact itself.

As MedAMore begins accumulating artifacts in the development of MAM-EA, it can use the Zachman grid to clarify the focus of each of these artifacts. For example, artifacts relating to a service-oriented architecture live mostly in the third row (designer’s perspective). They generally will not be of interest to the business owner (Bret, in the MedAMore case study).

The second suggestion of the Zachman taxonomy is that an architecture can be considered a complete architecture only when every cell in that architecture is complete. A cell is complete when it contains sufficient artifacts to fully define the system for one specific player looking at one specific descriptive focus.

When every cell is populated with appropriate artifacts, there is a sufficient amount of detail to fully describe the system from the perspective of every player (what we might today call a stakeholder) looking at the system from every possible angle (descriptive focus). So, MedAMore can use the Zachman grid to ensure that appropriate discussions are occurring between all of the important stakeholders of MAM-EA.

The third suggestion of the Zachman grid is that cells in columns should be related to each other. Consider, for example, the data column (the first column) of the Zachman grid. From the business owner’s (Bret’s) perspective, data is information about the business. From the database administrator’s perspective, data is rows and columns in the database.

While the business owner thinks about data quite differently from the database administrator, there should be some relationship between these perspectives. Somebody should be able to follow Bret’s business requirements and show that the database design is, in fact, being driven by those requirements. If Bret has requirements that are not traceable down to the database design, we must ask if the business needs will be met by this architecture. On the other hand, it there are database-design elements that do not trace back to business requirements, we might ask if we have included unnecessary design at the database level.

So, we can see five ways in which the Zachman grid can help in the development of MAM-EA. It can help:

  1. Ensure that every stakeholder’s perspective has been considered for every descriptive focal point.
  2. Improve the MAM-EA artifacts themselves by sharpening each of their focus points to one particular concern for one particular audience.
  3. Ensure that all of Bret’s business requirements can be traced down to some technical implementation.
  4. Convince Bret that Irma’s technical team isn’t planning on building a bunch of useless functionality.
  5. Convince Irma that the business folks are including her IT folks in their planning.

But Zachman by itself is not a complete solution for MedAMore. There are far too many issues that will be critical to MAM-EA’s success that Zachman does not address. Zachman does not give us a step-by-step process for creating a new architecture. Zachman doesn’t even give us much help in deciding if the future architecture we are creating is the best architecture possible. For that matter, Zachman doesn’t even give us an approach to show a need for a future architecture. For these and other issues, we are going to need to look at other methodologies.

The Open Group Architecture Framework (TOGAF)

The Open Group Architecture Framework is best known by its acronym, TOGAF. TOGAF is owned by The Open Group [19]. TOGAF’s view of an enterprise architecture is shown in Figure 5.


Figure 5. TOGAF’s enterprise architecture

As shown in the figure, TOGAF divides an enterprise architecture into four categories, as follows:

  1. Business architecture—Describes the processes the business uses to meet its goals
  2. Application architecture—Describes how specific applications are designed and how they interact with each other
  3. Data architecture—Describes how the enterprise datastores are organized and accessed
  4. Technical architecture—Describes the hardware and software infrastructure that supports applications and their interactions

TOGAF describes itself as a “framework,” but the most important part of TOGAF is the Architecture Development Method, better known as ADM. ADM is a recipe for creating architecture. A recipe can be categorized as a process. Given that ADM is the most visible part of TOGAF, I categorize TOGAF overall as an architectural process, instead of either an architectural framework (as The Open Group describes TOGAF) or a methodology (as it describes ADM).

Viewed as an architectural process, TOGAF complements Zachman—which, recall, I categorized as an architectural taxonomy. Zachman tells you how to categorize your artifacts. TOGAF gives you a process for creating them.

TOGAF views the world of enterprise architecture as a continuum of architectures, ranging from highly generic to highly specific. It calls this continuum the Enterprise Continuum. It views the process of creating a specific enterprise architecture, such as MAM-EA, as moving from the generic to the specific. TOGAF’s ADM provides a process for driving this movement from the generic to the specific.

TOGAF calls most generic architectures Foundation Architectures. These are architectural principles that can, theoretically, be used by any IT organization in the universe.

TOGAF calls the next level of specificity Common Systems Architectures. These are principles that one would expect to see in many—but, perhaps, not all—types of enterprises.

TOGAF calls the next level of specificity Industry Architectures. These are principles that are specific across many enterprises that are part of the same domain—such as, in our MedAMore case study, all pharmaceutical enterprises.

TOGAF calls the most specific level the Organizational Architectures. These are the architectures that are specific to a given enterprise, such as MedAMore.

Figure 6 shows the relationship between the Enterprise Continuum and the Architecture Development Method (ADM).


Figure 6. The TOGAF Enterprise Continuum

TOGAF defines the various knowledge bases that live in the Foundation Architecture. Two that you might run into are the Technical Reference Model (TRM) and the Standards Information Base (SIB). The TRM is a suggested description of a generic IT architecture. The SIB is a collection of standards and pseudo-standards that The Open Group recommends that you consider in building an IT architecture.

TOGAF presents both the TRM and the SIB as suggestions; neither is required. In my view, both the TRM and the SIB are flawed for the same reason: They are biased toward application portability, at the expense of application interoperability and application autonomy. I consider this an outdated view of technical architectures.

For an organization such as MedAMore, TOGAF largely boils down to the Architecture Development Method (ADM). Individuals within MedAMore will be exposed to the Enterprise Continuum, the SIB, and the TRM (as well as a few other TOGAF features), which is why I discussed them. But the day-to-day experience of creating an enterprise architecture will be driven by the ADM, a high-level view of which is shown in Figure 7.


Figure 7. The TOGAF Architecture Development Method (ADM)

As shown in Figure 7, the TOGAF ADM consists of eight phases that are cycled through after an initial “priming of the pump.” I’ll take you through these phases as they could be applied to the MedAMore case study. But, before MedAMore can start the ADM, it needs to gain some experience with TOGAF. MedAMore will have two choices on how it can get this experience.

First, MedAMore can train itself in TOGAF. MedAMore can download the TOGAF documentation [20]—which describes all of TOGAF, including the ADM, in considerable detail. It can purchase books on TOGAF [21]. There is probably more free and inexpensive available information about TOGAF than about all other architectural methodologies combined.

Second, MedAMore can buy expertise in TOGAF. There are consultants who specialize in TOGAF and have earned Open Group certification [22]. Because MedAMore wants to minimize any chances of failure, it has chosen to call in a TOGAF consultant. MedAMore has brought in Teri, an Open Group–certified TOGAF architect. Remember that the other players at MedAMore are Cath, the CEO of MedAMore; Bret, the Business VP; and Irma, the CIO.

In the Preliminary Phase, Teri meets with the major players at MedAMore to introduce the TOGAF process. Her three goals in the preliminary phase are to:

  1. Make sure everybody is comfortable with the process.
  2. Modify the TOGAF process, as necessary, to fit within the MedAMore culture.
  3. Set up the governance system that will oversee future architectural work at MedAMore.

Teri will work closely with Bret to understand the business philosophy, business models, and strategic drivers of MedAMore. She will work closely with Irma to define the architectural principles that drive technological architectures at MedAMore and document those principles using the TOGAF-recommended format.

In some organizations, achieving buy-in on the need for an enterprise architecture could be very difficult. This is especially true when the effort is driven from the IT organization, and even more so when there is a history of discord between the business and the technical sides of the organization. MedAMore does have this history of animosity. However, it has another fact going for it from which Teri should take heart: The effort is not driven by IT, but is driven by Cath, the CEO. This gives the project high visibility and creates a positive incentive for cooperation from all sides.

As soon as Teri and MedAMore have completed the Preliminary Phase, they are ready to start Phase A. Phase A begins, at least in theory, with a Request for Architecture Work from some organization within MedAMore. This document includes the business reasons for the request, budget and personnel information, and any constraints that need to be considered. Because MedAMore has never done a Request for Architecture Work, Teri will probably need to work with the sponsoring organization in creating such a request.

As soon as the Request for Architecture Work (or some equivalent) has been received, Teri (the TOGAF consultant) starts MedAMore on Phase A. In Phase A, Teri will ensure that the project has the necessary support within MedAMore, define the scope of the project, identify constraints, document the business requirements, and establish high-level definitions for both the baseline (starting) architecture and target (desired) architecture.

These baseline and target definitions will include high-level definitions on all four of the EA sub-architectures shown back in Figure 5—namely, business, technology, data, and application architectures.

The culmination of Phase A will be a Statement of Architecture Work, which must be approved by the various stakeholders before the next phase of the ADM begins. The output of this phase is to create an architectural vision for the first pass through the ADM cycle. Teri will guide MedAMore into choosing the project, validating the project against the architectural principles established in the Preliminary Phase, and ensure that the appropriate stakeholders have been identified and their issues have been addressed.

The Architectural Vision created in Phase A will be the main input into Phase B. Teri’s goal in Phase B is to create a detailed baseline and target business architecture and perform a full analysis of the gaps between them. She will work primarily with Bret (or Bret’s team) to achieve this.

Phase B is quite involved—involving business modeling, highly detailed business analysis, and technical-requirements documentation. A successful Phase B requires input from many stakeholders. The major outputs will be a detailed description of the baseline and target business objectives, and gap descriptions of the business architecture.

Phase C does for the information-systems architecture what Phase B does for the business architecture. In this phase, Teri works primarily with Irma (or her team). TOGAF defines nine specific steps, each with multiple sub-steps:

  1. Develop baseline data-architecture description
  2. Review and validate principles, reference models, viewpoints, and tools
  3. Create architecture models, including logical data models, data-management process models, and relationship models that map business functions to CRUD (Create, Read, Update, Delete) data operations
  4. Select data-architecture building blocks
  5. Conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders
  6. Review qualitative criteria (for example, performance, reliability, security, integrity)
  7. Complete data architecture
  8. Conduct checkpoint/impact analysis
  9. Perform gap analysis

The most important deliverable from this phase will be the Target Information and Applications Architecture.

Phase D completes the technical architecture—the infrastructure necessary to support the proposed new architecture. This phase is completed mostly by engaging with Irma’s technical team.

Phase E evaluates the various implementation possibilities, identifies the major implementation projects that might be undertaken, and evaluates the business opportunity associated with each. The TOGAF standard recommends that Teri’s first pass at Phase E “focus on projects that will deliver short-term payoffs and so create an impetus for proceeding with longer-term projects.”

This is good advice in any architectural methodology. Therefore, Teri should be looking for projects that can be completed as cheaply as possible, while delivering the highest perceived value. A good starting place to look for such projects is the organizational pain-points that initially convinced Cath (the MedAMore CEO) to adopt an enterprise architectural-based strategy in the first place. These pain-points, described earlier, included difficulties in completing regional/warehouse specialization and unreliability in data sharing.

Phase F is closely related to Phase E. In this phase, Teri works with MedAMore’s governance body to sort the projects identified in Phase E into priority order that include not only the cost and benefits (identified in Phase E), but also the risk factors.

In Phase G, Teri takes the prioritized list of projects and creates architectural specifications for the implementation projects. These specifications will include acceptance criteria and lists of risks and issues.

The final phase is H. In this phase, Teri modifies the architectural change-management process with any new artifacts created in this last iteration and with new information that becomes available.

Teri is then ready to start the cycle again. One of the goals from the first cycle should be information transfer, so that Teri’s services are required less and less as more and more iterations of the cycle are completed.

Much of the results of the TOGAF process will be determined as much by the Teri/MedAMore relationship as it will by the TOGAF specification itself. TOGAF is meant to be highly adaptable, and details for the various architectural artifacts is sparse. As one book on TOGAF says:

TOGAF is not wholly specific with respect to generated documents; in fact, it provides very little in the way of prescriptive document templates—merely guidelines for inputs and outputs. [23]

The TOGAF specification is also flexible with respect to the phases. As the specification itself says:

One of the tasks before applying the ADM is to review its components for applicability, and then tailor them as appropriate to the circumstances of the individual enterprise. This activity might well produce an “enterprise-specific” ADM. [24]

TOGAF allows phases to be done incompletely, skipped, combined, reordered, or reshaped to fit the needs of the situation. So, it should be no surprise if two different TOGAF-certified consultants end up using two very different processes—even when working with the same organization.

TOGAF is even more flexible about the actual generated architecture. In fact, TOGAF is, to a surprising degree, “architecture-agnostic”. The final architecture might be good, bad, or indifferent. TOGAF merely describes how to generate an enterprise architecture, not necessarily how to generate a good enterprise architecture. For this, you are dependent on the experience of your staff and/or TOGAF consultant. People adopting TOGAF in the hopes of acquiring a magic bullet will be sorely disappointed (as they will be with any of the methodologies).

Federal Enterprise Architecture (FEA)

The Federal Enterprise Architecture (FEA) is the latest attempt by the federal government to unite its myriad agencies and functions under a single common and ubiquitous enterprise architecture. FEA is still in its infancy, as most of the major pieces have been available only since 2006. However, as I discussed in the history section, it has a long tradition behind it and, if nothing else, has many failures from which it has hopefully learned some valuable lessons.

FEA is the most complete of all the methodologies discussed so far. It has both a comprehensive taxonomy, like Zachman, and an architectural process, like TOGAF. FEA can be viewed as either a methodology for creating an enterprise architecture or the result of applying that process to a particular enterprise—namely, the U.S. Government. I will be looking at FEA from the methodology perspective. My particular interest here is how we can apply the FEA methodology to private enterprises.

Most writers describe FEA as simply consisting of five reference models, one each for performance: business, service, components, technical, and data. It is true that FEA has these five references models, but there is much more to FEA than just the reference models. A full treatment of FEA needs to include all of the following:

  • A perspective on how enterprise architectures should be viewed (the segment model, that I will describe shortly)
  • A set of reference models for describing different perspectives of the enterprise architecture (the five models, mentioned earlier)
  • A process for creating an enterprise architecture
  • A transitional process for migrating from a pre-EA to a post-EA paradigm
  • A taxonomy for cataloging assets that fall within the purview of the enterprise architecture
  • An approach to measuring the success of using the enterprise architecture to drive business value

You can see that the FEA is about much more than models. It includes everything necessary to build an enterprise architecture for probably the most complex organization on earth: the U.S. Government. As the FEA-Program Management Office (FEAPMO) says, FEA, taken in toto, provides:

…a common language and framework to describe and analyze IT investments, enhance collaboration and ultimately transform the Federal government into a citizen-centered, results-oriented, and market-based organization as set forth in the President’s Management Agenda. [25].

While it might be a stretch to imagine that anything short of divine intervention could “transform the Federal government into a citizen-centered, results-oriented, and market-based organization,” there is at least hope that some of the FEA methodology could help our beleaguered MedAMore corporation deal with its much more mundane problems. So, let’s take a look at what FEA has to offer.

The FEA Perspective on EA

The FEA Perspective on EA is that an enterprise is built of segments, an idea first introduced by FEAF [26]. A segment is a major line-of-business functionality, such as human resources. There are two types of segments: core mission-area segments and businessservices segments.

A core mission-area segment is one that is central to the mission or purpose of a particular political boundary within the enterprise. For example, in the Health and Human Services (HHS) agency of the federal government, health is a core mission-area segment.

A business-services segment is one that is foundational to most, if not all, political organizations. For example, financial management is a business-services segment that is required by all federal agencies.

Another type of enterprise-architecture asset is an enterprise service. An enterprise service is a well-defined function that spans political boundaries. An example of an enterprise service is security management. Security management is a service that works in a unified manner across the whole swath of the enterprise.

The difference between enterprise services and segments, especially business-service segments, is confusing. Both are shared across the entire enterprise. The difference is that business-service segments have a scope that encompasses only a single political organization. Enterprise services have a scope that encompasses the entire enterprise.

In the federal government, for example, both HHS and the Environmental Protection Agency (EPA) use the human resources business-service segment. However, the people who are managed by human resources are a different group for HHS from what they are for the EPA.

Both HHS and the EPA also use the security management enterprise service. But the security credentials that are managed by the security-management service are not specific to either of those agencies. Security credentials are managed effectively only when they are managed at the scope of the enterprise.

Resist the temptation to equate either segments or services with services, as in service-oriented architectures. There are two reasons such a comparison would be flawed. Firstly, enterprise services, business-service segments, and core mission-area segments are all much broader in focus than services found in service-oriented architectures. Secondly, segments are an organizational unit for an enterprise architecture, whereas services are an organizational unit for technical implementations. As organizational units for an enterprise architecture, their depth includes not just the technical, but also the business and the data architectures.

One final note about segments: Although segments function at the political (that is, agency) level, they are defined at the enterprise (that is, government) level. Enterprise services, of course, both function and are defined at the enterprise level.

The fact that segments are defined globally facilitates their reuse across political boundaries. One can map out the usage of segments across the political boundaries of the enterprise, then use that map to seek opportunities for architectural reuse. Figure 8, for example, shows a segment map of the federal government from the FEA Practice Guide [27]. As you can see, there are many segments (the vertical columns) that are used in multiple agencies, and any or all of these are good candidates for sharing.


Figure 8. Segment map of the federal government

FEA Reference Models

The five FEA reference models are all about establishing common languages. The goal here is to facilitate communication, cooperation, and collaboration across political boundaries. According to the FEAPMO:

The FEA consists of a set of interrelated “reference models” designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across agencies. Collectively, the reference models [compose] a framework for describing important elements of the FEA in a common and consistent way. [28]

Why do we need a common language? Consider this exchange:

James: Do you have a torch I can borrow?
Roger: No, I’m afraid not.
James: Do you know where I can get one?
Roger: The hardware store in town should have one.

So, James goes out to the hardware store and buys himself a torch. He returns.

Roger: Did you get your torch?
James: Yes, here it is.
Roger: That’s not a torch! That’s a flashlight. Why didn’t you say so? I have one you could have borrowed.
James: Well, why didn’t you say so?

The problem, of course, is that James comes from England, where what I call a flashlight they call a torch. And when I hear torch, I think of a blowtorch. Although we both speak English, we don’t necessarily speak the same English. The result is that James goes out and unnecessarily spends money on something that I could have lent him.

This is exactly the problem that the FEA Reference Models are trying to solve on a much larger scale. Suppose the Internal Revenue Service (IRS) decides it needs a demographics system to track taxpayer data. They ask around to see if anybody has one they can modify for their purposes. Nobody does.

Little do they know that, right next door, the Government Printing Office (GPO) has a perfectly good demographics system that is almost exactly what the IRS needs. They just happen to call it a customer-analytics system.

So, the IRS goes out and builds its system from scratch, instead of just modifying the one already built (and paid for) by the GPO. And, in doing so, the IRS will waste considerably more money than James spent on his unnecessary flashlight.

This, in a nutshell, is the goal of the five FEA reference models: to give standard terms and definitions for the domains of enterprise architecture and, thereby, facilitate collaboration and sharing across the federal government. The five reference models are as follows:

  1. The Business Reference Model (BRM) gives a business view of the various functions of the federal government. For example, the BRM defines a standard business capability called water resource management that is a subfunction of natural resources that is considered a line-of-business of the broader services for citizens business area. [29]
  2. The Components Reference Model (CRM) gives a more IT view of systems that can support business functionality. For example, the CRM defines a customer-analytics system that I described earlier in the hypothetical interchange between the IRS and the GPO. [30]
  3. The Technical Reference Model (TRM) defines the various technologies and standards that can be used in building IT systems. For example, the TRM defines HTTP as a protocol that is a subset of a service transport that is a subset of service access and delivery. [31]
  4. The Data Reference Model (DRM) defines standard ways of describing data. For example, the DRM defines an entity as something that contains attributes and participates in relationships. [32]
  5. The Performance Reference Model (PRM) defines standard ways of describing the value delivered by enterprise architectures. For example, the PRM describes quality as a technology measurement area that is defined as “the extent to which technology satisfies functionality or capability requirements.” [33]

FEA Process

The FEA Process is primarily focused on creating a segment architecture for a subset of the overall enterprise (in FEA’s case, the enterprise is the federal government and the subset is a governmental agency) and is described in the FEA Practice Guidance [34]. I discussed the FEA vision on enterprise segments earlier. The overall segment-architecture development process is (at a very high level) as follows:

  • Step 1: Architectural Analysis—Define a simple and concise vision for the segment, and relate it back to the organizational plan.
  • Step 2: Architectural Definition—Define the desired architectural state of the segment, document the performance goals, consider design alternatives, and develop an enterprise architecture for the segment, including business, data, services, and technology architectures.
  • Step 3: Investment and Funding Strategy—Consider how the project will be funded.
  • Step 4: Program-Management Plan and Execute Projects—Create a plan for managing and executing the project, including milestones and performance measures that will assess project success.

FEA Success Measurement

The FEA framework for measuring organizational success in using enterprise architecture is defined in the Federal Enterprise Architecture Program EA Assessment Framework 2.1 [35]. Federal agencies are rated on their overall maturity levels in three main categories:

  1. Architectural completion—Maturity level of the architecture itself
  2. Architectural use—How effectively the agency uses its architecture to drive decision-making
  3. Architectural results—The benefits being realized by the use of the architecture

OMB assigns each agency a success rating, based on its scores in each category and a cumulative score, as follows:

  • Green—The agency rates quite well in the completion area (it has a quite mature enterprise architecture). It also rates well in both the use area (it is effectively using that enterprise architecture to drive ongoing strategy) and the results area (the usage of that architecture is driving business value).
  • Yellow—The agency rates quite well in the completion area. It also rates well in either the use area or the results area.
  • Red—The agency either does not have a completed architecture and/or is not effectively using that architecture.

The framework is interesting beyond the confines of the public sector. The category ratings can be fruitfully adapted by many enterprises to assess the maturity level of their own architectural efforts. Figure 9, for example, shows my own interpretation of the OMB maturity rankings for architectural completion, as I adapt them for the private sector. Similar adaptations can be created for architectural usage and architectural results.


Figure 9. OMB ranking of architectural completion, adapted for private sector by author (Roger Sessions)

FEA Applied to MedAMore

Now that I have taken you through the FEA approach, let’s see what this might mean to MedAMore. Let’s assume that Cath (MedAMore’s CEO) has heard about FEA and how it is promising to streamline the federal government. If it can do this for the federal government, she reasons, surely it can do this for her company.

Cath hires a consultant, Fred, who is an expert on FEA (if such a thing can be said to exist for a methodology that is, at the time of this writing, less than a year old!). Fred’s job is to show MedAMore how to do FEA—of course, not the real FEA, but FEA as it might be applied to the private sector. Cath introduces Fred to Bret (the business VP) and Irma (the CIO), and tells them to build her anMEA—FEA adapted for MedAMore.

Keep in mind that Cath has taken quite a risk. No other company to date has attempted to apply FEA to the private sector; and even the experience of using FEA within the public sector is nominal, at best.

The first thing that Fred will want to do is build enthusiasm for MEA. Keep in mind that he is coming into an organization in which the business folks barely speak to IT folks. If MEA is going to succeed, it needs to transform not only processes, but people. He will want to create a series of seminars explaining the value of the soon-to-be-defined MEA and how MEA will benefit not only MedAMore as a whole, but the individual units specifically.

Fred will next build a governance structure—MedAMore’s equivalent to FEAPMO. I’ll call this group MEAPMO. MEAPMO will own MEA, including the processes, the models, and the architecture itself.

The next thing that Fred will likely do is create reference models that can be used by all of the organizations across MedAMore. The five reference models from FEA can serve as a starting point. Some, such as the Technical Reference Model, might be usable with few modifications. Others, such as the Business Reference Model, will require extensive renovation. He shouldn’t do these in excruciating detail, but create starting points and build them up as MEA evolves.

Next, Fred will probably want to create a description of the segment architecture as it applies to MedAMore. Note that he will not be doing a complete segment architecture—just a high-level description. The actual process of completing the architecture will be a constantly evolving project.

By this point, a lot of work will have been done with few results. Fred will probably want to take a first pass at a segment-architecture process. FEA’s process will be a good starting point, but will require specialization to MedAMore at the detail level (such as who the team members are and what form the generated artifacts should take).

Now, Fred will test-drive the process with the first segment delivery. He will need to build a team, and then lead this team in analyzing and prioritizing the segments—mapping them to business value, determining their architectural options, delivering the work, and, perhaps most importantly, measuring the results. These measurements will be critical in building momentum for future work.

Soon after completing the first segment, Fred might decide that it is time to measure the progress of the different groups in MedAMore in using MEA effectively. To do so, Fred needs a yardstick to measure the success of the different groups within MedAMore in driving business value with MEA. Fred thus leads MEAPMO in building a MedAMore equivalent to the Federal Enterprise Architecture Program EA Assessment Framework [35]. This yardstick will be Cath’s main tool for ensuring that both the different groups are taking MEA seriously and her investment is paying off.

And, finally, after Fred has completed this process, he will start the process again. Each iteration will result in new segments being delivered, more business value being generated, and more substance being added to the MEA methodology. At least, this is the theory. As I said earlier, with MEA, we are working at the bleeding edge.


So far, I have written about three different methodologies that come together under the banner of enterprise architectures. This last methodology is a little different. It isn’t a taxonomy (like Zachman), a process (like TOGAF), or a complete methodology (like FEA). Instead, it is what I define as a practice. It is the enterprise-architecture practice of one of the best known IT research and consulting organizations in the world: Gartner.

Let me spend a moment exploring my use of the word practice. I use the word “practice” much like I would to describe a physician’s practice. A physician—say, Dr. Pérez—does not diagnose a disease by studying taxonomies, although taxonomies do help him communicate to other healthcare providers. He does not diagnose a disease by following a process, although he might go through an informal process in his head. He diagnoses a disease by applying his practice skills. These practice skills include his experience, training, and ongoing relationships with his colleagues.

How do you choose a physician? Do you grill candidates on how well they know the taxonomy of medicine? Do you sit candidates down and ask for a detailed description of the methodology each follows to diagnose illness? Probably not. You might ask your friends, but they probably only know a limited pool of candidates.

One approach to choosing a physician is to go to a well-known institution (a hospital or medical school) and choose from among their staff. In this approach, you are counting on the institution to choose highly qualified physicians and to have developed a community that encourages collaboration and best practices.

Does that institution insist on a rigid methodology for its physicians to follow? Probably not. Even if it does, it is not your primary concern. You are not even concerned with who the physicians in the institution are—although, in time, that will be of more interest to you. Your initial concern is only the reputation of the institution.

This is very similar to the Gartner approach to enterprise architecture. You don’t bring in Gartner because they do or don’t use TOGAF. You don’t go to Gartner because they do or don’t follow Zachman’s taxonomy. You go to Gartner because they are well-known in their field. You assume both that they hire well-qualified specialists and that they have developed a community that encourages collaboration and best practice.

If you are a Gartner customer and you check the Garner library for research notes describing their enterprise-architecture practice, you can find many such documents. For example, there is “Gartner Enterprise Architecture Process: Evolution 2005” [36] and “Gartner Enterprise Architecture Framework: Evolution 2005” [37]. However, these documents contain little descriptive information and, in any case, are dated in the late-2005 timeframe. Gartner contends that these best practices are timeless, and they continue to augment them as appropriate. The current Gartner methodology was not solidified until probably April of 2006, after the Gartner/Meta merger that I described in the history section.

The best summation of the Gartner practice that I have heard is the following:

Architecture is a verb, not a noun.

What does it mean to say that architecture is a verb, not a noun? It means that it is the ongoing process of creating, maintaining, and, especially, leveraging an enterprise architecture that gives an enterprise architecture its vitality. An architecture that is just a bunch of stiff artifacts that sit in a corner gathering dust is useless, regardless of how sophisticated your taxonomy is for categorizing those artifacts or how brilliant your process is that guided their development.

Gartner believes that enterprise architecture is about bringing together three constituents: business owners, information specialists, the technology implementers. If you can bring these three groups together and unify them behind a common vision that drives business value, you have succeeded; if not, you have failed. Success is measured in pragmatic terms, such as driving profitability, not by checking off items on a process matrix.

Gartner believes that the enterprise architectures must start with where an organization is going, not with where it is. If we are going to clean house, we don’t need to exhaustively document everything we are throwing out. Let’s focus our energy on what we want to end up with. As soon as we know our goal, we can see how what we have relates to that goal.

Gartner recommends that an organization begin by telling the story of where its strategic direction is heading and what the business drivers are to which it is responding. Gartner will want this story in plain language, without worrying about prescribed documentation standards, acronyms, or techno-babble. The only goal is making sure that everybody understands and shares a single vision.

Most organizations are facing major changes in their business processes. The process of creating an enterprise-architecture vision is the organization’s opportunity to sit down, take a collective breath, and ensure that everybody understands the nature, the scope, and the impact of those changes.

As soon as an organization has this single shared vision of the future, it can consider the implications of this vision on the business, technical, information, and solutions architectures of the enterprise. The shared vision of the future will dictate changes in all of these architectures, assign priorities to those changes, and keep those changes grounded in business value.

Enterprise architecture, in the Gartner view, is about strategy, not about engineering. It is focused on the destination. The two things that are most important to Gartner are where an organization is going and how it will get there. Any architectural activity that is extraneous to these questions is irrelevant. “Just enough enterprise architecture, just in time,” is another saying you will hear from the Gartner analyst.

Let’s say Cath (MedAMore’s CEO) likes what she hears. How is a Gartner engagement likely to proceed? With FEA, TOGAF, or Zachman, Cath needs to start by finding a qualified consultant who understands the methodology. With Gartner, this step is much easier: She merely calls Gartner.

Let’s say Gartner sends Greg, the Gartner EA consultant. The first thing Greg will want to do is make sure the architecture is driven from the highest levels of the corporation. The fact that he is being called by MedAMore’s CEO will be very reassuring.

Exactly how Greg will proceed is difficult to predict, because Gartner does not have a firm, step-by-step process. However, it is likely that he will start by focusing on Cath’s strategic vision for MedAMore. He will want her to specify her vision in business terms and resist any temptation to discuss technology. Here are some possible business-vision statements Greg might elicit:

  • MedAMore will have stores in at least 30 states, spread out over 8 geographic regions, by the year 2010. It will accomplish this mainly through acquisition of regional pharmacies.
  • MedAMore will be able to assimilate new regional systems within 120 days of finalization of purchase.
  • MedAMore will reduce its purchasing costs by 10 percent, by consolidating all regional purchasing into a central system.
  • MedAMore’s central office will be able to view consolidated sales and inventory reports from all stores that include data up to and including the previous day.
  • MedAMore will be able to reduce its inventory on-hand to no more than a five-day supply.
  • MedAMore will be able to invoice insurance companies by the end of the day on which the prescription was delivered to the patient.
  • Patients will be able to transfer prescriptions from any MedAMore pharmacy to any other.
  • Patients will be able to request prescription refills though a Web interface and receive e-mail notification of their availability for pick-up.

Notice that none of these visionary statements mentions technology (except as a delivery mechanism, in the last statement). Greg is purposely keeping these early discussions focused on business strategy.

Any one of Cath’s vision “bullets” will have major ramifications across the business, information, and technical architectures. Part of Greg’s job will be to prioritize the bulleted items. Let’s say Cath decides that her highest priority is consolidating purchasing, because this will improve profitability in the near term.

Greg will soon work to turn Cath’s idea about consolidated purchasing into a common-requirements vision (CRV). The CRV is where we will see some of the changes that will be required to drive Cath’s vision for MedAMore. Greg will be going over the business changes with Bret and the technical and information changes with Irma, but he will also be working to bring everybody together as a unified team.

Greg will work with Bret (the business VP) to develop a target business architecture that supports consolidated purchasing. As soon as they have spec’d out the future system, they will also look at their current architecture to see what can be recycled.

Greg will work with Irma (the CIO) to develop a target information architecture that allows the home office to track regional inventories and consolidate procurement. They will also work on the technical architecture for the IT systems that will support the new business architecture. After they understand the future, they will look at current architectures for opportunities to reuse existing technology assets.

After Greg has completed the broad-brush architecture for their strategic vision, he will probably step back from the picture until the consolidated purchasing system has been implemented. If Cath needs help with the implementation of the architecture, she will likely look outside of Gartner, because Gartner does not do implementations.

As soon as the implementation of consolidated purchasing has been completed, Greg will step back in to help with the next iteration. His approach will be to keep the architecture at a high level, business-focused, and hone in on details only when and where necessary. He will continue to see his role not as creating an enterprise architecture for MedAMore, but helping them institute a process for allowing an enterprise architecture to emerge and evolve from the business strategy.


As you can see, the leading enterprise-architecture methodologies are very different in their approaches. Which one is best for your organization? There is no one answer to this question. I’ll take you through the 12 criteria that I most often use for comparing and evaluating enterprise-architectural methodologies. Not all of these criteria might be relevant to your organization, and some might be more important than others. But, at least, this section can serve as a starting point for your own evaluation.

I’ll rank each methodology in each criteria. The ratings will be assigned as follows:

  • 1: Does a very poor job in this area
  • 2: Does an inadequate job in this area
  • 3: Does an acceptable job in this area
  • 4: Does a very good job in this area

Keep in mind that these ratings are subjective. I’m sure most people would disagree with at least one of my ratings.

Taxonomy completeness refers to how well you can use the methodology to classify the various architectural artifacts. This is almost the entire focus of Zachman. None of the other methodologies focuses as much on this area. Ratings:

  • Zachman: 4
  • TOGAF: 2
  • FEA: 2
  • Gartner: 1

Process completeness refers to how fully the methodology guides you through a step-by-step process for creating an enterprise architecture. This is almost the entire focus of TOGAF, with its Architecture Development Method (ADM). Ratings:

  • Zachman: 1
  • TOGAF: 4
  • FEA: 2
  • Gartner: 3

Reference-model guidance refers to how useful the methodology is in helping you build a relevant set of reference models. This is almost the entire focus of FEA. TOGAF also provides support; however, I am less impressed with the TOGAF reference models. Ratings:

  • Zachman: 1
  • TOGAF: 3
  • FEA: 4
  • Gartner: 1

Practice guidance refers to how much the methodology helps you assimilate the mindset of enterprise architecture into your organization and develop a culture in which it is valued and used. This is a primary focus of Gartner’s architectural practice. Ratings:

  • Zachman: 1
  • TOGAF: 2
  • FEA: 2
  • Gartner: 4

Maturity model refers to how much guidance the methodology gives you in assessing the effectiveness and maturity of different organizations within your enterprise in using enterprise architecture. Ratings:

  • Zachman: 1
  • TOGAF: 1
  • FEA: 3
  • Gartner: 2

Business focus refers to whether the methodology will focus on using technology to drive business value, in which business value is specifically defined as either reduced expenses and/or increased income. Ratings:

  • Zachman: 1
  • TOGAF: 2
  • FEA: 1
  • Gartner: 4

Governance guidance refers to how much help the methodology will be in understanding and creating an effective governance model for enterprise architecture. Ratings:

  • Zachman: 1
  • TOGAF: 2
  • FEA: 3
  • Gartner: 3

Partitioning guidance refers to how well the methodology will guide you into effective autonomous partitions of the enterprise, which is an important approach to managing complexity. Ratings:

  • Zachman: 1
  • TOGAF: 2
  • FEA: 4
  • Gartner: 3

Prescriptive catalog refers to how well the methodology guides you in setting up a catalogue of architectural assets that can be reused in future activities. Ratings

  • Zachman: 1
  • TOGAF: 2
  • FEA: 4
  • Gartner: 2

Vendor neutrality refers to how likely you are to get locked-in to a specific consulting organization by adopting this methodology. A high rating here indicates low vendor lock-in. Ratings:

  • Zachman: 2
  • TOGAF: 4
  • FEA: 3
  • Gartner: 1

Information availability refers to the amount and quality of free or inexpensive information about this methodology. Ratings:

  • Zachman: 2
  • TOGAF: 4
  • FEA: 2
  • Gartner: 1

Time to value refers to the length of time you will likely be using this methodology before you start using it to build solutions that deliver high business value. Ratings:

  • Zachman: 1
  • TOGAF: 3
  • FEA: 1
  • Gartner: 4

The criteria and ratings are summarized in Figure 10.


Figure 10. Criteria and ratings for each methodology

One of the important points of Figure 10 is that none of the enterprise-architecture methodologies is really complete. Each has its strengths and weaknesses.

How do you choose which methodology is best for you? Here is my recommended approach:

  1. Go through the rows (criteria) in Figure 10, eliminating any that you feel are not important to your organization.
  2. Add any additional rows (criteria) that you feel are important, and rate each of the methodologies in that area.
  3. Change any of my ratings with which you disagree.

At the end of this exercise, you should have a good idea about the strengths and weaknesses of each methodology with respect to your enterprise’s needs. If a clear winner emerges, count yourself lucky. Find a consultant who specializes in helping enterprises implement that methodology, and go for it.

For many organizations, there will be no clear winner. For such organizations, I recommend you use a blended approach, in which you create your own enterprise-architectural methodology consisting of bits and pieces of each of the methodologies that provide the highest value in your specific areas of concern.

You will want a different kind of consultant—one who has a broad perspective of all of these methodologies and specializes in helping enterprises create a methodology that works best, given the specific needs and political realities of that enterprise.


This paper has covered a broad introduction to the field of enterprise architecture. The history of the field goes back 20 years, but the field is still evolving—and rapidly so. Two of the four major methodologies (Gartner and FEA) have undergone major changes in the last two years alone.

As I have shown, these methodologies are quite different from each other, both in goals and in approach. This is good news and bad. It is bad news, in that it increases the difficulty for many organizations in choosing one single enterprise-architectural methodology. How do you choose between methodologies that have so little in common? Choosing between Zachman and TOGAF, for example, is like choosing between spinach and hammers.

But the good news is that these methodologies can be seen as complementing each other. For many organizations, the best choice is all of these methodologies, blended together in a way that works well within that organization’s constraints. This white paper should provide a good starting place for understanding the value of each of these methodologies and how they can complement each other.

Whichever route you choose, remember that enterprise architecture is a path, not a destination. An enterprise architecture has no value unless it delivers real business value as quickly as possible. One of the most important goals of any enterprise architecture is to bring the business side and the technology sides together, so that both are working effectively toward the same goals.

In many organizations, there is a culture of distrust between the technology and business folks. No enterprise-architecture methodology can bridge this divide unless there is a genuine commitment to change. That commitment must come from the highest level of the organization. Methodologies cannot solve people problems; they can only provide a framework in which those problems can be solved.

But, as soon as you have that commitment to change, an enterprise-architecture methodology can be a valuable tool for guiding that change. This change can manifest itself in many ways. Some of the predicted benefits from a successfully implemented enterprise architectural include:

  • Improvements in using IT to drive business adaptability.
  • Closer partnership between business and IT groups.
  • Improved focus on organizational goals.
  • Improved morale, as more individuals see a direct correlation between their work and the organization’s success.
  • Reduced numbers of failed IT systems.
  • Reduced complexity of existing IT systems.
  • Improved agility of new IT systems.
  • Closer alignment between IT deliverables and business requirements.

It is obvious that an organization that does well in these key areas will be more successful than one that doesn’t. This is true regardless of whether success is measured with tangibles, such as profitability and return on investment, or intangibles, such as customer satisfaction and employee turnover.

The starting point for any enterprise architecture is some critical self-analysis. Does your organization spend too much money building IT systems that deliver inadequate business value? Is IT seen as improving or hampering business agility? Is there a growing divide between your business and IT folks? And, finally, perhaps the most important question of all: Is your organization truly committed to solving these problems, and does that commitment come from the highest levels of the organization? If the answer to all of these questions is “yes,” enterprise architecture is your path. It’s up to you to take that next step.


  • ADM (Architecture Development Method)—A process for creating an enterprise architecture that is part of the TOGAF standard.
  • application architecture—The architecture of a specific application.
  • architect—One whose responsibility is the design of an architecture and the creation of an architectural description.
  • architectural artifact—A specific document, report, analysis, model, or other tangible that contributes to an architectural description.
  • architectural description—A collection of products (artifacts) to document an architecture.
  • architectural framework—A skeletal structure that defines suggested architectural artifacts, describes how those artifacts are related to each other, and provides generic definitions for what those artifacts might look like.
  • architectural methodology—A generic term that can describe any structured approach to solving some or all of the problems related to architecture.
  • architectural process—A defined series of actions directed to the goal of producing either an architecture or an architectural description.
  • architectural taxonomy—A methodology for organizing and categorizing architectural artifacts.
  • architecture—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 (from IEEE-1471-2000).
  • business architecture—An architecture that deals specifically with business processes and business flow.
  • business reference model (BRM)—An FEA term that gives a business view of the various functions of the federal government.
  • business services segment—An FEA term that refers to a segment that is foundational to most, if not all, political organizations, such as financial management.
  • CIO—Chief Information Officer, the executive in charge of information technology in a corporation.
  • CIO Council—A council consisting of CIOs from each of the federal governmental agencies that coordinates work related to common interests.
  • Clinger-Cohen Act of 1996—See Information Technology Management Reform Act.
  • common-systems architectures—A TOGAF term referring to an architecture that is common to many (but not all) types of enterprises, in contrast to foundation architectures and industry architectures.
  • component reference model (CRM)—An FEA term that gives an IT view of systems that support business functionality.
  • data architecture—The architecture of the data (typically stored in databases) owned by the enterprise.
  • enterprise architect—An architect who specializes in enterprise architectures.
  • enterprise architecture—An architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise.
  • enterprise service—An FEA term referring to a well-defined function that spans political boundaries, such as security management.
  • FEA—See Federal Enterprise Architecture (FEA).
  • FEAF—See Federal Enterprise Architectural Framework (FEAF).
  • FEAPMO—The organization within the OMB that owns and administers the Federal Enterprise Architecture.
  • Federal Architecture Program EA Assessment Framework—A benchmark used by the OMB to measure the effectiveness of governmental bodies in using enterprise architecture.
  • Federal Enterprise Architectural Framework (FEAF)—An enterprise-architectural framework used by the U.S. federal government to describe how the various governmental agencies and their IT systems are related to each other.
  • Federal Enterprise Architecture (FEA)—An architectural description of the enterprise architecture of the U.S. federal government that includes various reference models, processes for creating organizational architectures that fit in with the federal enterprise architecture, and a methodology for measuring the success of an organization in using enterprise architectures.
  • foundation architecture—A term used by TOGAF to refer to the most generic of architectures that can be used by any IT organization, in contrast to common systems architectures.
  • GAO—See General Accountability Office (GAO).
  • Gartner—An IT research and advisory organization.
  • gateway—A transfer point of an autonomous system from which messages from the outside world are received or through which messages to the outside world are sent.
  • General Accountability Office (GAO)—A branch of the U.S. Government that is responsible for monitoring the effectiveness of different organizations within the U.S. Government.
  • industry architecture—A TOGAF term that refers to a architecture that is common to most enterprises within an industry, in contrast to a common-systems architecture and an organizational architecture.
  • Information Technology Management Reform Act—An act passed by the U.S. Congress in 1996 that requires all governmental organizations to use effective strategies and frameworks for developing and maintaining IT resources.
  • OMB (Office of Management and Budget)—Part of the Executive Office of the President of the U.S. that serves the function of presidential oversight on federal agencies.
  • The Open Group Architectural Framework—See TOGAF (The Open Group Architectural Framework) 8.1.
  • organizational architecture—A TOGAF term that applies to an architecture that is specific to a particular organization, in contrast to an industry architecture.
  • performance reference model (PRM)—An FEA term that gives standard ways of describing terms related to measuring value.
  • Return on Investment (ROI)—A measure (in percent) of the business value of a project, based on the increase in profit (either because of increased income or decreased expenses) divided by the cost of the project. For example, a project with a cost of $100,000 that returned $200,000 in increased profit has an ROI of 200 percent.
  • ROI—See Return on Investment (ROI).
  • segment—An FEA term that refers to a major line-of-business functionality, such as human resources, that might be shared across organizations.
  • standards information base (SIB)—A TOGAF term that refers to a collection of information about standards, particularly in the area of open-source.
  • TAFIM (Technical Architecture Framework for Information Management)—An architectural framework developed by the Department of Defense and officially discontinued in 2000.
  • technical architecture—Usually refers to the architecture of the technical infrastructure within which applications run and interact.
  • technical reference model (TRM)—Part of TOGAF, a reference model that gives a common language for various pieces of IT architecture. This term is also used for a similar meaning within FEA.
  • TOGAF (The Open Group Architectural Framework) 8.1—An architectural methodology that is controlled by The Open Group.
  • Zachman Framework for Enterprise Architectures—An architectural framework in which an enterprise is modeled as 30 or 36 cells, each of which represents an intersection between a stakeholder perspective and an abstraction.


  • [01] IEEE Standard 1471-2000: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.
  • [02] Zachman, J.A. “A Framework for Information Systems Architecture.” IBM Systems Journal, Volume 26, Number 3, 1987.
  • [03] U.S. Department of Defense. Technical Architecture Framework for Information Management (TAFIM) Volumes 1-8. Version 2.0. Reston, VA: DISA Center for Architecture, 1994.
  • [04] Clinger-Cohen Act of 1996 (PL 107-347) (See THOMAS (Library of Congress).)
  • [05] The Chief Information Officers Council A04. Federal Enterprise Architecture Framework Version 1.1. September 1999.
  • [06] Information Technology: The Federal Enterprise Architecture and Agencies’ Enterprise Architectures Are Still Maturing, GAO Testimony Before the Subcommittee on Technology, Information Policy, Intergovernmental Relations and the Census, Committee on Government Reform, House of Representatives. May 19, 2004.
  • [07] Information Technology: FBI Is Taking Steps to Develop an Enterprise Architecture, but Much Remains to Be Accomplished. GAO-05-363. September 9, 2005.
  • [08] DOD Business Systems Modernization: Long-Standing Weaknesses in Enterprise-Architecture Development Need to Be Addressed. GAO-05-702. July 22, 2005
  • [09] Homeland Security: Progress Continues, but Challenges Remain on Department’s Management of Information Technology, Testimony Before Congressional Subcommittees, Randolph C. Hite, Director, Information Technology Architecture and Systems Issues. GAO. March 29, 2006
  • [10] Business Modernization: Some Progress Made Toward Implementing GAO Recommendations Related to NASA’s Integrated Financial Management Program. GAO-05-799R. September 9, 2005
  • [11] “framework”. The American Heritage Dictionary of the English Language. Fourth Edition. Boston, MA: Houghton Mifflin Company, 2006.
  • [12] “taxonomy”. The American Heritage Dictionary of the English Language. Fourth Edition. Boston, MA: Houghton Mifflin Company, 2006.
  • [13] Zachman, John A. “The Framework for Enterprise Architecture: Background, Description and Utility.” Zachman Institute for Framework Advancement (ZIFA). Document ID: 810-231-0531
  • [14] O’Rourke, Carol, Neal Fishman, and Warren Selkow. Enterprise Architecture Using the Zachman Framework. Boston, MA: Course Technology, 2003. ISBN: 0-619-06446-3
  • [15] Interview with John Zachman by Roger Sessions, Editor-in-Chief, in Perspectives of the International Association of Software Architects, Issue 6.
  • [16] Zachman, J.A. “A Framework for Information Systems Architecture.” IBM Systems Journal, Volume 26, Number 3, 1987.
  • [17] Zachman, J.A., and J.F. Sowa. “Extending and Formalizing the Framework for Information Systems Architecture.” IBM Systems Journal, Volume 31, Number 3, 1992.
  • [18] Zachman, J.A. “A Framework for Information Systems Architecture.” IBM Systems Journal, Volume 26, Number 3, 1987.
  • [19]
  • [20]
  • [21] Perks, Col, and Tony Beveridge. Guide to Enterprise IT Architecture. New York, NY: Springer, 2003. ISBN: 0-387-95132-6
  • [22]
  • [23] Perks, Col, and Tony Beveridge. Guide to Enterprise IT Architecture. New York, NY: Springer, 2003. ISBN: 0-387-95132-6
  • [24] TOGAF Version 8.1.1.
  • [25] “FEA Consolidated Reference Model Document Version 2.1,” December 2006, published by the Federal Enterprise Architecture Program Management Office, Office of Management of Budget.
  • [26] A Practical Guide to Federal Enterprise Architecture by the CIO Council, Version 1.0, February 2001.
  • [27] “FEA Practice Guidance,” December 2006, published by the Federal Enterprise Architecture Program Management Office, Office of Management of Budget.
  • [28] “FEA Consolidated Reference Model Document Version 2.1,” December 2006, published by the Federal Enterprise Architecture Program Management Office, Office of Management of Budget.
  • [29] Ibid.
  • [30] Ibid.
  • [31] Ibid.
  • [32] “The Data Reference Model, Version 2.0,” November 2005, published by the Federal Enterprise Architecture Program Management Office, Office of Management of Budget.
  • [33] “FEA Consolidated Reference Model Document Version 2.1,” December 2006, published by the Federal Enterprise Architecture Program Management Office, Office of Management of Budget.
  • [34] “FEA Practice Guidance,” December 2006, published by the Federal Enterprise Architecture Program Management Office, Office of Management of Budget.
  • [35] Federal Enterprise Architecture Program EA Assessment Framework 2.1, December 2006.
  • [35] Ibid.
  • [36] Bittler, R. Scott, and Gregg Kreizman. “Gartner Enterprise Architecture Process: Evolution 2005.” October 21, 2005. Gartner ID: G00130849
  • [37] James, Greta A., Robert A. Handler, Anne Lapkin, and Nicholas Gall. “Gartner Enterprise Architecture Framework: Evolution 2005.” October 25, 2005. Gartner ID: G00130855


About the author

Roger Sessions is the CTO of ObjectWatch. His ObjectWatch Newsletter is now in its 13th year of publication. He has written six books, including Software Fortresses: Modeling Enterprise Architectures (Addison-Wesley, 2003), and many articles. He is on the Board of Directors of the International Association of Software Architects (IASA), is Editor-in-Chief of Perspectives of the International Association of Software Architects, and is a Microsoft-recognized MVP in Enterprise Architecture. Roger holds multiple patents in both software and enterprise-architecture process. He has given talks at more than 100 conferences around the world, covering a wide range of topics in enterprise architecture. Learn more about Roger Sessions and ObjectWatch at

Posted in ASP.NET MVC, C#, Database, Software architecture | Leave a comment

How do I debug a VBScript script?

Run cscript.exe for full command args

cscript //X scriptfile.vbs MyArg1 MyArg2

will run the script in a debugger.

Posted in Integration, Knowledge | 1 Comment