A Comparison between Enterprise-Architecture Methodologies

Roger Sessions explains comparisons between top 4 architecture methodologies in this article.
None of the methodologies fulfills the enterprise architecture however they can be viewed as -

• 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

Following table shows ratings for these four methodologies -

• 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

(Unevaluated) Cost of UI performance

Scenario – Accounting application, data entry operators works 20-30 $/hour, total 10 data entry operators

What is the average time user wastes on UI per day? (For example – waiting for data, scrolling up-down/right-left, performance of controls (loading etc))

- 10-12 minutes per day of 8 hrs

Average time wasted per week per user –5 days * 12 minutes = 60 minutes

Average time wasted per month – 4 weeks * 60 minutes = 4 hours

Average time wasted per year – 12 months * 4 hours = 48-50 hours

Average time wasted for 10 data entry operators – 10 persons * 50 hours = 500 hours

Total cost  = $20 or $30 * 500 hours = $10K to $15K

Conclusion – while designing UI, only look-n-feel is not important but you also need to consider for whom you are solving & how fast.

Fast & Simple

Fast & simple – basic principles to work on any type of project although following are examples specific to software projects

Simple – to design / coding / for testing / for deployment / simple to use & operate (for end user)

Fast – to design / for coding / for testing / for deployment / fast (performance & scalability) for end user

Simplicity doesn’t mean cheap & easy. Creative thinking & innovative attitude helps to bring ‘simple’ approach in any product.

Any simple designed product has more life than over engineered product.

Bad s/w - Good s/w

The following type of code pattern indicates that software is badly written:
. Rigidity—Rigid software is software that requires a cascade of changes when you
make a change in one place.
. Fragility—Fragile software is software that breaks in multiple places when you
make a change.
. Needless complexity—Needlessly complex software is software that is overdesigned
to handle any possible change.
. Needless repetition—Needlessly repetitious software contains duplicate code.
. Opacity—Opaque software is difficult to understand.

Software design principles:
. SRP—Single Responsibility Principle
. OCP—Open Closed Principle
. LSP—Liskov Substitution Principle
. ISP—Interface Segregation Principle
. DIP—Dependency Inversion Principle

Robert and Micah Martin Agile Principles, Patterns, and Practices in C# on page 104

High scalable architectures

Last week I came across interesting web site by Todd Hoff who was former IBM and Intuit Employee.

His site http://highscalability.com/ on high scalable architectures has some big shot web sites explaining lore, art and science behind it. Some examples are:

• YouTube Architecture
• PlentyOfFish Architecture
• Google Architecture
• Flickr Architecture
• Amazon Architecture
• Scaling Twitter: Making Twitter 10000 Percent Faster
• An Unorthodox Approach to Database Design : The Coming of the Shard

His personal web site is at http://possibility.com/Tmh/ and Wiki stuff is at http://www.possibility.com/wiki/index.php?title=Main_Page

A sample enterprise architecture implementation checklist

While reading past post found some of the basic activities that must take place as part of any enterprise architecture implementation. This list should give you an idea of what the enterprise architecture work is really all about:

• Study existing business practices.
Understanding the business model of your organization and, at a minimum, its high-level business processes is a pre-condition for commencing the enterprise architecture implementation.
• Engage with senior management to understand strategic intent.
Obviously, senior management holds a key to interpreting strategic vision. Understanding a vision is critical for the purposes of drawing the roadmap of the enterprise architecture, as this artifact will drive the "to-be" part of the architectural work to come (more about this below).
• Connect with the business community to uncover urgent needs.
While senior management may be envisioning the organization's future state, the business community holds more answers about its current state. Your goal is to extract those facts and level them with the expectations set by the strategic vision.
• Build a panoramic understanding of the existing technology environment.
Technology is a major enabler of business processes (the other one being people), which implies that you won't go too far without proper understanding of your main tool.
• Draw the improvement roadmap.
Having collected data from various sources, create a roadmap to advise the stakeholders -- including senior management, business, and technology leaders -- about how you intend to act upon the needs they have communicated to you.
• Keep enterprise architecture models up-to-date.
Needless to say, after you create the roadmap for the enterprise architecture and receive stakeholder approval on it, you ought to make the best effort to update it over time.

How to bring TOGAF to life

Following blog has some good info on using TOGAF. How to bring TOGAF to life

Agile Development Tools

Some tools for Agile Development -

http://www.scrumworks.com/

http://studios.thoughtworks.com/mingle-project-intelligence

Arithmetic overflow caused death of several people!

The Therac-25 was a computer controlled radiation therapy machine produced by Atomic Energy Canada Ltd. in the 1980s. The machine offered two modes of therapy, including "Megavolt X-ray therapy". The problem happened when the machine's software failed to move a component into place to convert an electron beam into X-rays, allowing a high power electron beam to directly strike patients. At least 5 patients died of radiation poisoning from dosages that were sometimes in the hundreds of Grays.
AECL did not have the machine's software independently reviewed. AECL did not assess what potential failure modes existed. The system documentation did not explain error codes. AECL ignored incident reports.
The problem turned out to be a software bug which intermittently caused an arithmetic overflow. When this happened, the software bypassed safety checks. So the machine killed people that were simply undergoing therapy.

