While the TEC web site uses a tree control to allow users to navigate through the capabilities of ERP software, my interest is in creating a UML representation of the same. Here is what I came up with:

I do not have the patience to create the 3000+ use cases that reside in these many packages, but if someone is looking for what is broadly in the scope of the term “enterprise resource planning”, this diagram is very illuminating.

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”!

Here is an example of what I mean:

Alternately, imagine all the crisscrossing lines that will be needed to depict this same connectivity using communication paths and you will see why this model is a great improvement!

It is tempting to think of this node as a physical router / switch, but I refrain from doing that because a typical LAN is made up of more than one single router / switch. Hence this node is really modeling a collection of hardware and cables that go into a “bus” / LAN / “high-speed backbone” (this is why I did not model this as a device).

Strictly speaking, this node is not all right. You cannot deploy anything in it. Nothing executes on it. It is not a device; not an execution environment. It just carries signals back and forth which is not the semantics associated with a node in UML. But, until UML comes up with a better way to represent a “bus” / LAN / “high-speed backbone”, I am sticking with this, albeit inaccurate,  invention.

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

All deployment diagrams are inside the Topology package with each of the sub-packages containing the deployment diagram for a particular environment.

Each of these deployment diagrams is built using instances of devices, execution environments and artifacts that are present in the Nodes and Artifacts packages. In other words, while the definitions of devices, execution environments and artifacts reside in the Nodes and Artifacts packages, instances of these will reside in the individual “environment” packages along with the deployment diagram for that environment.

The Nodes package is organized as Devices (the hardware) and Execution Environments (the infrastructure software). The one unlabeled device models a high-speed LAN (more on this in my next post).

The Artifacts package is organized as Framework Artifacts (which manifest popular pre-built components) and Application Artifacts (which manifest custom-built components).

The recommended order of creation of these packages is as follows:

• Define all your devices and execution environment first with appropriate tagged values to describe their various characteristics.
• Define all your artifacts next. These are the various code components that you have built (dll, jar files, cab files, XML files, whatever) as well as any pre-built frameworks that you have used in your custom-built code.
• Finally, proceed to define each of the environments. Drag and drop devices, execution environments and artifacts to create new instances of these in your deployment diagram. Change the tagged values appropriately to represent that particular environment accurately (for example, a production environment device is likely to have much more CPU and memory than a corresponding integration environment device).

In summary, deployment diagrams use instances of nodes and artifacts. Hence you need to define nodes and artifacts first, and then create instances of those. Also, typical software systems require multiple deployment diagrams – for instance, one for each environment. This leads to a proliferation of instances. Hence, it is advisable to keep the definitions separate from the instances. That is what this deployment model structure is attempting to do.

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

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 Grand Academy of Lagado, Gulliver's Travels

I was complaining of a small fit of the colic, upon which my conductor led me into a room where a great physician resided, who was famous for curing that disease, by contrary operations from the same instrument. He had a large pair of bellows, with a long slender muzzle of ivory: this he conveyed eight inches up the anus, and drawing in the wind, he affirmed he could make the guts as lank as a dried bladder. But when the disease was more stubborn and violent, he let in the muzzle while the bellows were full of wind, which he discharged into the body of the patient; then withdrew the instrument to replenish it, clapping his thumb strongly against the orifice of the fundament; and this being repeated three or four times, the adventitious wind would rush out, bringing the noxious along with it, (like water put into a pump), and the patient recovered. I saw him try both experiments upon a dog, but could not discern any effect from the former. After the latter the animal was ready to burst, and made so violent a discharge as was very offensive to me and my companion.

The dog died on the spot, and we left the doctor endeavouring to recover him, by the same operation.

- A Voyage to Laputa, Gulliver’s Travels, Part III, Chapter V, Jonathan Swift

While better ways of developing softwre are most welcome, these better ways are not going to be arrived at by over-simplifications of reality:

We next went to the school of languages, where three professors sat in consultation upon improving that of their own country. 

The first project was, to shorten discourse, by cutting polysyllables into one, and leaving out verbs and participles, because, in reality, all things imaginable are but nouns.

The other project was, a scheme for entirely abolishing all words whatsoever; and this was urged as a great advantage in point of health, as well as brevity. For it is plain, that every word we speak is, in some degree, a diminution of our lunge by corrosion, and, consequently, contributes to the shortening of our lives. An expedient was therefore offered, “that since words are only names for things, it would be more convenient for all men to carry about them such things as were necessary to express a particular business they are to discourse on.” And this invention would certainly have taken place, to the great ease as well as health of the subject, if the women, in conjunction with the vulgar and illiterate, had not threatened to raise a rebellion unless they might be allowed the liberty to speak with their tongues, after the manner of their forefathers; such constant irreconcilable enemies to science are the common people.

- A Voyage to Laputa, Gulliver’s Travels, Part III, Chapter V, Jonathan Swift

