Monthly Archives: August 2013

Architectural lessons to draw from building In Tempo

20130813-004550.jpg
Move over Winchester House, In Tempo is well positioned to take over your spot as the favorite story used in Enterprise Architecture. In Tempo’s construction began in 2007 and was initially designed for 20 floors. Today, it is about 94% complete, and has additional 27 floors built on top. Level 21 onwards are, however, only accessible via the stairs. There was no way to extend the elevators upwards. It was said that the architects had since resigned.

There are certainly a lot to learn from In Tempo. For a start, think scalability. As architects, our design must be scalable. It is extremely expensive to include scalability as an afterthought. In the case of In Tempo, the residents from level 21 onwards would be inconvenienced daily. And it would be very difficult to get buyers for those floors. Imagine the horrors of building a software solution that cannot be scaled horizontally nor vertically.

Even if the architects didn’t factor in scalability, there was still an opportunity when the additional 27 floors were being planned. Change management obviously failed. The impact analysis, if any, were not sufficient. Such a change shouldn’t have been approved. Or if it must proceed, the design need to extend to include elevator services for the additional floors.

Would the completed In Tempo pass the fit-for-purpose and fit-for-use tests? Maybe only partially, for those units level 20 and below.

In Tempo is a good modern day example that illustrates the importance of having the architecture (blueprint) well designed.

Sources: The Guardian, Wikipedia
Image Credit: devacacionesypuentes.com

Advertisements

Architectural lessons to draw from building In Tempo

20130813-004550.jpg
Move over Winchester House, In Tempo is well positioned to take over your spot as the favorite story used in Enterprise Architecture. In Tempo’s construction began in 2007 and was initially designed for 20 floors. Today, it is about 94% complete, and has additional 27 floors built on top. Level 21 onwards are, however, only accessible via the stairs. There was no way to extend the elevators upwards. It was said that the architects had since resigned.

There are certainly a lot to learn from In Tempo. For a start, think scalability. As architects, our design must be scalable. It is extremely expensive to include scalability as an afterthought. In the case of In Tempo, the residents from level 21 onwards would be inconvenienced daily. And it would be very difficult to get buyers for those floors. Imagine the horrors of building a software solution that cannot be scaled horizontally nor vertically.

Even if the architects didn’t factor in scalability, there was still an opportunity when the additional 27 floors were being planned. Change management obviously failed. The impact analysis, if any, were not sufficient. Such a change shouldn’t have been approved. Or if it must proceed, the design need to extend to include elevator services for the additional floors.

Would the completed In Tempo pass the fit-for-purpose and fit-for-use tests? Maybe only partially, for those units level 20 and below.

In Tempo is a good modern day example that illustrates the importance of having the architecture (blueprint) well designed.

Sources: The Guardian, Wikipedia
Image Credit: devacacionesypuentes.com


Incident versus Problem Management

Years back when I was still earning a living through writing and maintaining codes, I’d a colleague, a System Engineer who is looking after the servers that our application was running on. As with any application, ours had bugs too. And, occasionally, the bugs surfaced, bring about a service disruption. This affected quite a lot of users, and naturally our first response was to restore the service (incident management).

Our colleague, however, was more focused on problem resolution. A scheduled weekly restart at off-peak hours were not acceptable. Likewise, we cannot be always increasing the heap size to address OOM issue. He would insist on fixing the problem instead of having quick fixes. At that point of time, these did frustrate me.

Back then, I was still green and lacked ITIL knowledge. Now, I begin to appreciate that our quick fix or workarounds were not wrong, our intention was to quickly restore the service so that business continues as usual. My colleague was not wrong either, for insisting on problem resolution.

Through the hard way of learning, I come to realize that not all problems have a solution and sometimes, a workaround could actually become the permanent fix to a problem. Not to mention that problem resolution takes time, and while searching for the answer, business must continue and hence, a workaround if available can provide the required time.

Perhaps what was missing at that time was the ITIL training for both the application teams and our system engineers. If we knew what were incident and problem management, perhaps both teams could have worked together with better synergy.