from http://blog.cioinsight.com/parallax_view/content/information_technology/top_10_it_disasters_of_all_time.html

You can read here more on Top 10 IT Disasters of All Time

XP, MSF Agile, RUP & MSF

XP, MSF Agile, RUP, and Microsoft Solution Framework :

Extreme Programming (XP) at a Glance
MSF Agile at a Glance
Rational Unified Process (RUP) at a Glance
Microsoft Solution Framework (MSF) at a Glance

7 Habits of Highly Effective Program Managers

Found this interesting habits on J.D Meier's blog

Habit 1, Frame problems and solutions.
Habit 2, Sell visions.
Habit 3, Deliver incremental value.
Habit 4, Manage communication.
Habit 5, Connect with customers.
Habit 6, Execute.
Habit 7, Leverage the system.

SCRUM Resources

SCRUM info and resouces

http://www.controlchaos.com/

What's agile, what's not

Here is an article by Alistair Cockburn which list top 10 of how to know you're not doing agile?

Guidelines when applying color in diagrams

Without a doubt, the use of color dramatically impacts any diagram or presentation. You can use color to draw attention to particular aspects of a diagram, to distinguish differences between elements, or simply to increase the visual appeal. When misused, however, color can cause discomfort to the viewer and even create ambiguity. Discover some of the common mistakes modelers can make when applying color to diagrams, and learn a set of simple rules you can follow when presenting model information containing color.

This article on Using color effectively in system models discusses how to follow simple guidelines when applying color in diagrams.

Being an Agile Architect..

Today more on Agile.... here is great discussion on Being an Agile Architect by Sam...

Bringing Agility to Architecture, and Architecture to Agility

Agile development methods are good or not? Despite some successes larger organisations and projects have been very slow to adopt them, one of the reasons is that many agile methods are perceived as architecturally weak, disconnected from the realities of delivering large systems in complex enterprise environments.

At the same time, many architecture processes are seen as slow, clumsy and bureaucratic. They would benefit from a more agile approach.

This site http://www.agilearchitect.org/agile/index.asp looks at ways to confront this dilemma, by bringing agility to architecture and architecture to agility.

TOGAF, architecture domains and 'BAD' 'T'ea

Open Group Architecture Framework supports four architecture domains: To memorize, remember 'Bad Tea' :)

• Business (or business process) architecture which defines the business strategy, governance, organization, and key business processes of the organization
• Applications architecture which provides a blueprint for the individual application systems to be deployed, the interactions between the application systems, and their relationships to the core business processes of the organization
• Data architecture which describes the structure of an organization's logical and physical data assets and the associated data management resources
• Technology architecture which describes the software infrastructure intended to support the deployment of core, mission-critical applications

and EA is enterprise architecture?

TOGAF or not TOGAF: Extending Enterprise Architecture beyond RUP

This article contrasts the disciplines of enterprise architecture, solution architecture, and business architecture; compares these disciplines to the IBM Rational Unified Process (RUP) and suggests ways to combine them; and advocates applying The Open Group Architecture Framework (TOGAF) in combination with RUP to advance the implementation of enterprise architecture within organizations.

TOGAF or not TOGAF: Extending Enterprise Architecture beyond RUP

The Art of Project Management: How to Make Things Happen

MS Project mager Scott Berkun discusses here on The Art of Project Management: How to Make Things Happen.


The ability to make things happen

-Some people are able to apply their skills and talents in whatever combination necessary to move projects forward, and others cannot, even if they have the same or superior individual skills. The ability to make things happen is a combination of knowing how to be a catalyst or driver in a variety of different situations, and having the courage to do so.

Priorities Make Things Happen

-Collect things that had to be done like requirements, features, bugs. Make a list discuss/debate with others on list to priorites, making sure they were rock solid.

And some Guerilla tactics too....

The Architecture Development Method (ADM) - Basic Phases

Originally designed as a way to develop the technology architecture for an organization, TOGAF has evolved into a methodology for analyzing the overall business architecture. The first part of TOGAF is a methodology for developing your architecture design, which is called the Architecture Development Method (ADM). It has the following nine basic phases:

• Preliminary phase: Framework and principles. Get everyone on board with the plan.
• Phase A: Architecture vision. Define your scope and vision and map your overall strategy.
• Phase B: Business architecture. Describe your current and target business architectures and determine the gap between them.
• Phase C: Information system architectures. Develop target architectures for your data and applications.
• Phase D: Technology architecture. Create the overall target architecture that you will implement in future phases.
• Phase E: Opportunities and solutions. Develop the overall strategy, determining what you will buy, build or reuse, and how you will implement the architecture described in phase D.
• Phase F: Migration planning. Prioritize projects and develop the migration plan.
• Phase G: Implementation governance. Determine how you will provide oversight to the implementation.
• Phase H: Architecture change management. Monitor the running system for necessary changes and determine whether to start a new cycle, looping back to the preliminary phase.

http://www.ibm.com/developerworks/library/ar-togaf1/