architect roles

The Fall and Rise of the Full Stack Architect

Peter Cripps architecture , , ,

strawberry-layer-cake

Almost three years ago to the day on here I wrote a post called Happy 2013 and Welcome to the Fifth Age! The ‘ages’ of (commercial) computing discussed there were:

  • First Age: The Mainframe Age (1960 – 1975)
  • Second Age: The Mini Computer Age (1975 – 1990)
  • Third Age: The Client-Server Age (1990 – 2000)
  • Fourth Age: The Internet Age (2000 – 2010)
  • Fifth Age: The Mobile Age (2010 – 20??)

One of the things I wrote in that article was this:

“Until a true multi-platform technology such as HTML5 is mature enough, we are in a complex world with lots of new and rapidly changing technologies to get to grips with as well as needing to understand how the new stuff integrates with all the old legacy stuff (again). In other words, a world which we as architects know and love and thrive in.”

So, three years later, are we any closer to having a multi-platform technology? Where does cloud computing fit into all of this and is multi-platform technology making the world get more or less complex for us as architects?

In this post I argue that cloud computing is actually taking us to an age where rather than having to spend our time dealing with the complexities of the different layers of architecture we can be better utilised by focussing on delivering business value in the form of new and innovative services. In other words, rather than us having to specialise as layer architects we can become full-stack architects who create value rather than unwanted or misplaced technology. Let’s explore this further.

The idea of the full stack architect.

Vitruvius, the Roman architect and civil engineer, defined the role of the architect thus:

“The ideal architect should be a [person] of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of juriconsults, familiar with astronomy and astronomical calculations.”

Vitruvius also believed that an architect should focus on three central themes when preparing a design for a building: firmitas (strength), utilitas (functionality), and venustas (beauty).

vitruvian man
Vitruvian Man by Leonardo da Vinci

For Vitruvius then the architect was a multi-disciplined person knowledgable of both the arts and sciences. Architecture was not just about functionality and strength but beauty as well. If such a person actually existed then they had a fairly complete picture of the whole ‘stack’ of things that needed to be considered when architecting a new structure.

So how does all this relate to IT?

In the first age of computing (roughly 1960 – 1975) life was relatively simple. There was a mainframe computer hidden away in the basement of a company managed by a dedicated team of operators who guarded their prized possession with great care and controlled who had access to it and when. You were limited by what you could do with these systems not only by cost and availability but also by the fact that their architectures were fixed and the choice of programming languages (Cobol, PL/I and assembler come to mind) to make them do things was also pretty limited. The architect (should such a role have actually existed then) had a fairly simple task as their options were relatively limited and the number of architectural decisions that needed to be made were correspondingly fairly straight forward. Like Vitruvias’ architect one could see that it would be fairly straight forward to understand the full compute stack upon which business applications needed to run.

Indeed, as the understanding of these computing engines increased you could imagine that the knowledge of the architects and programmers who built systems around these workhorses of the first age reached something of a ‘plateau of productivity’*.

Architecture Stacks 3

However things were about to get a whole lot more complicated.

The fall of the full stack architect.

As IT moved into its second age and beyond (i.e. with the advent of mini computers, personal computers, client-server, the web and early days of the internet) the breadth and complexity of the systems that were built increased. This is not just because of the growth in the number of programming languages, compute platforms and technology providers but also because each age has built another layer on the previous one. The computers from a previous age never go away, they just become the legacy that subsequent ages must deal with. Complexity has also increased because of the pervasiveness of computers. In the fifth age the number of people whose lives are now affected by these machines is orders of magnitude greater than it was in the first age.

All of this has led to niches and specialisms that were inconceivable in the early age of computing. As a result, architecting systems also became more complex giving rise to what have been termed ‘layer’ architects whose specialities were application architecture, infrastructure architecture, middleware architecture and so on.

Architecture Stacks

Whole professions have been built around these disciplines leading to more and more specialisation. Inevitably this has led to a number of things:

  1. The need for communications between the disciplines (and for them to understand each others ‘language’).
  2. As more knowledge accrues in one discipline, and people specialise in it more, it becomes harder for inter-disciplinary understanding to happen.
  3. Architects became hyper-specialised in their own discipline (layer) leading to a kind of ‘peak of inflated expectations’* (at least amongst practitioners of each discipline) as to what they could achieve using the technology they were so well versed in but something of a ‘trough of disillusionment’* to the business (who paid for those systems) when they did not deliver the expected capabilities and came in over cost and behind schedule.

Architecture Stacks 4

So what of the mobile and cloud age which we now find ourselves in?

The rise of the full stack architect.

As the stack we need to deal with has become more ‘cloudified’ and we have moved from Infrastructure as a Service (IaaS) to Platform as a Service (PaaS) it has become easier to understand the full stack as an architect. We can, to some extent, take for granted the lower, specialised parts of the stack and focus on the applications and data that are the differentiators for a business.

Architecture Stacks 2

We no longer have to worry about what type of server to use or even what operating system or programming environments have to be selected. Instead we can focus on what the business needs and how that need can be satisfied by technology. With the right tools and the right cloud platforms we can hopefully climb the ‘slope of enlightenment’ and reach a new ‘plateau of productivity’*.

Architecture Stacks 5

As Neal Ford, Software Architect at Thoughtworks says in this video:

“Architecture has become much more interesting now because it’s become more encompassing … it’s trying to solve real problems rather than play with abstractions.”

 

I believe that the fifth age of computing really has the potential to take us to a new plateau of productivity and hopefully allow all of us to be architects described by this great definition from the author, marketeer and blogger Seth Godin:

“Architects take existing components and assemble them in interesting and important ways.”

What interesting and important things are you going to do in this age of computing?

* Diagrams and terms borrowed from Gartner’s hype cycle.

A Cloudy Conversation with My Mum

Peter Cripps architecture ,

Traditionally (and I’m being careful not to over-generalise here) parents of the Baby Boomer generation are not as tech savvy as the Boomers (age 50 – 60), Gen X’ers (35 – 49) and certainly Millenials (21 – 34). This being the generation that grew up with “the wireless”, corded telephones (with a rotary dial) and black and white televisions with diminutive screens. Technology however is invading more and more on their lives as ‘webs’, ‘tablets’ and ‘clouds’ encroach into what they read and hear.

IT, like any profession, is guilty of creating it’s own language, supposedly to help those in the know understand what each other are talking about in a short hand form but often at the expense of confusing the hell out of those on the outside. As hinted at above IT is worse than most other professions because rather than create new words it seems particularly good at hijacking existing ones and then changing their meaning completely!

‘The Cloud’ is one of the more recent terms to jump from mainstream into IT and is now making its way back into mainstream with its new meaning. This being the case I thought the following imaginary conversation between myself and my mum (a Boomer parent) given my recent new job* might be fun to envisage. Here’s how it might start…

Cloud Architect and Mum

Here’s how it might carry on…

Me: “Ha, ha very funny mum but seriously, that is what I’m doing now”.

Mum: “Alright then dear what does a ‘Cloud Architect’ do?”

Me: “Well ‘cloud computing’ is what people are talking about now for how they use computers and can get access to programs. Rather than companies having to buy lots of expensive computers for their business they can get what they need, when they need it from the cloud. It’s meant to be cheaper and more flexible.”

Mum: “Hmmm, but why is it called ‘the cloud’ and I still don’t understand what you are doing with it?”

Me: “Not sure where the name came from to be honest mum, I guess it’s because the computers are now out there and all around us, just like clouds are”. At this point I look out of the window and see a clear blue sky without a cloud in sight but quickly carry on. “People compare it with how you get your electricity and water – you just flick a switch or turn on the tap and its there, ready and waiting for when you want to use it.”

Mum: “Yes I need to talk to you about my electricity, I had a nice man on the phone the other day telling me I was probably paying too much for that, now where did I put that bill I was going to show you…”

Me: “Don’t worry mum, I can check that on the Internet, I can find out if there are any better deals for you.”

Mum: “So will you do that using one of these clouds?”

Me “Well the company that I contact to do the check for you might well be using computers and programs that are in the cloud yes. It would mean they don’t have to buy and maintain lots of expensive computers themselves but let someone else deal with that.”

Mum: “Well it all sounds a bit complicated to me dear and anyway, you still haven’t told me what you are doing now?”

Me: “Oh yes. Well I’m supposed to be helping people work out how they can make use of cloud computing and helping them move the computers they might have in their own offices today to make use of ones IBM have in the cloud. It’s meant to help them save money and do things a bit quicker.”

