Monday, November 22, 2010

Architecture Drill Down in the UML

Solution Architects need to create models of the systems they are building for a number of reasons:
  • Models help to visualise the component parts, their relationships and how they will interact.
  • Models help stakeholders understand how the system will work.
  • Models, defined at the right level of detail, enable the implementers of the system to build the component parts in relative isolation provided the interfaces between the parts are well defined.
These models need to show different amounts of detail depending on who is looking at them and what sort of information you expect to get from them. Grady Booch says that "a good model excludes those elements that are not relevant to the given level of abstraction". Every system can be described using different views and different models. Each model should be "a semantically closed abstraction of the system" (that is complete at what ever level it is drawn). Ideally models will be both structural, emphasizing the organization of the system, as well as behavioral, emphasizing the dynamics aspects of the system.

To support different views and allow models to be created at different levels of abstraction I use a number of different diagrams, created using the Unified Modeling Language (UML) in an appropriate modeling tool (e.g. Rational Software Architect or Sparx Enterprise Architect). Using a process of "architecture drill-down" I can get both high level views as well as detailed views that are relevant to the level of abstraction I want to see. Here are the views and UML diagrams I create.
  • Enterprise View (created with a UML Package diagram). This sets the context of the whole enterprise and shows actors (users and other external systems) who interact with the enterprise.
  • System View (Package diagram). This shows the context of an individual system within the enterprise and shows internal workers and other internal systems.
  • Subsystem View (Package diagram). This shows the breakdown of one of the internal systems into subsystems and the dependencies between them.
  • Component View (Component diagrams and Sequence diagrams). This shows the relationships between components within the subsystems, both static dependency type relationships (through the UML Component diagram) as well as interactions between components (through the UML Sequence diagram).
  • Component Composition View (Composite Structure diagram). This shows the internal structure of a component and the interfaces it provides.
Note hat a good tool will link all these together and ideally allow them to be published as HTML allowing people without the tool to use them and also navigate through the different levels. Illustrative examples of the first three of the diagrams mentioned above are shown below. These give increasing levels of detail for a hypothetical hotel system. Click on the picture to get a bigger view.
Enterprise View

System View

Subsystem View
In the actual tool, Sparx Enterprise Architect in this case, each of these diagrams is linked so when I click on the package of the first it opens up the second and son on. When published as HTML this "drill-down" gets maintained as hyperlinks allowing for easy navigation and review of the architecture.

Monday, November 15, 2010

Five Inspirational Videos

As a follow-up to my six non-IT books here are five videos I have found some inspiration from recently (plus one that whilst cannot be described as inspirational is at least amusing in a vaguely nerdy programmer kind of way):
  1. Steve Jobs (A CEO): How to Live Before You Die Steve Jobs steps out from his usual Apple presentation mode and delivers this keynote to students at Stanford. He highlights three things which have had a major impact on his life and how important it is to learn from such life experiences.
  2. Winston Royce (A Methodologist): The Rise and Fall of Waterfall Not actually by Winston Royce but a humorous look at how we ended up with waterfall. An example of how to get a point across by telling a story (and using wonderfully simple graphics).
  3. Grady Booch (A Software Architect): The Promise, The Limits, The Beauty of Software Grady is an inspirational speaker on all things software related. We were lucky enough to get him to write the forword to our book (which I'm sure has done its sales the world of good).
  4. Sir Ken Robinson (An Innovator and Educationalist): Do Schools Kill Creativity SKR (as he calls himself on his website) has some strong views on how our present education system is letting down youngsters.For a great rendition of another of Sir Ken's talks see here.
  5. David Eustace (A Photographer): In Search of Eustace Nothing to do with IT but related to one of my other passions. This simple and beautifully filmed video set to music will resonate with anyone on life's journey.
And finally...
  1. Lady Gaga (A Singer) Lookalike: Sings About Java Programming An example of how creativity (the video production) can be used to improve even the worst ideas (the song). What else can I say! 

Sunday, November 14, 2010

Hire an Architect

Seth Godin has a great definition of what an architect is in his blog here. Here's the description:

Architects don't manufacture nails, assemble windows or chop down trees. Instead, they take existing components and assemble them in interesting and important ways.

He goes on to say that:

...intentionally building a structure and a strategy and a position, not focusing your energy on the mechanics, because mechanics alone are insufficient. Just as you can't build a class A office building with nothing but a skilled carpenter, you can't build a business for the ages that merely puts widgets into boxes.

I like this because for me this is absolutely the essence of what an architect does, take existing components and put them together in new and interesting ways. That's exactly what Tim Berners-Lee did when he created the web. The key skill is not to get bogged down in the detail but to maintain the big picture of whatever it is you are doing. It applies equally to IT systems just as much as it does to buildings.

Thursday, November 11, 2010

When a Bridge Falls Down is the Architect to Blame?

Here's a question. When a bridge or building falls down whose "fault" is it. Is it the architect who designed the bridge or building in the first place, is it the the builders and construction workers who did not build it to spec, the testers for not testing the worst-case scenario or the people that maintain or operate the building or bridge? How might we use disasters from the world of civil engineering to learn about better ways of architecting software systems?

Here are four well known examples of architectural disasters (resulting in increasing loss of life) from the world of civil engineering:
  1. The Millenium Bridge in London, a steel suspension bridge for pedestrians across the Thames. Construction of the bridge began in 1998, with the opening on 10 June 2000. Two days after the bridge opened the participants in a charity walk felt an unexpected swaying motion. The bridge was closed for almost two years while modifications were made to eliminate the "wobble" which was caused by a positive feedback phenomenon, known as Synchronous Lateral Excitation. The natural sway motion of people walking caused small sideways oscillations which in turn caused people on the bridge to sway in step increasing the amplitude of the bridge oscillations and continually reinforcing the effect. Engineers added dampers to the bridge to prevent the horizontal and vertical movement. No people or animals were injured in this incident.
  2. The Tacoma Narrows Bridge was opened to traffic on July 1st 1940 and collapsed four months later. At the time of its construction the bridge was the third longest suspension bridge in the world. Even from the time the deck was built, it began to move vertically in windy conditions, which led to it being given the nickname Galloping Gertie. Several measures aimed at stopping the motion were ineffective, and the bridge's main span finally collapsed under 40 mph wind conditions on November 7, 1940. No people were injured in this incident but a dog was killed.
  3. On 28 January 2006, the roof of one of the buildings at the Katowice International Fair collapsed in Katowice, Poland. There were 700 people in the hall at the time. The collapse was due to the weight of the snow on the roof. A later inquiry found numerous design and construction flaws that contributed to the speed of collapse. 65 people were killed when the roof collapsed.
  4. The twin towers of the World Trade Center (WTC) in downtown Manhattan collapsed on September 11 2001when al-Qaeda terrorists hijacked two commercial passenger jets and flew them into the skyscrapers. A government report that looked at the collapse declared that the WTC design had been sound and attributed the collapses to "extraordinary factors beyond the control of the builders". 2,752 people died, including all 157 passengers and crew aboard the two airplanes.
In at least one of these cases (the Katowice International Fair building) various people (including the designers) have been indicted for "directly endangering lives of other people” and face up to 12 years of prison. They are also charging the buildings operator for "gross negligence" in not removing snow quickly enough.

So what can we learn from these natural and man made disasters and apply to the world of software architecture? In each of these cases the constructions were based on well known "patterns" (suspension bridges, trade halls and skyscrapers have all successfully been built before and have not collapsed). What was different in each of these cases was that the non-functional characteristics were not taken into account. In the case of the bridges, oscillations caused by external factors (people and winds) were not adequately catered for. In the case of the trade hall in Katowice the building's roof was not engineered to handle the additional weight caused by snow. Finally, in the case of the WTC, the impact of a modern passenger jet, fully laden with fuel, crashing into the building was simply not conceived of (although interestingly an "aircraft-impact analysis", involving the impact of a Boeing 707 at 600 mph was actually done which concluded that although there would "a horrendous fire" and "a lot of people would be killed," the building itself would not collapse. Here are some lessons I would draw from these incidents and how we might relate them to the field of software architecture:
  1. Architects need to take into account all non-functional requirements. Obviously this is easier said than done. Who would have thought of such an unexpected event as a passenger jet crashing into a skyscraper? Actually, to their credit, the buildings architects did but what they lacked was the ability to properly model the effect of such impacts on the structures, especially the effects of the fires.
  2. For complex systems, architects should build models to model all aspects of the architecture. Tools appropriate to the task should be deployed and the right "level" of modelling needs to be done. Prototyping as a means of testing new or interesting technical challenges should also be adopted.
  3. Designers should faithfully implement the architectural blueprints and the architect should remain on the project during the design and implementation phases to check their blueprints are implemented as expected.
  4. Testing should be taken into account early and thought given to how the non-functional characteristics can be tested. Real limits should be applied taking into account the worst case (but realistic) scenario.
  5. Operations and maintenance should be involved from an early stage to make sure they are aware of the impact of unexpected events (for example a complete loss of all systems because of an aircraft crashing on the data centre) and have operational procedures in place to address such events.
As a final, and sobering, footnote to the above here's a quote from a report produced by the British Computer Society and Royal Academy of Engineers called The Challenges of Complex IT Projects.

"Compared with other branches of engineering in their formative years, not enough people (are known to) die from software errors. It is much easier to hide a failed software project than a collapsing bridge or an exploding chemical plant."

The implications of this statement would seem to be that it's only when software has major, and very public, failures that people will really take note and maybe start to address problems before they occur. There are plenty of learning points (anti-patterns) in other industries that we can learn from and should probably do so before we start having major software errors that cause loss of life.

You may be interested in the follow up to the above report which describes some success stories and why they worked (just in case you thought it was all bad).


    Friday, November 5, 2010

    On Being a Versatilist

    The world is full of wicked problems. As stated previously a wicked problem is one that is:
    • Unique
    • Difficult to define
    • Linked to other problems
    • Not always clear when its been solved
    Some wicked problems can benefit from the reasoned application of information technology to help in solving them. Solving wicked problems needs an innovative approach and the use of design thinking. A versatilist is someone who knows how to apply design thinking and can orchestrate the skills of multiple disciplines in solving wicked problems. A versatilist is also someone who:
    • Applies both left (logical) and right (artistic) brain thinking to the problem.
    • Uses rapid prototyping to test out solutions.
    • Understands that everything is connected to everything else and that sometimes solving one problem results in many more.
    • Is not afraid to disrupt the status quo and risk ridicule from his peers.
    • Is not afraid to propose a solution to a problem before the problem is completely understood.
    • Iterates (maybe many times) rather than expecting to arrive at a solution following a (simple-minded) analysis of the problem.
    The world needs more versatilists if we are to solve the truly wicked problems. Solving wicked problems is one of the things we must do if we are to build a Smarter Planet.