A note on software architecture style classification

Architecture style of software system has evolved for decades. We can classify these styles as below.

1. No Architecture
no unified principle,thus no architecture
a integration task needed to plug into the whole enterprise after each
application developed
applications interact in a point-to-point way
each application has its own data store
interface bloating with O(n*n)
also referred as "post integration"
drawbacks: lack of semantic consistency
uncontrolled data replication
result: tight coupling, ripple effect

2. The Integrated Database Architecture
unified data model with clearly defined semantic
applications interact through a single data store
a single data store also a giant "global variable"
still result in tight coupling and ripple effect

3. The Distributed Object Architecture
OO Model ensures consistent semantic
still result in tight coupling, vendor lock-in
examples: EJB, DCOM, CORBA

4. Message Broker(Hub and Spoke)
Star-like topology
applications interact through the central broker
add a intermediary between applications, thus application can be removed or
replaced without effect on others
drawbacks: single point of failure
limited scalability
example: Web Methods

5. The Message Bus Architecture
Flexibility is one of the most crucial qualities of modern organization
Imagine main board bus architecture in computer
return to Integrated Database Architecture but difference remains
applications interact by sending message conforming to a message schema
drawbacks: proprietary messaging protocol, vendor lock-in
security risk including network flooding
message format adaption
example: TIBCO Rendezvous

6. Hybrid Architecture
virtual group
each group contains nodes acting as broker and bus
example: Microsoft BizTalk

6. Service Oriented Architecture
service everywhere
each application exports its own function to service which can be consumed by
other application
also each application can import services provided by other application in
implementing its own function
Put it simple, each application can be both service provider and service consumer.

Conclusion
1. No silver bullet, no one-size-fits-all solution.
2. No perfect architecture, only appropriate architecture
3. Big upfront design is less feasible than incremental iterative design

some new stuff worth a look

I came across the InfoWorld's 2008 best open source software awards yesterday. Today InformationWeek's Top50 startups list pops up. Some of them definitely worth a look.

1. Git: a distributed version control system that has been used for Linux kernel, fedora and other important open source projects with geographical distribution characteristic.

2. Intel Threaded Building Blocks: an open source cross-OS x86 c++ template library for parallel programming. The essence of this library is a work stealing scheduler. There is an equivalent API in java called fork-join framework that is under development.

3. Alfreso: open source Enterprise Content Management alternative for MS Sharepoint. Most java projects use Confulence Wiki for similar purpose, but ECM solution provides more rich feature set.

4. Hyperic HQ: comprehensive open source application and system monitoring solution

5. Pentaho: open source Business Intelligence Suite originated from another comprehensive machine learning algorithm package Weka. Note: I have tried Weka for web page classification. It is more lightweight and developer-friendly than other open source alternatives such as RapidMiner.

6. Vyatta: open source router, firewall & VPN solution/claimed Cisco alternative. Ambitious! Here are some intro webcasts. And here is a comprehensive review. Another similar but more academic project is XORP. Ops! It seems Vyatta was really derived from XORP. Anyway, we can consider to use it as a replacement of Cisco low-end products. More importantly, students can download it and build a virtual network lab with VMware-like virtual machine software. Thanks for the hard work from these guys!

7. Metasploit Framework: open source penetration toolkit that can be used to hammer application for finding potential security vulnerabilities. Also It can be used for malicious attack.

8. Splunk: open source security log analysis framework that can analyze logs from various sources to find out security threats.

9. Amanda: maybe mostly used open source backup solution.

10. Abiquo: open source cloud computing solution provider, ambitious too!

11. Eucalyptu: yet another open source cloud computing solution, but more academic.

12: openqrm: open source data center management software, not touted as cloud stuff yet, but it can be.

I will elaborate more details when I try any of them.

architecture principles notes

When I watched a presentation by Ebay architect about Ebay architecture principles, I was thinking about how could we figure out what architecture principles we could use in my specific project cases. After all, architecture principles vary from company to company and from project to project. So what does it derive from? After reading some resources, here is my notes.

1. what?

Before we go further, we'd better make clear what the architecture principles are. Here is a definition from TOGAF's enterprise architecture framework:

Architecture principles are a subset of IT principles that relate to architecture work. They reflect a level of consensus across the enterprise, and embody the spirit and thinking of the enterprise architecture.
......
Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions.

Each architecture principle should be clearly related back to the business objectives and key architecture drivers.

It seems way too dogmatic. Here are the guts:

• They are IT principles.
• They are general guidelines and rules of utilizing IT resources.
• They should be well aligned with business objectives.
  

