I thought that the mental comparison between construction and systems was something that everyone had in their minds when looking at the maturity of architecture (which has been recently the scope of a recent engagement for a client).
The other day I was talking to a fellow architect and it surprised me that he had never made that metal comparison, so I guess a couple of paragraphs on the topic could be interesting.
 
So here’s the key thought: we IT Solution Architects are professional equivalents to our counterparts in the construction world, the Architects… what a revelation! J
It needs to be clarified that what we ordinarily understand as a “real world” architect, the one that architects buildings, bridges, airports, etc. would be the equivalent of the Solution Architect in the systems world.
 
In IT we have another half dozen other architect roles (Security, Application, Integration, Infrastructure, Data, Business); those have also their equivalent in the construction world, but in that business they’re mostly known as Engineers (I guess the fact that constructions relates to tangible physical elements makes it more of an engineering domain). But effectively it is the same approach: as a Solution Architect is responsible for delivering a balanced system design that addresses the business requirements across the technology and operational disciplines and drags in domain architects as needed, the construction architect does the exact same thing: he brings in the Security Engineers, the Electrical Engineer, etc. and each of those professionals provide their input into the overall blueprint for the building in question.
 
Hemienu: Vizier, Master of Works, and architect of the Great PyramidIt is important to highlight that the construction architecture discipline has been around for a very long time now, without being precise at least 5,000 years. And don’t try to tell me that while construction is indeed an old activity, architecture is not. Not true; it may have not been the mature discipline it is right now, but it’s been around for quite a while (think of the Chinese Wall, the Pyramids, the Coliseum, all those were definitely not architecture-less feats).
 
Obviously construction architecture has matured to incredible levels nowadays; just look for example how successful the construction work for the Olympics in London has been. The level of sophistication of the design patterns; the clear boundaries between the disciplines; the crystal clear definition of the design deliverables; the standardization of tools and techniques; the precision and control of delivery; the absolute repeatability and predictability of it all…
How I’d wish my work in the system architecture space would run under such advanced and controlled frameworks… How I’d wish that whenever I start a new project I wouldn’t have this hopeless feeling that I’m entering into unchartered territory again and again and again…
 
So what else is new? What is it so exciting about drawing this comparison? What’s the bottom-line?
Well, the bottom line is that I draw consolation in that IT Solution Architecture is in its absolute infancy, just short of 70 years against those 5 millennia!
So whenever I get frustrated by my project issues, by my inability to prevent the same issues to creep over and over again in my designs, by how frustrated my project team, my stakeholders and ultimately my client get through the whole process, I always bring this image to my mind.
The image is that I’m not the equivalent to those smooth and trendy architecture boutiques effortlessly designing incredible stadia with an amazing level of complexity; the image is that I’m more like that architect the pharaoh commissioned to build the pyramid for his mortal body so long ago.
I can very easily imagine and get sympathetic with the level of absolute difficulty that challenge surely was for that anonymous architect, and sadly or not, that image brings peace and quiet to my soul… J
 
There you go, 5,000 years of experience for my discipline to catch on but also a certainty that at some point in time we will reach that dreamed-of maturity*… though not all of it may come true in my life-time… shame!
 
As those architects of old were constantly told… “the damn thing it’s just a pile of blocks, it surely can’t be that difficult to put together?”
J
 
