Thank You, All My Readers!

After a short five months, thanks to all you readers, this blog has crossed 10,000 hits today!

My sincere thanks to all of you!

Deployment Diagrams – Communication Paths

I have found the concept of communication paths in UML deployment diagrams to be quite frustrating for the simple reason that a communication path connects two deployment targets and no more than two. In other words, communication paths do not support the familiar concept of a “bus” / LAN / “high-speed backbone” to which multiple devices are connected.

As a result, while deployment diagrams are very expressive when it comes to portraying devices and nested execution environment and deployed artifacts, when it comes to showing connectivity between devices, they fall short.

After living with this problem for a long time (I pretty much stopped illustrating connectivity between devices), I hit upon the simple idea of modeling a “bus” / LAN / “high-speed backbone” as a node (not a device). This way, I am now able to connect multiple devices to this “bus” / LAN / “high-speed backbone”!

Structure of Deployment Models

Deployment models, while being very expressive, are not easy to organize and manage. Any non-trivial deployment model would require a multitude of devices, execution environments and artifacts (and multiple instances of these) which typically makes the organization of a deployment model somewhat hard.

The following package diagram represents a typical model organization that I have found useful in the J2EE space:

A Domain Reference Architecture Framework

Having written a set of posts on the various diagrams of the Unified Modeling Language, I now proceed to pull them all together into a whole, and call all those diagrams into service to represent the architecture of a specific business domain. I refer to such an architecture as a domain reference architecture.

In these posts, I use Insurance as the business domain for illustrative purposes.

I split architecture into two parts: 

• functional architecture
• technology architecture

The Agile Anthem

Imagine no deadlines 
I wonder if you can 
No need for plans or schedules 
A brotherhood of man 
Imagine all the people 
Sharing all the pain 

You may say I’m a dreamer 
But I’m not the only one 
I hope someday you’ll join us 
And the world will code as one

- The Agile Anthem, not by John Lennon

The Twelve Commandments of Agile – Conclusion

The Agile Manifesto says:

We are uncovering better ways of developing software by doing it and helping others do it.

Thank you very much. Much obliged.

While their intentions are good, Agile Methodists’ methods simply do not sound appropriate to enterprise-class software development. 

The Agile Methodists are living in a world much simpler than the one I inhabit and from where I stand their methods seem corny to say the least:

The Twelve Commandments of Agile – Commandment XII

Here is the Twelfth Commandment:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

- The Twelve Principles of Agile, The Agile Manifesto

Really? Are you quite sure? Oh my! What can I say!

Team reflecting on how to become more effective

Get real guys!

This is not really a commandment but an ideal. This is the kind of thing that makes Agile less a methodology and more a religion.

The Twelve Commandments of Agile – Commandment XI

Here is the Eleventh Commandment:

The best architectures, requirements, and designs emerge from self-organizing teams.

- The Twelve Principles of Agile Software, The Agile Manifesto

This begs the question what is a self-organizing team? In the absence of a definition of this term I went Googling for a definition:

The Twelve Commandments of Agile – Commandment X

Here is the Tenth Commandment:

 Simplicity–the art of maximizing the amount of work not done–is essential.

- The Twelve Principles of Agile Software, The Agile Manifesto

This is yet another motherhood statement in the same league as “you should have a motivated team” (Commandment V) and “you should create a good design” (Commandment IX). No arguing with this one in principle.

In practice, in the context of enterprise-class software development, this focus on simplicity does create special problems when building software on an enterprise scale.

Consider an insurance policy admin system that one of my teams is building right now:

The Twelve Commandments of Agile – Commandment IX

Here is the Ninth Commandment:

Continuous attention to technical excellence and good design enhances agility.

- Twelve Principles of Agile Software, The Agile Manifesto

Oh well, continuous attention to technical excellent and good design is certainly desierable and nobody can deny that. And it will enhance not only agility but all of the following ilities listed on Wikipedia: