 |
| The Vasa from the Bow by Javier Kohen |
Walking around in the museum and reading why the Vasa sunk felt like reading about failed IT projects. Since we love analogies in IT, I will compare the construction of the Vasa to an IT project and see how architecture can help us in realizing an IT project successfully. Before we begin, a disclaimer on the accuracy of the history and construction of the Vasa in this blog is in order since I'm not an historian and neither a shipbuilder.
Good design doesn't mean good architecture: Why design alone isn't enough
You can hire experienced craftsmen to design and build a ship. Those people can be top of the line in their respective area such as armament, rope-making, carpeting, and sail-making. Putting together such a team doesn’t automatically result in a good ship however. For example, while each of the ships canons could have been of great quality and have an enormous range, placing too much heavy canons on the upper deck and having too little weight in the bottom of the ship can cause instability.
Architecture and design are often intermixed. Architecture is about the overall structure of a system and the rules and principles that govern the system as a whole. Design is more about the detailed structure of a particular subsystem or smaller component. Suppose we create an IT system to support the Customer Care department. The system can be made up of a Document Management System, Web Portal, and Case Management System. While all the different components can work really well themselves from both functional and technical perspective, you need to make an effort to make these components work together and also in such a way that supports Customer Care. Bad design will probably mean a bad solution. Good design however can still result in a bad solution. We need overall structure and coherence between the parts of an IT system to make them work together optimally and create a valuable solution. The various IT systems in an organization need to work together to support the enterprise. This is what architecture is about.
Using best-practices: Applying reference architecture
In the time period in which the Vasa was built, knowledge and experience were mostly in the heads of masters and passed on to apprentices. Knowledge and experience wasn't as broadly and readily available as it is nowadays. Also there weren't many ships built in Sweden like the Vasa that had multiple gun decks. When the main ship-builder Henrik Hybertsson died and his less experienced successor took over, he didn't have much best-practices or blueprints available for completing the Vasa.
In IT and other fields we have reference architectures that contain best-practices and guidelines to implement systems. Examples of reference architectures are eTOM for telcos and NORA for Dutch governments. Such blueprints speed up design and help you avoid common pitfalls.
On a side note, I recently participated in a podcast on reference architectures hosted by Bob Rhubart. One of the statements was that you shouldn’t apply reference architectures in an organization or project without first validating the applicability of the guidelines. Reference architectures have their merits, but can be too abstract, too elaborate, or too complex for a particular project or particular organization. However, Reference architectures are useful tools that can be applied to solve particular problems.
Not only managers, but also architects need to have an opinion on how and when to meet requirements
King Gustavus Adolphus of Sweden had some pretty strong requirements for the Vasa. It should have massive firepower and be constructed in a short time period. Requirements such as dimensions were frequently changed over time. It's interesting to review these requirements when we take a step back. Requirements are often derived from a particular goal or strategy. If the goal is to achieve naval superiority in the Baltic region, an alternative to a few big battleships like the Vasa could be the deployment of a larger number of smaller war vessels that can be created with the same total budget and within the same timeframe. Perhaps these vessels have less firepower but can cover a larger part of the Baltic region.
Architects can help make such cost/benefit analysis in IT projects or within the enterprise as a whole and align projects to the overall strategy.
If project managers say no to requirements it is usually because of time or budget constraints. Managers often need to balance quality, price and time. Besides budget and time one can also validate the realization of requirements based on compliance with architectural guidelines. If Java is the defacto standard then building a perfect PHP system that realizes all requirements and is delivered in time and within budget can still cause serious problems. For example when an enterprise doesn’t have the knowledge to correctly administer PHP systems and has a policy of not outsourcing system administration. Architects should look at the feasibility of requirements from the structures, principles, and boundaries they have set up in an architecture. Architects should propose alternatives that better fit the architecture. Architects should also stand up to managers if requirements don’t fit enterprise policies.
Also test architecture, not only functional and technical requirements
It is said that the stability test of the Vasa (men running up and down the deck) was cancelled shortly after it began because the ship almost tumbled over. Still construction and launch of the Vasa continued.
IT projects test systems to validate that functional and technical requirements are met. They furthermore test to verify that changes to the IT system do not introduce faults and cause regression. It is somewhat less obvious to test the architecture or architectural constraints and principles a IT system should adhere to. It can still be that all functional and technical requirements are met, but that e.g. applying changes after taking an IT system in production takes way too long. This can be an indicator of a flaw in the IT systems architecture that has big impact.
For example, a solution architecture could state that services should be reusable by future consumers. At first these services could only be used by a single consumer. We can actually test if these services are reusable (or whether they might be too specific to be used by future consumers) by investigating the service contract and interface.
To summarize: good architecture helps making IT projects successful, good design alone isn’t enough, we can learn lessons from other fields for applying architecture, and finally make sure you visit the Vasa museum when you’re in Stockholm!
