Is cloud computing the end of Internet utopia?

Cloud computing may be unavoidable but for all the IaaS, SaaS and (to a lesser extent) PaaS services out there, we're not quite there yet, at least at the corporate level. In fact, despite a growing adoption of out-hosted services there aren’t all that many corporations that have gotten rid of their data centres.

So what is then missing? A signature, really. The problem is that nobody wants to sign off what may be a death sentence for the business. So next question is, what is required to get that signature? I can only see one possibility: the one thing that nobody wants in the Internet right now... regulation. Once this is accepted, everything will come to place. The "cyber-world" will be ever more like our "physical" world. Even insurance companies may take their part and cover for data leakage, manipulation or unavailability. And the Internet will finally be a normal part of our lives.

But will people ever want regulation? It is certainly about time that our children get the protection that they deserve on the Internet, and that criminals start getting caught. No doubt that a hacker would think twice before defacing a web site or impersonating somebody else if he could get jailed for it. It's all about value at risk. Let’s face it, right now there is virtually no risk in attacking who or whatever a hacker wants, and that makes it really hard and often expensive for businesses and people to defend themselves.

In my opinion it is long overdue because only with security can people and institutions thrive.

The challenge is to create a secure environment while keeping privacy and freedom of expression. And as far as I can see that cannot be achieved only with so-called self-regulation.

"If you don't develop an architecture, you will get one anyway – and you might not like what you get!" (Linda Northrop, SEI)

Many times have I been asked what „IT Architecture” is, or what is the difference to system design, and what does an architect do that is different from an engineer.

Sometimes the IT architect is simply an experienced system engineer. In fact I can’t really think of someone doing IT architecture without having been exposed to the many aspects of engineering, to many different technologies and patterns, and not knowing at least a few of them in depth. There is however a difference between architecture and engineering. In fact there are many sides to engineering; for example, someone with a main background in software development tends to look at things differently from someone that comes from network design, IT operations or IT security.

Once you become an architect you are expected to deal with all of these functions and to understand them well enough to propose decisions.

For instance, security often wants their systems (controls) to be based on appliances because they tend to be more secure. However Operations will argue that they can’t manage so many boxes and would prefer instead to have standard images and virtualisation. As for the development team, they always need the latest versions because the older ones have either run out of support or are not good enough.

The architect has to consider all of these points of view and many more when designing a system or working on a change to an existing system. And this is just inside the IT department. The customers have their own concerns, which are not necessarily related to security, technical component versions or release cycles. They need to have their tools and information available, quickly and in an uncomplicated way. In addition, many times different groups of customers have conflicting requirements.

This is where architecture comes into play. It’s all about managing trade-offs. The architect has to understand the concerns or viewpoints of each stakeholder and design a system that takes all of those aspects into consideration.

Architecture is mainly concerned with non-functional requirements, or system qualities. When you buy a car you want it to be fast, beautiful, big, comfortable, reliable, secure, eco-friendly, not depreciating too much, with low maintenance, lots of extras… and cheap. You have probably seen a panoramic roof which you liked in some model, tinted glasses, MP3 connectivity, built-in GPS, a fridge, Bluetooth, parking aids. You want it all but then you realise that you need to compromise somewhere. So in the end you (sometimes) get the car that matches your most important qualities within budget. If the balance is not right you know you will regret it later, and probably end up replacing it and spending a lot more than you wanted.

So that’s the role of the architect: to find the right balance given the priorities that are communicated by each stakeholder and on which there must be agreement at design time.

Can you build a system without taking care of architecture? You certainly can. But inevitably the system will be unbalanced, neglecting the interests of key stakeholders, and problems will soon emerge. Like Linda Northrop from the SEI wrote “If you don't develop an architecture, you will get one anyway – and you might not like what you get!” (http://csse.usc.edu/gsaw/gsaw2003/s13/northrop.pdf).

There are countless examples of badly or non-architected systems. The consequence is that they usually have to be replaced quickly. That is what architecture tries to solve.

Architecture and agility: the ultimate trade-off?

Architecture-centric design is meant to minimise the probability that structural changes in the system will occur.

Changes in a system, as pointed out in the great “Software Architecture in Practice” book from the Software Engineering Institute (SEI), can be either:

• Local - affecting only one element;
• Non-local - affecting multiple elements but not the architecture itself; or,
• Architectural - affecting the pattern of the architecture, i.e. the “fundamental ways in which the elements interact with each other”.

The system structure should therefore be created in a way that it minimises the likelihood of architectural changes. If possible only local changes should be necessary. 

Of course this requires design to be done upfront which is something that some “agilists” love to hate.

In fact, by using an architecture-centric approach such as the Attribute Driven Design (ADD) the system is decomposed recursively into components in a way that the desired qualities are achieved. The system can then be developed and prototyped incrementally like a skeleton into which the components can be added, tested and refined until the final product is achieved. This also allows components to be developed externally with minimal risk.

This kind of approach ensures that the system qualities, or non-functional requirements, are met, also in expected growth scenarios.

At first glance it contrasts with agile methodologies such as Scrum. These are based on developing in small iterations that build functionality incrementally. Each of these “sprints” is a small project that takes a chuck of requirements, or user stories, from the product backlog, and provides an increment to the product. Requirements are not very clear until they get prioritised and included in a sprint.

This approach is usually focused on functional requirements but it doesn’t have to be. As long the architect is involved in the development process, the backlog prioritisation is aligned with architecture scenario-based priorities, and enough design decisions are done upfront, there’s no reason why Scrum and Architecture can’t provide synergies. Moreover, architecture intermediate reviews or even trade-off analyses can be performed during the development process, after certain iterations.

After all, agile methodologies are frequently applied in projects where the architecture is implicitly defined anyway, via frameworks such as Spring, Hibernate, Grails, etc. So the idea of "no design upfront" doesn't really apply.