* maturity that will enable us to apply those exciting building architectural concepts. Like the design principle of “pace layering” (http://en.wikipedia.org/wiki/shearing_layers), that allows the architect to define the different components of the building in a way by which faster changing layers, like the floor plans or seat distribution, are able to slip and evolved unobstructed by the slower changing layers, such as the building foundations… right now in IT architecture these concepts are just mostly aspirational, but their time is coming. In our current maturity state all layers in a solution change every day, if not every hour, during and after delivery, and little consideration is given to create durable structures… it’s like we’re constantly tearing down whole buildings and replacing them with new ones. Which is obviously one of the strengths of IT in itself, the pace and depth of change that systems support, but we definitely need to learn to architect in ways that enable us to evolve our systems by renewing “facades” and “floor plans”, while keeping long lasting components underneath for longer periods, foundations that are able and ready to support the frequent change on top of them.
 
PS: I haven’t touched upon Enterprise Architecture in the article, my view is that EA compares to the city planning activities that our beloved councils across the country try to deliver for our cities… I guess in one specific space it seems IT has already caught up and is probably doing a better job than our real world counterparts!
 
PS2: when drawing my comparison to pyramid architects, I humbly think of the lesser pieces, the ones that haven’t stood the test of time, the ones built for the pharaohs no one remembers… I haven’t really architected a system that will still be around and that technology tourists will explore, analyze and admire 3,000 years from today… but watch this space!

As Smart421’s partnership with Amazon Web Services (AWS) is slowly moving from pure infrastructure work into full cloud-based solution architecture design, I’ve recently spent some time analysing their IaaS platform from that angle.

My immediate goal with this was to better understand how the infrastructure side of my solutions are going to be affected by this paradigm shift moving forward. In other words, I was preparing myself to have a conversation with my infrastructure architect, let’s call him Jimmy, and not be caught showing my complete ignorance on the matter… again. :D

To my surprise I’ve found out that AWS, and IaaS in general, has a much more profound effect on my end to end solution design than just infrastructure, the key being how the “Servicelisation of Infrastructure” (sorry) provides a great mechanism to finally comprehensively address NFRs at the application view and close what I use to call “the leap of faith into the iron”… let me explain that.

We all know by now that our solution design is always going to start by a business architecture exercise that will feed the solution requirements, including functional and data requirements but also those dreaded non-functional requirements (NFRs)**, to our data and application architects, who in turn will produce the data model and component view, and that will be followed by our infrastructure architect, who will come up with the technical platform all those application components will run. Fine and dandy, but…

Dreaded NFRs? Why? Well, while it is quite straightforward for our data architect to create a logical data model out of the data requirements, or it is just BAU for our application architect to derive the system capabilities to cover the functional requirements, it is not easy for any of the two to cope with those NFRs… How does our data architect react to a NFR such as “the system shall process 2 million transactions per day”? Or what does our application architect think of the NFR “the site will provide the same response times independently of the location of the user”? Well, in most of the cases the reaction will be “Well, that’s for infrastructure to answer, isn’t it? Let’s pass those ugly things to Jimmy, he’ll know what to do with them…”.

So that leaves us with that situation we’ve been so many times, in which we provide a very detailed application architecture to Jimmy alongside a very long list of performance related requirements, hoping, and here’s the leap of faith I was referring to earlier, that our infrastructure hero will know how to put a lot of heavy equipment together that somehow magically will achieve those very ambitious performance goals…please raise your hands if that has never happened to you, or if that hasn’t inevitably ended up in all sort of performance issues detected just too late down the line, maybe a couple of weeks prior to go-live? Anyone?

Well, let’s see how Infrastructure as a Service may come to our rescue. Just do this simple exercise: go to the Amazon Web Services site and read all the documentation of the offering, all of it, trying to ignore the fact that it describes an infrastructure platform and rather set your mind-set as if you were looking at the functionalities of just another software system that needs to be part of your component architecture… Interestingly enough this made a “magic click” in my head, and suddenly I was thinking about my solution and my application architecture*** in terms of capabilities, functionalities and features that elegantly addressed all those long hated NFRs!

I’ve put this idea to test for a CMS solution I’ve been playing around with recently; I would have never typically defined capabilities such as a “Fast Access Data Access Layer” or a “Low Latency Distribution of Content” in my capabilities inventory, but suddenly my understanding of those AWS services such as ElastiCache or CloudFront made it dead simple to think about the NFRs and translate them to discrete solution components.

And what’s even more interesting is my design is not immediately coupled to the given IaaS platform as a result, not at all. As with the rest of the solution, these components and capabilities allow for a fit-gap exercise against the available options to be answered by my infrastructure architect: Do we achieve global performance by deploying the servers in our corporate data centres or maybe by deploying them in the AWS regions in the cloud? Or do I just keep my platform in a single location within my premises and use a CDN pull-zone for low latency delivery of static content? Quite a different proposition for Jimmy than the old “make it quick, boy”!

Now the problem is addressed where it should be in the design process, at the logical level, and decomposed into a set of features that achieve full traceability from the business into the application and then into the infrastructure layer and then back up again… the work of our infrastructure architect is now so much easier, as it is the predictability of our design exercise! Life is good! :D

Well just a thought in any case… I guess most of you were already through this learning, but just in case you had your own Jimmy’s suffering, this is a nice mental approach to try to bridge the gap.

* Infrastructure as a Service; I’ve focused this analysis to this type of cloud offering as it is probably where the biggest gap between architecture practices exist. In big organizations with dedicated software, middleware or platform architecture functions a similar situation will probably exist in which we could follow a similar approach with SaaS (eg. Microsoft Dynamics CRM Online) or PaaS (eg. Microsoft Azure)…

** It’s worth mentioning the usual problem of the business architecture exercise not really producing NFRs other than maybe a couple of fuzzy “it must be like really really fast” or “the site needs to look gorgeous”… this article is working on the bold assumption that our business analysts have been able to get blood out of stones and have coaxed the business into expressing real tangible NFRs to come along with the rest of requirements.

*** After all aren’t we solution architects just application architects with a good working knowledge of the other disciplines? At least I’ll confess that’s my case…

Follow

Get every new post delivered to your Inbox.

Join 1,084 other followers