Big Data and Architects Part 1: Big vs. Little Data in the Architectural Practice

The Big Picture

The image accompanying this blog is my Google Analytics map from the cities across the globe from which I have had new visitors this year: The blog is big in Samara and Almaty and of course Dunedin and Lagos. So, thank you everyone who has visited from near and far. 


There has been a lot of talk about big data and data analytics of late. I saw a talk at work the other day about metrics concerning global-cities and thought: Wow ! We all love the macro-view. It makes us feel that we are above it all. Big data nowadays is kind of like a juggernaut as online information is constantly being gathered by big, big, big firms like Google and Faceybook. Arguably Trump employed data analytics from Cambridge Analytica to win HIS election. Of course, much closer to home is AURIN.

It’s easy to get seduced by the big picture stuff and BIG DATA; it has become such a catchphrase for the academic, consulting and elite chattering classes; So, I thought I might devote a few blogs to discussing it from the architect’s perspective.

For the architect it is not so much about BIG data but in fact LITTLE data.

Little Data = Data generated within and circulating through the architect’s firm.

Architects are too small and certainly not the cloud platform or solutions we might find at Google.

I am quite interested on following Meltwater a firm that gathers and gains insights from the realm of online data that exists outside of “internal reporting systems.” I guess when I saw those words I wondered about the internal and external reporting systems of architects. Do these systems actually exist? Or, is it all just seat of the pants decision-making and guess-work in the architect’s office? Their CEO of Meltwater has written a book which looks good and can be found here.

It’s probably a good idea to start with some of the basics of what I might call Little Data pertaining to the architect’s studio. Then further blogs will cover big data, data analytics and strategic intelligence (including its politics and ethics) and most importantly how data analytics might be employed in the design studio. I might even throw in a bit of critical theory for fun.

Think of this as a crash course in data, information and knowledge management. For most architects there is probably three or four types of data that they need to gather (and scrubbed), and manage in order to make effective decisions.

1. Internal Firm Data and Information:

Information about the firm internally is really critical. Especially, given that for architects the primary input is the amount of hours worked accurate data on this is crucial. Another category of data central to the firm This can then be mapped against the fixed and variable expenses that the firm incurs in doing the work. Of course, in Australia, as is the case elsewhere, keeping time and wages records (like overtime) is an important thing to do under the Architects award.

2. Broader Industry Structure Data and Information:

This covers information about the broader Industry, other similar, or contrasting  firms and how all of these things are performing. How much profit should a firm be making, how many hours should it be spending on particular project phases? How much should be spent on marketing each year, for example, and how does this compare to other architectural firms?

Yes, all architects really need to pressure our professional associations, groupings and even governments to continually collect and distribute this kind of information about the market for architectural services.

3. External Facing Data and Information:

This includes information about potential clients, potential areas or sites of development and expertise. In the real world they call this Business Intelligence. If an architectural firm is to be entrepreneurial and anticipate future work then it needs to develop a base of research and knowledge in particular area. For any firm it is important to understand that overall demographics and needs of the entities or agents that might fund architectural work.

For this reason data gathered around the strategic imperatives, culture, asset management, site, planning and regulatory contexts, demographics and anything at all to do with the client is important. How is client’s business and operations structured? Who should we develop relationships with?A good question to ask is: where is the money coming from and who actually owns a company that might give you work?

4. Online Information:

A rapidly rising subset, if not the only one to be concerned with, is online information. This could mean anything from collecting data and about the firm’s own websites or new media channels like Instagram or Farcebook. Or collecting (scraping, is the term used, I think) information, from online, about areas of knowledge the firm is interested in. I will discuss this more in future posts.

So what ?

Once you have all of this data a firm might then be in a situation to make some reasonable design decisions. But all of this data, once gathered needs to be readily at hand. In other words it needs to be in some kind of legible and easily accessible data, information and knowledge management system. Maybe it’s an just an excel spreadsheet, database or maybe that’s  a IT system with a legible file directory.

It’s not rocket science but too often data, information and Knowledge Management in architectural firms is not seen as high priority.  But, how many architectural firms have a knowledge manager or even think about having a Knowledge Management function within their firms.

For small firm’s it is a stretch to even get the right information and data systems, even if it is only an excel spreadsheet of contacts, in place and for large firms too often data is spread across to many different silos and knowledge is too often locked into people’s heads or hidden from view by management.

Too often architects are sucked in by the production and delivery orientated technologies. Yet in the future, for both clients of architects managing data, information and producing knowledge will be where it is at. Not producing actual things. This is especially the case,  in terms of design and design outcomes, so let’s hope architects don’t miss the boat on this one.

Surviving the Design Studio: Architectural Practice as a Design Knowledge Ecosystem.

For some practicing architects, there is the prevalent fantasy that they are valued for their knowledge. In this utopian world architects, with their unique generalist knowledge alongside an ability to drill down and easily grasp disciplinary detail, are employed just like management consultants. In this scenario, all the practicing architect has to do, rather than slaving over CAD drawings, is to sit back and relax and dispense valuable knowledge to the clients. In fact, in this oh so wonderful scenario, architects get paid lots of money for it. But maybe this is dream, is the dream of a discipline slowly losing its currency, moribund by the fact that architects are hung up by the building delivery paradigm.