A good way to improve agility is to automate the detail work involved in programming as was done by client/server development tools such as PowerBuilder. By speeding up the development processes, these tools tended to reduce project cycle time from requirements to production release.

The Internet complicated the landscape by pushing processing back to centralized servers (a la mainframes). Object oriented design methodology further complicated matters by introducing ideas such a separation of concern, MVC architecture and now service oriented architecture. The Model Driven Architecture guys have set off on  the right track by attempting the encapsulate these OO concepts in frameworks and tools in order to generate fully-functional systems from platform independent models. While I have my reservations on their approach [Model Driven Archietcture - Myth or Reality?], I have great respect for their daring.

As for Agile Methodists, the less said the better. Enough said.

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 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:

When we say an Agile team is self-organizing, we mean that a group of peers has assembled for the purpose of bringing a software development project to completion using one or more of the Agile methodologies. The team members share a goal and a common belief that their work is interdependent and collaboration is the best way to accomplish their goal. Empowered team members’ reduce their dependency on management as they accept accountability, and the team structure places ownership and control close to the core of the work. Rather than having a manager with responsibility for planning, managing and controlling the work, the team members share increasing responsibility for managing their own work and also share responsibility for problem-solving and continuous improvement of their work processes.

- Team Agility: Exploring Self-Organizing Software Development Teams (PDF)

I gather this is all about empowering teams to make their own decisions, and de-emphasing managment by one or more managers.

I found an excellent take on this aspect by Jim Highsmith:

First, I’d like to get away from the idea that agile teams are leaderless and that leadership only revolves around the team depending on the situation (this type of situational leadership does occur, and often, it just does not replace a good leader). There is just too much experience and management literature that shows that good leaders make a big difference. The anarchist wants to eliminate leaders and merely go with situational leadership. However, there is also a large contingent in the agile community that think the right approach is to change the style of leadership, not to eliminate leaders. It’s easy to rail against poor managers or leaders and advocate eliminating them. It’s much harder to work with organizations to change their leadership style to one that supports an agile environment.

- No More Self-Organizing Teams, Jim Highsmith 

Mr. Highsmith goes on to add:

Some advocates of empowerment have been carried away. They forget that in the management literature empowerment is a fancy new term for delegation — delegation of decision-making authority. Does empowerment mean that project teams get to make all decisions related to their project? What if there are five teams working on a project, does each team get to make architectural or development infrastructure decisions independently? Light-Touch Leadership means that decision making is delegated to the lowest level possible and as many decisions as possible are delegated to the team. However, delegating decisions in an organization isn’t a simple task; it requires tremendous thought and some experimentation. To me, Light-Touch conveys the right mix of delegation of decision making to teams while retaining appropriate decision-making authority with the leader or in other parts of the organization

So much for self-organizing teams. I could use my own words but I would express the same sentiments as Mr. Highsmith.

I will add that I have managed many projects using what the Agile Methodists would call a “command and control” approach. The projects were successful; customers were happy; my management was happy; my teams were happy. This indicates that the architecture, requirements and design were adequate if not the best. Also adequate were many other things this commandment does not mention such as test cases, project plans, status reports etc.

So what problem is this commandment trying to solve?

 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 first release is expected to service UK and subsequent releases need to service France, Spain, Germany, Netherlands and other continental European countries.
• The first release is expected to service casualty insurance product, the next release will address property insurance products (which is further split into property, auto, and marine – hull as well as cargo).
• Somewhere in the release roadmap lies support for personal as well as commercial lines (personal auto insurance is significantly different from insuring a fleet of cars for a car rental company).

Further consider that due to the desire for the aforementioned flexibility, we have chosen to use a workflow engine. A portal server was chosen to provide personalization and flexible branding, an ESB was chosen to support implementation of services, an identity management product was chosen to support authentication and authorization. Further consider that these products could potentially come from different vendors. This is no longer your run-of-the-mill, “simple” system any longer.

Putting it differently, from the time the Agile Manifesto and Twelve Commandments were published in 2001, to today, there has been a significant increase in the complexity of enterprise solutions. The move from simple client-server technologies to service-orientation and Internet technologies has inherently complicated enterprise solutions. When I now see a commandment that reads “simplicity is essential” I wonder which world are these guys living in?

It is worth noting the practical effect this commandment has on Agile Methodologies. Most Agile methodologies recommend keeping the design of a software system very simple. Their key to doing this is to live in  the present and not make any attempts to future-proof the system. While this is really an attempt to avoid over-engineering, many Agile Methodists do end up under-engineering! In other words, they really maximize the amount of work not done and that is not always a good thing!

That said, I repeat, the underlying sentiment expressed by this commandment is unexceptionable. Leonardo da Vinci said it best when he said:

 

 Simplicity is the ultimate sophistication

Unfortunately, these twelve commandments while being extremely simple are far from sophisticated!

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:

 
Substitute any of these ilities in this commandment in the place of agility and it will still makes sense.

This commandment is really a motherhood statement. Maybe it is used just to make up the numbers?