Here is the components an architecture principle usually contains:

• Name: representative name with clear meaning
• Statement: description of unambiguous fundamental rule
• Rational: highlight business benefits, point out the relations to business principles and relations to other architecture principles, and how to weight them in context
• Implication: requirements from both IT and business to carrying out the principle in terms of resources, cost, activities and cost. It's about impact and consequence.
  

Here is an architecture principles example from Example Set of Architecture Principles from TOGAF's enterprise architecture framework. Another example is NIH enterprise architecture. Maybe this example is more technology oriented.

2. how?

According to the above interpretation of what, we could only derive these architecture principles from business objectives. Here is the method of running a workshop to draw up them. The key points are:

• Identify Strategic Objectives
• Record Strategic Objectives
• Identify Architecture Principles
• Explain Architecture Principles
• Prioritize Architecture Principles
• Show Prioritization Results

reference:

1. http://it.toolbox.com/blogs/enterprise-solutions/running-an-architecture-principles-workshop-12581
2. http://it.toolbox.com/blogs/enterprise-solutions/sample-architecture-principles-workshop-agenda-12598
3. http://www.opengroup.org/architecture/togaf9-doc/arch/
4. http://www.bredemeyer.com/HotSpot/20040428EASoapBox.htm
5. http://enterprisearchitecture.nih.gov/ArchLib/Guide/EnterprisePrinciples.htm
6. http://enterprisearchitecture.nih.gov/About/Approach/Framework.htm
8. http://blogs.msdn.com/architectsrule/archive/2008/04/22/reference-architecture-principles.aspx

handy system administration and monitoring tools

Just a memo:

maybe the most extensive list on the net about system administration:
http://www.slac.stanford.edu/xorg/nmtf/nmtf-tools.html

Among the list, here are those I have used:

Ntop/Nmon: network traffic data collection

Currently the most popular and also oldest network monitoring tools might be Nagios(network and server monitoring) and MRTG(mainly network traffic). Another perl written one cfengine is getting popular for its powerful rule based management script execution system. Rule language is not new. It has been widely used in business rules engine like ILOG and Drool. It also shines when it is used for system administration. I will give a try if I have a chance.

There are some new open source tools worth a look:
1. OpenNMS: java
3. Hyperic: java
3. Zenoss: python

And it seems old boy is losing favor.

operation dimension of system architecture

In terms of software architecture, there are usually various stakeholders involved in a specific system architecture. Each of them might has different architectural requirements. Product department often submits functional requirements. Operation department often submits system management or monitoring requirements. Accounting department may submits billing requirements. And in some cases the system has its own inherent non-functional requirements such as performance, availability and other SLA guarantees. In one word, a system architecture always involves quite a lot dimensions. We have to think about all of them so as to get a full picture of the system. However, developers are usually myopic so that they rarely think about other dimensions. After all, when system rolls out, developers have to work closely with operation people to get feedbacks about production system. If developers don't get well prepared, they may end up with getting nothing. Even worse, they will get entangled into operation aspect. Here are some points developers could consider in advance and prepare for.

The first question is how to get production system status?

The common approach is log extensively in the system itself and send notification email when things get abnormal. Simple! But it don't work when the system is down. And another disadvantages is that application level logging only cares about the system itself. How about machine poweroff or disk failure or network outrage?

So we should have an independent and full functional health management system. Usually this system is maintained by operation department. Then there is a gap, social and technical. The social one is that the two department have to cooperate to make system work. The technical one is about how to make existing health management system be aware of the new system. It depends on both sides. The health management system should be extensible so that it can adapt to any kind of new system. Luckily some full functional monitoring systems qualify. And the new system itself should provide health checking interface that would be called by health management system. So far so good. When system goes wrong, the health management system will get notification in the first place. If they can deal with it, developers can sleep well. Otherwise, developers will get busy.

Another important point is that trust should be built between operation department and development department. Developers should add a lens which can view the dimension of operation to its toolbox. Also system administrators should add a lens which can view the dimension of development to its toolbox, because a full understanding about the new system can help them monitor the system more extensively.

The reason why I am aware of operation aspect of system architecture is that it is getting more and more important today. Service has been a buzzword for years. SOA, SaaS, PaaS, Web Services and so on. So how can we measure the quality of service? Yes, SLA(Service Level Agreement). 4 nines availability and 1s response time. That's it. But how can we reach that SLA? It is closely related to operation. So be watchful of it.

UPDATE: Here is a good post on the same topic: monitoring java system, but more specifically.