The best way to get anywhere near this dream is to operate an architectural practice as a Design Knowledge Ecosystem or DKE.

Ecosystems as a model, and a theoretical view, of practice are well known and prevalent in the world of big software development. For example, Google’s ecosystem has been described in the following diagram from HBRgoogle-designed-for-innovation-24-638

Some business commentators have even argued that Apple is no longer a hardware or a software company but an ecosystem. In construction management Chris Harty and Jennifer Whyte discuss what they call ecologies of practice. One of my favourite sociologists is the Bronfenbrenner who has developed Ecological Systems Theory. Bronfenbrenner’s theory contributes to our understanding of individuals in organisational contexts. Check it out if you are interested.

Thinking of the practice as an ecosystem of design knowledge is a much better way to conceive of and create new architectural theory, new modes of architectural education, and practice management. So what does the above mean for the practicing architect? For me organising a practice as an ecosystem of design knowledge implies the following:

It’s all about the idea and not the building

 A practice needs to be organised around the generation of knowledge. In other words ideas. The design of buildings are a by-product of these ideas. For a start this means that the practice must embrace research, research and development and even in some cases strive to produce innovative intellectual property. Dare I say it, Intellectual Property that might even be commercialised. This will mean that architects need to better understand and even be taught the dark arts of entrepreneurial pathways, innovation systems and associate policy contexts.

What is important for practices is not so much the creation or delivery of buildings, or representations of those buildings for that matter, but the creation of design knowledge. Managing the Design Knowledge Ecosystem is about constantly creating new ideas and managing a system that is in flux. Knowledge ecosystems can take on a life of their own and architects need to be comfortable with the ambiguity this can create.


Within practices new decision-making process and modes of leadership will be required. In the past, far too often knowledge was centred on a single designer or figure within the practice. Too often this knowledge was by its nature was tacit and for the most part hidden. Knowledge transparency is the key to creating better designs; designs that have been subject to rigorous process of design testing and re-testing. In the future leadership in the best practices will be those that are able to harness in an inclusive way all the members of a diverse team. The best leaders will be those with an intimate knowledge of design processes and different modes of designing. These leaders will understand that


The purpose of having a diverse team within a practice is not simply about giving people opportunity. Although that is really important. Practices that recruit in their own image or through existing intern networks (really, how many interns from Columbia or the AA can you get?) may miss the opportunity to create teams that spit out a range of ideas and perspectives. The Management Consultants are the same and possibly worse. Worse because consulting is an industry that constantly espouses its creativity. But, whenever I get in a room for management consultants I usually shrivel up from the stench of conformist boredom (harsh I know). Diverse teams, is about having team members with contradictory and diverse perceptual, and conceptual thinking skills. It’s also about having diverse age groups and backgrounds. Tell that tot he management consultants.  To put it cruelly who needs a team entirely composed of “big Picture” people or only the under 30s.


Building a robust knowledge ecosystem, means not limiting information to the closed boundaries of the firm. In the design knowledge ecosystem, clients, consultants, product suppliers, sub-contractors, manufacturers and yes even academics may form a part of the way a firm gathers, produces and sifts through design knowledge. This is not dissimilar to what the software developers do.

Hybrid practices

One of the problems of the current system of architectural production is that the focus on the built object has been aligned with the digitisation of design processes and workflows. And whilst the delivered object is physical, hopes for its efficient realisation has increasingly led to the myth that this realisation is entirely reliant on the virtual processes. In the design knowledge ecosystem is an immanent system where both digital objects and practices are seen to be equal with the physical. As Harty and Whyte designate the real practices of the firm are hybrid practices.

The tyranny of the commission

I suspect that for some architects the idea of a Design Knowledge Ecosystem goes against everything they were taught at architecture school. At architecture school, many of us were inculcated with the idea that architecture was ONLY about designing buildings. I think a pedagogical approach focused on building design is far too narrow an objective. This unduly puts the focus onto gaining, and then delivering, an elusive built commission. This leads to the physical object, or building, rather than the knowledge or ideas embedded in that object, being debated. Don’t get me wrong as I am the first to argue that architecture’s presence, as well as architectural aesthetics, is an important component of architectural debate (As I say in the studio, “is if it looks good then it is good”). But what interest me more than anything else is the link between architectural aesthetics and ideas. It is the ideas that architects create through design knowledge ecosystems that gives rise to the ideas that are of most interest to me. Not necessarily the completed building itself.

However, the crude emphasis on the built and completed object has helped to create a global system of architecture that is overly bound to educational pedigrees, the clustering of architectural brands around star architects, a discriminatory intern system and worst of all a clustering of theory around crude ideologies focused on the latest delivery technology. I thought we had gotten rid of those, banal notions, of a historical zeitgeist driven by technology in our discipline and discourse.  Since when was architecture just, and only, about technology: in particular delivery technologies like CAD, BIM, the gymnastics of coding and CNC fabrication? Of course the contractors and the Project Managers will flip out when they hear it’s not about the building. But maybe that’s the point of the exercise.

So, next time someone tries to tell you it’s all about: getting actual stuff built, the big brand star architect or some new technology run for the exit. It’s time for architects to stop being content with both a local and global system of practice that is entirely inflexible and increasingly redundant.