Mum: “I don’t know why everyone is in such a rush these days – people should slow down a bit, walk not run everywhere.”

Me: “Yes, you’re probably right about that mum but anyway have a look at this. It’s a video some of my colleagues from IBM made and it explains what cloud computing is.”

Mum: “Alright dear, but it won’t be on long will it – I want to watch Countdown in a minute.”

*IBM has gone through another of its tectonic shifts of late creating a number of new business units as well as job roles, including that of ‘Cloud Architect’.

The Three C’s of IT Architects

Peter Cripps architecture, creativity

This is a completely unscientific observation but over the years of being an architect I have observed the following characteristics in people that claim to be members of this profession.  I refer to these as the three C’s of being an IT architect. Some people have only one of these but most have a mix of all three, with maybe one being dominant. The three C’s are: 

  • Creatives – These are the ideas people, that are keen to do new stuff. They are the people that build the solutions that address the business requirements. They have an intimate knowledge of technology (in their particular area of interest or concern) and want to use that technology. If you don’t have these people in your project/team/organisation then nothing will actually get done. The downside of having too much of this attribute is that eventually you have to stop creating and ship something so you need to know when to stop. 
  • Consumers – These are the people that use what the creatives create. Whilst they may not create anything new this type of architect is not without merit. They often combine what others have done in new and innovative ways. We sometimes refer to this activity as reuse, one of the Holy Grails of IT so it is not to be underestimated. If you don’t have these people in your project/team/organisation then chances are the ideas from the creatives will not get fully realised. The downside of having too much of this attribute is that there is a limit to what you can build out of reusing stuff and eventually someone has to come up with some new ideas. 
  • Connectors – These are the people that don’t create or reuse but know people that can do these things and join the two together. Again this is not to be an underestimated skill. After all if a seller cannot find a buyer what’s the point! If you don’t have these people in your project/team/organisation then the two previous types won’t find each other. The downside of having too much of this attribute is that you ain’t going to do anything if all you do is push ideas of others around without creating or reusing things.

From my observations I reckon a ratio of Creatives to Consumers to Connectors needs to be something like 4:2:1.

Incidentally, my guess is that these actually apply to other professions as well but I have even less scientific evidence about those.

Working with Zuck

Peter Cripps comment ,

In this article Facebook software engineer Andrew Bosworth describes what its like to work with the founder and architect of Facebook, Mark Zuckerberg (‘Zuck’). The attributes that Bosworth ascribes to Zuckerberg, that by implication are at least partly the reasons for his galactic success, are ones which I believe all architects should aspire to. Here are the four attributes with my spin on how I think they apply to architects in general:

  1. Zuck expects debate. A good architect is not a dictator but should expect, and be happy to participate in, debate. Be open to new ideas and don’t think you have all the answers. At the same time be robust in pushing back on any ideas to test out peoples thinking thoroughly. Be aware of people who play Devil’s Advocate and who argue just to be heard or are negative without proposing viable, alternative solutions.
  2. Zuck isn’t sentimental. It’s sometimes easy to be too wedded to an idea or your favourite technology. Be prepared to scrap these and to throw things away if they no longer meet the requirements or something better has come along. As Bosworth says of Zuckerman he is “fearless about disrupting the status quo and tireless in his pursuit of building the right thing, even in an ever-changing landscape”.
  3. Zuck experiences things contextually. As architects we often talk about ideas very abstractly and prefer to talk in generalities rather than specifics. Bad idea! A good architect (and indeed architecture) should be firmly grounded in reality and be backed up by actual products, prototypes, even working code! The best way of convincing someone of your idea is to build something that you can give them to play with.
  4. Zuck pushes people. People can often do more than they think (sometimes in less time than they think as well). The important thing is to be focussed on the problem and not the distractions that your job (as opposed to your work) may bring.

Architect Roles

Peter Cripps architecture ,

The IT industry tends to bandy around a number of different architect roles. Working with different clients, as I do, I find there is often confusion about what all these roles do. I find the following diagram helps to explain the different roles that IT architects take. Of course the important point to emphasise is that these are roles not job titles. In other words, one person may take on multiple roles on any given project so this is not meant to be a a way of generating architecture jobs but is merely a way of showing the different skill areas or disciplines that need to be applied when building a solution that is comprised of multiple layers.